Flash SoftDevice and then an app using JLink?

[Ladasky]

Hello everyone,

Please forgive my continued naive questions. This is my first embedded-systems project.

I have been working with an nRF52 development board and SDK 0.9.1 for several weeks. I have applications talking to the USB interface. My development environment is pure Linux. I am running GCC ARM Embedded, and SEGGER JLink, from the command line. Notice, I don't have access to the Windows-based nrfjprog, so I can't use the parts of the Nordic-supplied makefiles which flash the board.

Now my boss wants me to get the device talking over Bluetooth. I tried compiling the ble_app_beacon and flashing it to the board the way I have done with USB-based apps. I have an Apple laptop scanning for Bluetooth devices. It sees other Bluetooth devices, but it's not seeing my nRF52 board. After doing a little reading, I believe that I skipped a step. I should flash the board with the S132 SoftDevice .hex file first. Then I should flash the board with my app, making sure not to over-write the SoftDevice.

I know how to change the address of the starting flash memory location with JLink, but I have never flashed any memory location other than 0. How do I choose where to flash the SoftDevice, and where to flash my application? I can't imagine that those locations can be arbitrary. There must be a defined execution start address. Without linking the app to the SoftDevice at compile time, the app still must know where the SoftDevice resides in memory in order to call it (which I think it would have to do at least once for setup purposes, even if everything is handled by interrupts after that?).

I am aware of github.com/.../nrf51-pure-gcc-setup. I have learned quite a few things from reading through the files there. But some parts of it are out of date, particularly the parts which refer to a toolchain called ELF (which was apparently succeeded by GCC ARM Embedded). The parts of those makefiles which compute memory locations, flash the SoftDevice, and then flash the app, depend on ELF.

Thanks for your help!

[RK]

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

[RK]

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

[Ladasky]

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.

[Ladasky]

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.

[RK]

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.