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

[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.