Flash SoftDevice and then an app using JLink?

RE: Flash SoftDevice and then an app using JLink?

RK — Mon, 26 Oct 2015 23:58:28 GMT

That doesn't really make sense as lots of people flash the softdevice first and the user code afterwards. Moreover, a very standard and working practice is to flash the softdevice once and flash the user code constantly for each debugging iteration. That all works perfectly, rewriting the user code every time and leaving the softdevice alone. JLink just erases the pages it needs to use and then uploads the new code to them, it doesn't touch flash in the rest of the chip.

There could be something different about JLinkExe on Linux, but that really doesn't seem likely.

You should be able to see what's going on by loading the files in the 'wrong' order and then dumping out the memory contents back from the chip using JLink and verifying what you see.

RE: Flash SoftDevice and then an app using JLink?

Ladasky — Mon, 26 Oct 2015 22:21:02 GMT

I don't know if anyone is still following this discussion, but I discovered the solution to my problem. If the application code is flashed BEFORE the SoftDevice, everything works! Like this:

J-Link>loadfile ble_app_template_s132.bin 0x1f000

[no errors]

J-Link>loadfile s132_nrf52_softdevice.hex 0

[no errors]

J-Link>r

[no errors]

J-Link>go

[no errors]

This makes me wonder exactly how memory is being erased by JLink. Is JLink's default procedure to erase every memory address from the highest address needed by the program, down to 0? When I had the order reversed, it is possible that I was just erasing the SoftDevice after loading it.

My development platform is Linux-based. Until recently, nrfjprog was apparently unavailable on Linux. I just downloaded the Linux version of nrfjprog, and I now will try it. I was unable to use the Nordic makefiles to flash the board without nrfjprog. Loading order may be unimportant when nrfjprog is used, because I can see in the makefile that specific ranges of memory are selected for erasure. I do not specify the erased memory range when using JLink -- indeed, I don't know whether it's even possible. Time to RTFM.

RE: Flash SoftDevice and then an app using JLink?

Ladasky — Thu, 15 Oct 2015 04:28:52 GMT

Thanks again, RK. I am sure that there are better ways of me getting my work done than I am currently using. The boss wants to see Bluetooth ASAP. I will work on building a better work environment when the time pressure is off. Also, I don't get to keep the Apple laptop, it was just lent to me for Bluetooth sensing. Thanks anyway for offering your RKnRFGo software. If I could get it running on my Linux development box... :^)

I like your idea of building Blinky in a way that it co-habitates in memory with the SoftDevice, even though it wouldn't actually activate Bluetooth. At least I could see that the SoftDevice was handing off to the application. I already tried doing that, so I thought, with my attempt to communicate with SEGGER RTT. I'm willing to try another approach.

RE: Flash SoftDevice and then an app using JLink?

RK — Thu, 15 Oct 2015 01:29:47 GMT

... there's a pca10038/blank subdir. Add a pca10038/s132 subdir and populate it with an armgcc directory with the s132 ld file in it. That should build a blinky at 0x1f000, try that with the softdevice, try the bare board one too, if you can get those to work then you can at least be confident in the upload process.

RE: Flash SoftDevice and then an app using JLink?

RK — Thu, 15 Oct 2015 01:26:58 GMT

All had to start somewhere - I began this stuff about 2 years ago and spent at least the first 3 months looking permanently dazed. Debugging with JLinkExe is not very easy, you can do it, but it's just hard, so getting an environment set up, even if it takes time and it does, pays back quickly.

Another idea for you - you said you have an Apple laptop - you could grab this sourceforge.net/.../, install JLink on the mac, copy the softdevice and code files over and use that to upload them to the board. That removes one variable from the process as rknrfgo usually puts things in the right place.

Nordic usually provides a blinky which builds for a softdevice, for some reason they don't for the nrf52 DK. What you could try is going to the current blinky example ...

RE: Flash SoftDevice and then an app using JLink?

Ladasky — Thu, 15 Oct 2015 01:09:55 GMT

Hi, RK, thanks for staying with me. I did not modify the Nordic linker files for the applications in any way. Apps which don't use a SoftDevice (at least, the ones I have looked at) are allocated memory as follows:

SEARCH_DIR(.)

GROUP(-lgcc -lc -lnosys)

MEMORY

{

FLASH (rx) : ORIGIN = 0x0, LENGTH = 0x80000

RAM (rwx) : ORIGIN = 0x20000000, LENGTH = 0x8000

}

INCLUDE "nrf5x_common.ld"

And the BLE apps linker files look like this:

SEARCH_DIR(.)

GROUP(-lgcc -lc -lnosys)

MEMORY

{

FLASH (rx) : ORIGIN = 0x1f000, LENGTH = 0x61000

RAM (rwx) : ORIGIN = 0x20002800, LENGTH = 0x5800

}

INCLUDE "nrf5x_common.ld"

Concerning debugging: as I mentioned, I'm new to embedded systems. I haven't even needed a debugger yet, although I planned to use gdb. I will investigate the registers as you suggested.

RE: Flash SoftDevice and then an app using JLink?

RK — Thu, 15 Oct 2015 00:12:19 GMT

As long as you compiled the code for 0x1f000, that's the correct sequence for getting the softdevice and code onto the chip. Do you have a better way of debugging than RTT and JLink, even gdbserver is better than that.

If not then try ```halt,regs`` to see where you've ended up. Or set a breakpoint in your code using JLink.

RE: Flash SoftDevice and then an app using JLink?

Ladasky — Wed, 14 Oct 2015 23:34:04 GMT

Here is a modestly-abbreviated transcript of my JLink session:

BashPrompt$ JLinkExe -device nRF52

SEGGER J-Link Commander V5.02c ('?' for help)

[...]

Cortex-M4 identified.

Target interface speed: 100 kHz

J-Link>loadfile s132_nrf52_softdevice.hex 0 [yes, I shortened the SoftDevice file name]

[no errors]

J-Link>loadfile ble_app_template_s132.bin 0x1f000

[no errors]

J-Link>r

[no errors]

J-Link>go

[no errors]

Nothing ever happens.

I have a modified ble_app_template which includes SEGGER_WriteString statements. They should print to JLinkRTTClient when main() first starts, and when it's about to enter the power management loop. Nothing prints. My other applications which talk to JLinkRTTClient are working fine.

This makes me think that the SoftDevice is never jumping to my application's own code.

RE: Flash SoftDevice and then an app using JLink?

Ladasky — Wed, 14 Oct 2015 21:53:01 GMT

Thanks for your reply, RK. I believe that I flashed the S132 SoftDevice .hex file to 0x0, and the Beacon app to 0x1F000, but I've seen nothing so far.

Upon doing some further reading, I can see that a "beacon" means something very specific in Bluetooth terms. I believe that I am only interested in my nRF52 board "advertising" its existence at this stage. I have also tried to compile and flash ble_app_template as above. I am still not seeing anything.

I am currently seeking to modify ble_app_template to show that it's actually running (adding some blinking LEDs, or SEGGER RTT output to the USB port).

RE: Flash SoftDevice and then an app using JLink?

RK — Tue, 13 Oct 2015 06:22:04 GMT

The softdevice goes at 0x00000000 and your code is flashed at whatever the correct code address is for the softdevice you're using, which is in the softdevice spec. It's the address you built the code to run at. In the case of the S132 V1 alpha that's 0x1f000. That address is in the ble_app_beacon_gcc_nrf52.ld file you used to build the code.

And you have it backwards, the softdevice, which is at 0x00000000 is the code the chip starts running on boot, because that's where the default vector table is. When it's set itself up, it reads the vector table at 0x1f000, the defined address for your user code, and jumps to the reset_handler who's address is at 0x1f004. The user code never really calls the softdevice except via SVC calls which are handled by the softdevice's SVC interrupt handler.