Using Segger Studio and Nordic SDK with Particle Xenon
The Particle Xenon is a nice CPU module based on the brand new Nordic Semiconductor NRF52840. Last I looked, retail price was $15 so it’s very compelling. This article is about ignoring the Particle firmware and using a totally different operating system and development chain for it.
I waited months for my Xenons in order to replace some Adafruit NRF52 boards. They have the exact same pinout and mechanics. The Xenon uses the newer processor (with twice the ram and flash), is FCC certified, and has a 4MB spi flash for extra storage. It’s also about half the cost!
Unfortunately the Xenon also comes with very incomplete software. The firmware doesn’t yet support traditional Bluetooth and it’s missing features like sleep. I have great faith in Particle and expect the firmware to add these features but I have a project waiting for this.
I’m pretty sure Adafruit is also working on their Arduino for the chips but they don’t yet have the Xenon files in their Arduino port.
So, I decided to try developing on the Xenon using the Nordic Semi NRF5 SDK, instead of the particle firmware. It seems to be working fine.
To get started you need Segger Embedded Studio (free for Nordic development).
SES requires a Segger device for connection. If you’re a hobbyist that would be the Segger JLink EDU (purchase here) for about $60 or the JLink Mini EDU for about $20. You can develop without debugging using the SDK but getting a JLink is totally worth it.
This also needs an SWD adapter cable.
Also install the Nordic NRF5 SDK. This is a zip file that I unzipped into a root folder with a short name (no spaces or funny characters in the folder name).
Segger Studio installs the rest of the toolchain (gcc-arm).
Once the prerequisites are installed, run Segger Embedded Studio (SES). The top menu has a command Tools / Package Manager … Click this and refresh the package list then find the Nordic tools package and install it.
I personally use Visual Studio Code for development, but I use SES for building, debugging, and quick edits. Normally I keep both windows open simultaneously. Nothing special about the VSCode installation.
Connection requires two USB ports. Use this order:
- Connect the JLink to the Xenon using the debug port.
- Connect the JLink to a USB port.
- Connect the Xenon USB input to a USB port.
It’s easy to do the first test. Start up SES and select File / New Project…
SES has strange definitions of project and solution. I treat them as the same. When you create a new project it builds a project file (foo.emProject) that you load using “Open Solution”. Huh?
Put it in a new solution and for project settings change the Target Processor to the NRF52840_xxAA.
This will create a simple hello world application. You can build and download in one step by doing a Go (F5) or you can build then download then go…
When you run it the Debug Terminal will show Hello World nns.
A Serious NRF52840 Application with Bluetooth
To move on to a more serious application, the best thing to do is start with a Nordic-supplied example program. To use a Nordic sample program go to the folder (C:\nrf5_sdk\examples\ble_central\ble_app_hrs_c in my case) and then dive into the pca10056\s140\ses folder where the Segger Embedded Studio (ses) project file lives. Double-click the emProject file to load the project.
The pca10056 is the codeid for the Nordic NRF52840-DK board, which is a pretty slim board and seems to work fine as a starting point for the Xenon. The code also won’t deal with the Particle Lipo charging system nor the antenna selector.
This will produce a working bluetooth application (in my case) but all of the dependencies require the app being in the nrf5 sdk folder — which sucks.
Move the app by moving the entire folder somewhere useful (e.g. Documents) and then edit the emProject file with better paths. I added a macro for the base SDK path then updated the relative paths to the SDK code in the emProject file. Also look at the emSession file and remove any prior paths.
Adafruit is starting to support the Xenon, as expected. The board files were added on Dec 4th (two days ago as I write this). See sdk-root/boards/particle_xenon.h for example.
Building the bootloader
It took longer than I thought. You can just download the hex files stored in the Releases tag.
First, the makefile is designed for windows (I usually build in windows ubuntu). So I had to find make and cut and tar. I ended up installing GnuWin32 (make and the core utilities) and adding the GnuWin32/bin folder to my path. PATH=%PATH%;%CD% does it if you are in the folder.
Next the makefile needs changes with GnuWin.
- It has the wrong name. GnuWin make wants it named makefile and it is named Makefile. Just rename it.
- I’m not sure where the gcc path came from. Change the line below to point to your unzip of the 2018 q2 update.
GNU_INSTALL_ROOT = $(PROGFILES)/GNU Tools ARM Embedded/7 2018-q2-update/bin/
- There’s a syntax error in the cut call if you’re using GnuWin32. The following line originally used
cut -d' ' -f3,4and should be:
GIT_SUBMODULE_VERSIONS = $(shell git submodule status | cut -d" " -f3,4 | paste -s -d" " -)
At one point SES was convinced the firmware on the chip was up to date (it wasn’t). I think it uses a CRC to verify the flash has changed so there is a small possibility the CRC is unchanged I guess. I finally ended up clearing the flash and then it failed crc and downloaded and worked.
The SES project settings require all individual include paths for the SDK. This is a lot of paths. I worked through failed compiles, adding paths as required, until it compiled. Some care is required as the SDK has multipath options for their different chips (so the same file in multiple places). Apparently you also have to point to each individual c/c++ file used by the source code (including the nrf5 sdk). Rather tedious.
It’s not at all clear where the Nordic soft-device (the API library for the chip) and the bootloader live in the SES processing. More detective work.
In the Weeds
I’m a newbie but here are some helpful hints. Feedback is welcome.
Two repositories are critical. Open source smile.
This is a really nice Arduino layer over the nRF52 SDK. It provides examples and good working code. Clone it locally.
Here you can download the current SDK tree. Unzip it and put it somewhere.
The Nordic Semiconductor documentation is abysmal. No, it’s worse than that. Their examples, however, are illustrative and they have a user forum. So, all is not lost. Also, there’s the working Adafruit layer for additional examples. Please buy something at Adafruit.
The example folders come with this innocuous file named flash_placement.xml. You care when all of a sudden it can’t find things that live in the SoftDevice. The flash_placement file names them and voila they appear for the link.
I use VSCode to edit the .emProject file. Especially with a project macro for the sdk folder it’s efficient. SES auto-reloads the project on save by VSCode. You get two common build errors:
- Can’t find header file: they don’t support recursive include paths, so find the file in the nrf5-sdk folder tree and add the path to the project file.
- Can’t find method linked-to. Add the sdk’s xxxx.c file to the project tree (use Add Existing File…).
For source files the projects do support recursion. This is done by creating a new folder (with the path name imho) and making it dynamic linked to the folder you want (example ./Utility) and recursion is a checkbox.
Because the Xenon is not yet supported I created two key files
- config/sdk_config.h — this file is included at the top of most of the source files. It’s a combo of the /10056/sdk_config.h settings as overrides for the Xenon. This file enables and disables modules and defines on-board peripherals.
- particle_xenon/variant.h — this is the Arduino partial equivalent to sdk_config
Key-> I also edited the nrf52 sdk tree in-place (yuck). I created a git repo of it (since it’s just a zip) then made the changes. I added two lines to boards.h to add the particle_xenon then added a particle_xenon.h header for it derived from the 10056 header (as I recall). Follow up by changing the BOARD’s preprocessor definition in the emProject to BOARD_PARTICLE_XENON.
I’ve been working with SES for a few days now. I really like it. The IDE (interface) is ok, but noticeably worse than Visual Studio Code, except for two things.
- When there’s a build error it opens the file and scrolls to the first error and shows error lines with a red x-circle. That’s nice.
- The debugger is very similar to Visual Studio (real) and that’s a wonderful thing. It has breakpoints and shows local values and lets you step in and out and … yay.
So, highly recommended as a nRF52840 development environment. I run Visual Studio Code at the exact same time for serious editing — the apps synchronize extremely well.
I ported about 5,000 lines of Arduino code to the nRF5 SDK in under a week.