Most recent, fully functional, GCC example code?

[chalecampb]

Hi,

I am trying to get even a basic ARM GCC example set up using the provided toolchain code, and am having a rough go at it.

First, what is the most recent, working, full example of how to set up ARM GCC to compile and deploy to a nRF51 DK? I have no 'difficult' goals - I am running without a softdevice, with only GPIO, no standard library, not trying to implement OTA firmware or anything. I can figure out Eclipse later, I just need to be able to deploy to a target for now.

My procedure was this -

1. Changed the $sdk/components/toolchain/gcc/Makefile.posix to point to /usr/local, where the ARM GCC is linked
2. CD to the blinky armgcc directory, make, make flash
3. The .hex is around 3kB, which is what we would expect for a gpio-only hex file
4. Worth pointing out at this point that "make flash" is broken, it calls --program when my nrfjprog uses --flash for some reason. Even then, as written, it calls flash on _build/.hex, which is obviously wrong. So, I do it manually, with JLinkExe commands r, loadfile _build/nrf51422_xxac.hex, r, g in a script file.
5. In any case, it says that it flashes successfully, but the expected pins are not toggling.
6. If I use JLinkExe and halt it just says that PC is at 00000. After stepping, CycleCnt doesn't change, PC doesn't change, etc. IPSR says HardFault - maybe a problem with the startup code?
7. Speaking of which, I read that some people saw blinky start at _start, which is a stdlib function, and suggested that blinky would work with the CFLAG -nostdlib. This didn't change anything.

When I halt, I see the following output -

PC = FFFFFFFE, CycleCnt = 00000000
R0 = FFFFFFFF, R1 = FFFFFFFF, R2 = FFFFFFFF, R3 = FFFFFFFF
R4 = FFFFFFFF, R5 = FFFFFFFF, R6 = FFFFFFFF, R7 = FFFFFFFF
R8 = FFFFFFFF, R9 = FFFFFFFF, R10= FFFFFFFF, R11= FFFFFFFF
R12= FFFFFFFF
SP(R13)= FFFFFFD8, MSP= FFFFFFD8, PSP= FFFFFFFC, R14(LR) = FFFFFFF9
XPSR = 81000003: APSR = Nzcvq, EPSR = 01000000, IPSR = 003 (HardFault)
CFBP = 00000000, CONTROL = 00, FAULTMASK = 00, BASEPRI = 00, PRIMASK = 00

The obvious questions,

• What am I missing to make this work?

• Is there a way to step through the code, on the command line? I will look up GDB in the meantime.

• From an organizational perspective, are there Makefile examples that are self-contained? The current system looks like it would work best if you duplicated the example projects in-place. There doesn't seem to be a way for me to just "point to" a nRF SDK installation and have it use the files there, without modifying the Makefile. I did that, and got the same result, so it's not hard, but I am interested to know why this method of organization was selected. It seems a little awkward to have to actually drop your code into the nRF SDK examples folder to use the provided stationary.

Version notes -

OSX Yosemite, 10.10.2
ARM GCC version 4.7.4 20140401 (release) [ARM/embedded-4_7-branch revision 209195]
SDK 8.0.0

Thanks,

-Alex

[RK]

1), 2) and 3) look right. Just to confirm you're in the 'blinky/pca10028/blank/armgcc' subdirectory and not the s110 one or the other board, sure you are but may as well check everything. I just built that example, I get a 3684 byte hex file. And that works on my DK, it's blinking right now.

4. make flash is broken if you're on OSX partly because nrfjprog doesn't exist on OSX, what are you actually running here, OSX or something under parallels. (you can use this if you like, it's a homebrew not-really-look-alike version of nrfjprog plus a gui which runs on OSX)

5. is the code actually on the chip?

   mem 0 128

in JLinkExe. I get this (first few lines)

00000000 = 00 80 00 20 15 03 00 00 5D 03 00 00 5F 03 00 00 
00000010 = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  

which makes sense. 0x20008000 for the stack pointer, reset handler at 0x00000314

6. CycleCnt won't change, the nrf51 doesn't have a cycle counter on it, the rest of the registers make no sense at all unless you don't actually have code on the chip. In fact that looks really like you have 0xff everywhere, PC at 0xFFFFFFFE, SP at 0xFFFFFFD8 (starts at 0xffffffff, gets aligned to 8 bytes on the exception and then has 32 bytes pushed --> 0xFFFFFFD8).

7. I don't know where you read that but that advice is garbage, I'd ignore that.

Couple other things, are you running JLinkExe with

-if swd -device nrf51

Before programming try the flash wipe sequence which is

r
sleep 500
w4 4001e504 2
w4 4001e50c 1
r
w4 4001e504 1
sleep 1000
r

no need for the sleeps if you're typing from the command line.

what else - you can single step with JLinkExe if you have lots of patience, it's fine for a blinky example, not hard to follow along.

[chalecampb]

OK, this is great, exactly the response I needed!

So, it turns out that I had done something similar in grabbing an nrfjprog variant from the internet. Unfortunately it was nrfjprog-in-name-only, there were a few other problems with it.

• The makefiles called -program, but the fake nrfjprog implemented -flash
• The fake nrfjprog called loadfile, not loadbin. loadfile didn't work, even though the hex seemed to be correct.
• The options for JLink used -device nrf51822, not -device nrf51, so when I switched everything to match, it worked great.

The symptom was, everything was 0xff. I am not sure why loadfile and loadbin would both say O.K. when they were failing to load. The expected output for loadbin should be

J-Link>loadbin _build/nrf51822_xxac.bin 0
Halting CPU for downloading file.
Downloading file [_build/nrf51822_xxac.bin]...Info: J-Link: Flash download: Flash download into internal flash skipped. Flash contents already match
Info: J-Link: Flash download: Total time needed: 0.597s (Prepare: 0.514s, Compare: 0.032s, Erase: 0.000s, Program: 0.000s, Verify: 0.000s, Restore: 0.051s)
O.K.

I will check out the rknrfgo program, it's probably a bit more reliable. Hope this helps someone else!

[RK]

To be fair to the author of the other nrfjprog,

• loadbin is documented only to work on bin files and loadfile is the correct jlink command for loading bin, mot, hex and srec, so loadfile is correct. I suspect that loadbin was changed to be the same as loadfile long ago and the docs never updated.
• nrf51 is the most generic device name to use but nrf51822 works as do a large number of others. In fact segger only lists the very long names like nrf51822_xxAC.
• loadbin isn't very good at reporting failure in some cases and JLinkExe is even worse at propagating errors out of the exe as a status code (although I think I saw Segger say recently they were going to fix that, or had in most cases)

So actually it seems to me that nrfjprog should have worked. I'd suspect that the chip needed the --erase-all option to get it into programmable mode at all, now it is, it works.