Creating nRF51x22 Embedded Targets

In my previous post I demonstrated the use of a Free Pascal embedded target for the nRF52832 Nordic Semiconductor SoC processor.  This chip also has a little brother, the nRF51422 and it’s variant the nRF51822.  Unfortunately, they aren’t currently supported as embedded targets by Free Pascal.  So I have returned to looking into the feasibility of implementing them.

Last year, I asked about support for these chips on the Free Pascal mailing list and was kindly created a patch by Michael Ring giving provisional support for them.  Unfortunately, I ran out of time to work on this and in the meantime the Nordic Semiconductor SDK and Free Pascal have gone through several version changes.

Ideally, the current processor SVD should be used to generate new support files, but to get up and running as quickly as possible, I have adapted Michael’s original patch to work with  Free Pascal trunk and structured it consistently with the new nRF52832 support.

I have also adapted my demo for the nRF52832 to run on the nRF51422 and tested it with my the nRF51-DK.  The only change to the source code is to the pin numbers of the board’s LEDs.  The build setup is identical to that of the nRF52-DK, with only minor changes to the flashing script:

nrfjprog --recover -f NRF51
nrfjprog --program Test.hex --verify --chiperase -f NRF51
nrfjprog --rbp ALL -f NRF51
nrfjprog -r -f NRF51

The new last line forces a reset for the board, which happens automatically on the nRF52-DK, but not with the nRF51-DK.  To use this program within the Lazarus IDE the custom project options need to be set to:


Otherwise this behaves identically to the nRF52832 version.  The test program is available here and the experimental patch for Free Pascal here.  Hopefully, I will be able to develop this into a stable solution for supporting these targets with the help of the excellent Free Pascal developer community.

Free Pascal with nRF52832 Embedded Target

In addition to targeting all of the mainstream desktop OS environments, Free Pascal is also capable of generating code for bare metal architectures. This is supported by cross compiler builds with the target operating system parameter (-T) set to ’embedded’, in combination with the target CPU (-P) and architecture instruction set (-Cp) parameters identifying the required processor.

I want to be able create embedded programs for the Nordic Semiconductor ARM SoC’s the nRF52832 and nRF51822.  Fortunately, Free Pascal already contains support for the nRF52832 in the current trunk version (3.1.1) and that is what I will be using here.  The nRF51822 will have to be the subject of a future post!

The process of creating a cross-compiler I have already looked at in my post ‘Cross-compiling to Pi Zero’.  The procedure is exactly the same for an embedded target, except for the embedded parameter and the fact that only a minimal RTL is required.  This minimal RTL creation is controlled by the make file options ‘buildbase’ and ‘installbase’.  So the actual building and installing commands for a nRF52832 cross compiler are as follows (all parameters on a single line):

make buildbase CROSSINSTALL=1 OS_TARGET=embedded CPU_TARGET=arm 
            SUBARCH=armv7em CROSSOPT="-O2 -gw2" CROSSBINDIR=/usr/bin/ 

sudo make installbase CROSSINSTALL=1 OS_TARGET=embedded CPU_TARGET=arm 
            SUBARCH=armv7em CROSSOPT="-O2 -gw2" 
            BINUTILSPREFIX=arm-none-eabi- PREFIX=/usr

They can replace the commands given in the script for the Pi Zero as it is identical in all other respects.  Once the cross compiler is installed, a program may be compiled for the nRF52832 with the following command line:

fpc -Tembedded -Parm -Wpnrf52832 -CpARMV7EM -XParm-none-eabi- 
                                             -Oonostackframe Test.lpr

Note the key parameter ‘-Wpnrf52832’ which identifies the exact embedded target to build for.  There is a very useful command line parameter for a Free Pascal cross compiler:

ppcrossarm -iu

Which lists all of the supported embedded targets for that particular compiler.  This is a good check that the cross compiler was created with the correct command line options.

To transfer the program to the target board I use nrfjprog which can be installed from the RF5x-Command-Line-Tools-Linux64.  The actual commands to perform the transfer are:

nrfjprog --recover -f NRF52
nrfjprog --program Test.hex --verify --chiperase -f NRF52
nrfjprog --rbp ALL -f NRF52

On the nRF52-DK, which is the test platform I am using, the program starts running as soon as the board resets at the end of the transfer.  Obviously the build and transfer commands can be contained in a single make files so the day-to-day workflow feels very similar to using GCC, just with much faster build times.

However, this being Free Pascal, it is possible to forget about explicitly executing make from the command-line and instead we can use the various Lazarus project options to perform the same operations when the Lazarus build command is executed (Shift F9).  Even the nrfjprog steps may be invoked using the ‘Execute After’ compiler settings, so that we never have to leave the IDE!  For anyone interested, my ‘proof of concept’ test program (simple nRF5x SDK ‘Blinky’ translation) is available here.


First Steps with the MtM Kit

Before I can start work on developing my own software for the MtM motion sensor kit, I need to connect the hardware to my laptop via USB tethering.  The interface board (MtAid01) provides a micro USB port, but this is purely used to supply power and does not implement a debugging connection.  However the MtAid01 board does provide a Segger J-Link ‘Serial Wire Debug’ interface to which J-Link capable hardware can be connected.

As it happens, the Nordic nRF51-DK, which I have previously worked with, includes a J-Link chipset and provides a serial wire debug interface to enable it to be connected to an external module, bypassing the onboard ARM SoC.  Therefore, my working setup consists of a USB connection between my laptop and the nRF51-DK board; then a serial wire connection to the MtAid01; into which is plugged the MtConnect04S module containing the actual chip to be programmed!


Fortunately, MtM provide a useful overview of setting up the wiring for this in their blog post:  ‘Connect MtConnect03 with nRF51 DK’.  The revision of the base board shown is an older model of the MtAid01 than the one I have, but it is close enough to work out the correct connections as the pins are consistently labelled.

To actually use this connection to flash the nRF51822 on either the nRF51-DK or the MtConnect04S requires software to transfer the system binary image.  On Ubuntu, the operating system automatically shows a mounted volume called JLINK when J-Link hardware is plugged into a USB port.  This can be used to flash the chip by simply copying the binary image ‘hex’ files to this mount point!

However, for more fine grained control over the flashing process and to be able to write command scripts, I have opted to install two additional command line utilities: nrfjprog and mergehex.  These programs are available from Nordic Semiconductor for Linux, Windows and OSX.  In my case I downloaded the RF5x-Command-Line-Tools-Linux64.  I copied these programs to ‘/opt/nRF5x-Tools’ which I temporarily add to my system PATH when I need them.

To test this is all fully working I downloaded the sample ‘blinky application’ provided in the MtM blog article ‘How to program the flash of MtConnect04S’. along with the S110 Nordic Semiconductor SoftDevice to provide BLE services. Using these, I was able to successfully flash a MtConnect04S with the following script:

rm -f temp.hex
mergehex -m s110_nrf51822_7.3.0_softdevice.hex 
                                  20160105_blinky_arm.hex -o temp.hex
nrfjprog --recover -f NRF51
nrfjprog --program temp.hex --verify --chiperase -f NRF51
nrfjprog --rbp ALL -f NRF51
nrfjprog -r -f NRF51

Here mergehex prepends the BLE softdevice (s110_nrf51822_7.3.0_softdevice.hex) to the application (20160105_blinky_arm.hex) and then copies them to a temporary file (temp.hex).  This is then flashed to the target system with nrfjprog.  Finally, to test the unit disconnected from the nRF51-DK, I attached the coin battery module (MtAid02) to the now flashed MtConnect04S processor module.  When switched on, this successfully continued to run the LED blinking software.


Un-boxing an MtM IOT Kit

Inspired by the release of the BBC Micro:bit, I have started to look again at ARM based low power boards.  I am interested in their usefulness for fencing training aids and as a possible platform for use in wireless scoring systems.  Whilst researching this, I came across the IOT Developer Kits from MtM Tech, a Taiwanese electronics company.

unbox1 unbox2 unbox3unbox4 unbox5 unbox6

They use a stackable modular design similar in concept to Arduino shield boards, but considerably smaller, each unit being approximately 3cm square.  The units I am evaluating are a pair of MtM’s Motion Sensors kits.  Each of these consists of a MtAid01 extension board; a MtConnect04S processor and BLE board; a MtSense03 motion sensor board and a MtAid02 battery board.

What caught my eye, is that the CPU component is a Nordic Semiconductor nRF51 series chip, compatible with that in the nRF51-DK board that I tested last year with Free Pascal.  The Nordic board however, does not contain motion sensors, which for my purposes, restricted it’s usefulness.  By contract, with the MtM modular design I can combine the various electronics required for a particular project in a manner rather like playing with Lego!


For comparison in my last photograph, I have placed the MTM developer kit next to a Raspberry Pi Zero on the left and a BBC Micro:bit on the right.  As you can see it is very similar to the Micro:bit in overall dimensions, although it should be pointed out that the larger base board of the MTM kit, the MtAid01, is only required during programming and can be removed for normal use, making it clearly the smallest of the three devices.

My next step will be to setup a nRF51-DK to function as a programming and debugging interface for the MtM kit.  After that I will need to build a Free Pascal cross compiler to generate the CPU binaries to perform the control logic.  I will post my progress periodically here and I will also publish the build instructions and the source to any utilities I create here and on Bitbucket.