Most recent, fully functional, GCC example code?

RE: Most recent, fully functional, GCC example code?

RK — Sun, 26 Apr 2015 00:38:32 GMT

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.

RE: Most recent, fully functional, GCC example code?

chalecampb — Sat, 25 Apr 2015 18:17:12 GMT

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!

RE: Most recent, fully functional, GCC example code?

Nguyen Hoan Hoang — Sat, 25 Apr 2015 02:24:59 GMT

That is what I meant. not using Softdevice. The problem you are having is very similar to the problem I mentioned. When you run a Blink Blank on a blank chip, it's fine. If you run the Blinky blank on a chip already have Softdevice burned in. The jtag is unable to write you blinky lot location zero but it thinks that the write was successful and crash with register dump all FF. This problem is not only with Jlink but also with OpenOCD. After using nRFGo to perform an erase all, blinky blank works.

RE: Most recent, fully functional, GCC example code?

bluevanilla — Sat, 25 Apr 2015 02:13:41 GMT

You can follow https://devzone.nordicsemi.com/tutorials/7/development-with-gcc-and-eclipse/ to set up your mac dev environment.

If you don't want that, the basic things you need are GNU Tools for ARM Embedded Processors (you probably want to put it in /usr/local/bin) and RKNRFGO (to flash your board).

You seem like you installed gcc arm and changed makefile correctly I assume. Then you cd to "/nRF51_SDK_8.0.0_5fc2c3a/examples/peripheral/blinky/pca10028/blank/armgcc" and make. Use RKNRFGO to download .hex to the board without soft device.

This works for me. Sorry if I am not solving your question directly. But those are the steps that took me.

RE: Most recent, fully functional, GCC example code?

RK — Sat, 25 Apr 2015 02:07:58 GMT

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.

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)
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

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

RE: Most recent, fully functional, GCC example code?

chalecampb — Fri, 24 Apr 2015 20:35:22 GMT

Like I said, I am not using a SoftDevice. Good thought, though, I have run into that issue in other contexts.

RE: Most recent, fully functional, GCC example code?

Nguyen Hoan Hoang — Fri, 24 Apr 2015 19:42:04 GMT

When the chip has Softdevice flashed in, it won't work directly due to protection. You need to do full erase before you can debug any program that does not use Softdevice.