This post is a quick tutorial on how to set up a GUI for debugging NRF51 code
2015-08-28
Previous article
Update:
If you want to know the insides of how to set up a development environment, read on!
If you want Ansible to do all the work for you, skip this post and check out my repos:
* For an Ubuntu VM, use this repo
* For using your Mac natively, use this repo.Enjoy!
Introduction
There is not much documentation about the NRF51, and the tool-collection hunting and gathering process can be intimidating.
I hope this blog entry will help those that want to use and program the Nordic NRF51 development board to test out BLE functionality.
The hardware
We are using the NRF51 development board, which was purchased from here.
Basic operations
Connecting to the board
Connection is done via conneting a standard Micro USB Cable to your host computer. Once power is supplied to board, it will run the current program automatically.
Communicating with the board
Flashing the device can be done using the JLinkExe program runing on the host computer. JLinkExe can be downloaded from here.
Resetting the board to manufacturer settings
From a terminal window, as the device is connected and turned on, run the following command line:
[code language="bash"]prompt> JLinkExe -device nrf51822
[/code]
When the JLink prompt appears, type the following:
[code language="plain"]J-Link> w4 4001e504 2
J-Link> w4 4001e50c 1
J-Link> r
J-Link> g
J-Link> exit [/code]
This will erase all the programs that were loaded.
Programming the device
In order to program the device, you must first set up the following tools:
The Nordic SDK
The SDK can be downloaded from the Nordic website here. For our testing, we used nRF51_SDK_v9.0.0. The SDK contains a binary referred to as “SoftDevice” that supports BLE management of the chip. Please see below on how to load the SoftDevice to the board using JLink.
Compiler and Linker toolchain from GNU
The cross-compiler/linker tools that are needed to build executables for the board can be found here. We placed them under ‘/usr/local’. If you have multiple development environments, it may be easier to set an alias to run the right tools rather than modifying the path. For example:
[code language="bash"]alias gdb51="/usr/local/gcc-arm-none-eabi-4_9-2015q2/bin/arm-none-eabi-gdb"
alias jdb51="jlinkgdbserver -device nrf51822 -if swd -speed 4000 -noir -port 2331”[/code]
Loading a binary to the device
An executable image is created in the form of “.HEX” files that has to be loaded to the board’s flash memory. To load it to the device, open a terminal window and run JLinkExe, this time using the loadfile command:
[code language="plain"]prompt> JLinkExe -device nrf51822
J-Link> loadfile path-to-binary
J-Link> r
J-Link> g
J-Link> exit [/code]
When you program BLE functionality, you will need to load the chip’s firmware in order to support your programs. This is packaged as an executable and is part of the SDK. In order to load the SoftDevice, simply use the loadfile command with the correct path, such as:
[code language="plain"]J-Link> loadfile SDK_ROOT/components/softdevice/s110/hex/s110_softdevice.hex
J-Link> r
J-Link> g
J-Link> exit
[/code]
Select a different path if you want to change the version loaded (in this example, it’s S110).
Checkpoint
At this stage, you should have a connected board that has a version of the firmware loaded, and the toolchain downloaded, ready for development to begin!
BLE is hard, but blinking the board is easy
Using the toolchain let’s compile and load the demo blink program that comes with the SDK to make sure we have everything in place for future development.
Making Make make
Here you’ll edit the file named Makefile.posix to point to the correct toolchain for cross-development. The file is found at SDK_ROOT/components/toolchain/gcc/Makefile.posix, where SDK_ROOT being the location you installed the Nordik SDK files.
Edit this file so it contains the path to where you installed the cross-compiler:
[code language="plain"]GNU_INSTALL_ROOT := /usr/local/gcc-arm-none-eabi-4_9-2015q2
GNU_VERSION := 4.9.3
GNU_PREFIX := arm-none-eabi[/code]
Building the blink example
Navigate to the “blink" example directory
[code language="bash"]cd SDK_ROOT/examples/peripheral/blinky
[/code]
Depending on your board (the one we used was PCA10028), you might need to create a subdirectory within “blinky” by copying the one present, if your model number does not appear there:
[code language="bash"]cp -r pcaXXXXX pca10028
[/code]
Edit the Makefile in the PCA10028/armgcc directory to reference DBOARD_PCA10028, if it’s not already referenced there.
The path to the makefile is: SDK_ROOT/examples/peripheral/blinky/pca10028/s110/armgcc/Makefile.
Once you have saved the modification, return to the terminal window and invoke make to build the image:
[code language="plain"]prompt> make
[/code]
in the directory where the makefile is located.
Even though the LED program does not need BLE functionality, let’s load the S110 firmware prior to loading our image for illustrative purposes:
[code language="plain"]prompt> JLinkExe -device nrf51822
JLink> loadfile SDK_ROOT/components/softdevice/s110/hex/s110_softdevice.hex
[/code]
And now we’ll load our blink example
[code language="plain"]JLink> loadfile _build/nrf51422_xxac.hex
JLink> r
JLink> g
[/code]
You should now see the board’s four LEDs should blink at a nice rhythm.
Debugging
Download the jlinkgdbserver debugger from here. When run, it will connect to the board via the serial cable, and wait for commands coming from the GNU debugger, which was included in the GCC download described previously.
To build with debug symbols, invoke make with the debug goal:
[code language="plain"]prompt> make clean
prompy> make debug
[/code]
Run the debugger server in a terminal window or tab:
[code language="plain"]prompt> jlinkgdbserver -device nrf51822 -if swd -speed 4000 -noir -port 2331[/code]
Open another terminal window and run your image from the armgcc subdirectory so that JLinkExe will be able to load the debug symbols created when building the application:
[code language="plain"]prompt> gdb51[/code]
This runs the debugger, loading debug symbols which will relay instructions to the JLink server that in turn will relay those to the board.
Summary
We made sure that the hardware and the development environment was set up correctly for future application development. In order to take advantage of the hardware’s capabilities, please refer to the documention of the board and firmware here, which contains essential links to the BLE functionality as well as a demo mesh project.
Acknowledgements
I’d like to thank Tim Kadom, my friend and colleague at ThoughtWorks, who sparked my interest by introducing me to BLE and mesh applications and was instrumental in helping me set up the environment and getting everything to work.
Previous article
Filed under
BLE
arm
nrf51
Other Tags
API GW
AWS
- Programming ESP32 using MQTT with AWS and FreeRTOS
- Quick AWS IoT Setup and test
- Set up AWS API GW with a Typescript authorizer and logging
- Use AWS CodePipline to execute CloudFormation templates
- Use GitHub Actions to deploy your SPA hosted on Amazon S3
- Use an AWS CloudFormation script to create and host an SPA on S3 with SSL and apex/subdomain redirection using CloudFront
- Writing an Alexa skill using Ruby and AWS Lambda (Part 0)
ActiveRecord
Agile
- A review of software development metrics
- Agile programme management brief
- An alternative to current product development metrics
- An alternative to the current product development governance model
- Command & Control Management - The Party Killer
- Document Driven Development
- Inceptions revisited
- Managing multiple stakeholders
- Returns Driven Development
- The tip of the (good) iceberg
Alexa
Analysis
Ansible
BDD
BLE
C
CAB
CloudFormation
- Set up AWS API GW with a Typescript authorizer and logging
- Use AWS CodePipline to execute CloudFormation templates
- Use GitHub Actions to deploy your SPA hosted on Amazon S3
- Use an AWS CloudFormation script to create and host an SPA on S3 with SSL and apex/subdomain redirection using CloudFront
- Writing an Alexa skill using Ruby and AWS Lambda (Part 0)
CloudFront
CloudWatch
Cross-compile
Cucumber
DevOps
Devops
DotNet
Embedded
Fitbit
GNU
GitHub Actions
Governance
How-to
Inception
IoT
Javascript
Jest
Lambda
Mac OS X
- Bluetooth Low Energy (BLE) Implementing a peripheral on Mac OS X
- Cross-compiling for Raspberry Pi on a Mac and debugging using NetBeans
- Drobo will not mount in Finder
- Quickie - ssh dynamic port forwarding to avoid unsecured public networks
- Remote compilation, execution and debugging Raspberry Pi from a Mac using NetBeans
- Weekend warrior - MacRuby and rSpec, Mac OS X Lion, Xcode V4.3.2
MacRuby
Metrics
MySQL
NetBeans
Objective-C
PMO
Product Management
- A path to accelerating value realization
- A review of software development metrics
- Agile programme management brief
- An alternative to current product development metrics
- An alternative to the current product development governance model
- Express initiative kickoff formula
- Inceptions revisited
- Managing multiple stakeholders
- Plan for value delivery
- Pre-prod activity - Futurespective
- Value Stream Mapping
- When planning, it's not only about relative complexity
Programme management
Project Management
- A path to accelerating value realization
- A review of software development metrics
- Agile programme management brief
- An alternative to current product development metrics
- An alternative to the current product development governance model
- Command & Control Management - The Party Killer
- Express initiative kickoff formula
- Inceptions revisited
- Managing multiple stakeholders
- Plan for value delivery
- Pre-prod activity - Futurespective
- Value Stream Mapping
- When planning, it's not only about relative complexity
Quality Assurance
Rails
Raspberry Pi
Remote compilation
Remote debugging
Remote execution
Risk Assessment
Route 53
Ruby
- Alexa on Rails - how to develop and test Alexa skills using Rails
- Arduino programming using Ruby, Cucumber & rSpec
- How to reconnect to a database when its connection was lost
- Oh, the places you'll go...
- Quick AWS IoT Setup and test
- Weekend warrior - MacRuby and rSpec, Mac OS X Lion, Xcode V4.3.2
- Writing an Alexa skill using Ruby and AWS Lambda (Part 0)