Does SEGGER JLink version affect BLE programming?

RE: Does SEGGER JLink version affect BLE programming?

Ladasky — Fri, 19 Aug 2016 00:30:13 GMT

That's right RK, the compatibility matrix says that the only version of the S132 SoftDevice which is compatible with the Engineering A (PCA10036) boards is 1.0.0-3.alpha.

Now that we have a year's worth of experience with the alpha version of the nRF52 and our project is growing, we will be getting some newer boards. But I had to hand one of the original boards off to another team member for Bluetooth work, and I needed to give him a board that was actually doing something over BLE.

RE: Does SEGGER JLink version affect BLE programming?

RK — Thu, 18 Aug 2016 23:54:48 GMT

ok I had to look that version up - it's so old I don't even have support for it in my OSX tool, but yes indeed that was 0x1F000, then it dropped to 0x1C000 and now with v3 it's back to 0x1F000 again.

I don't remember what the compatibility was, possibly if you only have the original PCA10036 boards you are limited to very early versions of the softdevice. You might want to raid the piggy bank and get a more recent dev kit, eg the PCA10040 which gives you access to the production softdevices and all the great stuff added in S132V2 and even more in V3, which I haven't even moved to yet.

RE: Does SEGGER JLink version affect BLE programming?

RK — Thu, 18 Aug 2016 23:44:40 GMT

The sections of memory erased when doing a loadfile are exactly the bytes required to load the new file and nothing more and nothing less. A full erase does a full erase (most people don't use the erase command but write the registers directly however Segger's erase command runs the correct thing for each board type they support so using that works as well).

I don't know what's going on because it continues to make zero sense.

RE: Does SEGGER JLink version affect BLE programming?

Ladasky — Thu, 18 Aug 2016 23:42:14 GMT

RK, please see my longer comment, I have solved my own problem. In this remark, I will simply note that I am using SoftDevice S132 1.0.0-3.alpha, which is compatible with the PCA10036 boards I have. I am flashing this SoftDevice to 0x0. The makefiles for the BLE examples in SDK 0.9.1 and 0.9.2 build the APPLICATION to be installed at 0x1F000, and that's where I'm installing the app.

RE: Does SEGGER JLink version affect BLE programming?

Ladasky — Thu, 18 Aug 2016 23:37:36 GMT

Well, I seem to have solved my problem, although I don't know exactly WHY I had to do what I did.

After many frustrating attempts, I discovered that if I invoke the erase command from JLink before flashing the board, Bluetooth applications are working again. RK, I was working on this all day, and I just saw your post come in as I was typing this. If running erase was what you meant to tell me to do when you wrote "type in the commands to clear flash", I seem to have stumbled on that myself.

As suggested by David: using mergehex to make a single file out of the SoftDevice and the application works -- but so does the more straightforward way of flashing each file separately.

I was also able to flash ble_app_heart over ble_app_template at memory location 0x1F000, and on rebooting, the board was running the heart rate app. Previously, I was unable to do this. See above.

What exactly is going on with JLink? What sections of memory are erased on executing a loadfile command? Why doesn't loadfile seem to erase something critical to the operation of the SoftDevice? What does a full erase do that loadfile does not? If anyone understands, please feel free to chime in. Thanks!

RE: Does SEGGER JLink version affect BLE programming?

RK — Thu, 18 Aug 2016 23:26:05 GMT

Your old procedure makes no sense either, so really it seems you have a basic misconception here somewhere, because everyone else can program softdevices and code in any order and do it all day long. JLink can write as little as a single byte, it saves the pages it's going to clear, updates the data you want to write, clears only the pages required and then writes back the data. And that hasn't changed between version 4, 5 or 6 and it never will.

Why are you putting your code at 0x1f000? The only softdevice which uses that start address I'm aware of is the S132V3 which was just released. What softdevice are you using? Are you building for the correct address? Are you loading the correct softdevice?

Start over with a JLink session, and type in the commands to clear flash, load the softdevice then load your code and put the log of the session in the question.

RE: Does SEGGER JLink version affect BLE programming?

Ladasky — Thu, 18 Aug 2016 19:14:34 GMT

Hi David, thanks for your suggestion. I will give mergehex a try, to see whether it solves my problem. I have never used mergehex. I didn't need to use mergehex the last time that I ran BLE apps on my nRF52 boards, about six months ago.

But I had to flash the app code .bin into high memory (0x1f000) first, and then flash the S132 driver .hex into low memory (0x0). If I switched the order, nothing ran. Other people found this behavior unexpected -- and I agree, flashing the (unchanging) SoftDevice once into low memory, and then flashing your own (changing) code into high memory should be possible, and it is far more convenient for code development. I am still wondering exactly which regions of memory JLink chooses to erase, and how. Maybe the memory erasing process was changed between JLink 5.x and 6.x?

RE: Does SEGGER JLink version affect BLE programming?

David Edwin — Thu, 18 Aug 2016 10:20:34 GMT

Are you using mergerhex to merge the application hex file and the softdevice hex file before flashing them with jlink.exe ?

RE: Does SEGGER JLink version affect BLE programming?

Ladasky — Thu, 18 Aug 2016 01:44:52 GMT

Thanks for your answer, RK. I do not use any of the Python tools. I use JLinkExe directly to flash my boards.

Simple applications like Blinky are working fine. A more complex application that I wrote which makes use of TWI, SAADC, and UART is also working fine. The only thing that has stopped working for me is applications using BLE. I can flash them to the board, but they are silent. As I said, I have two PCA10036 boards. I used one board as a BLE heart rate transmitter and the other as a receiver.

I have not written any of my own BLE apps yet, I am just trying to get the Nordic example programs running again. If you have any thoughts on this matter, I would appreciate them... but they probably should be made in the thread I started yesterday (first link in my original post) unless there is some connection to JLink. Thanks.

RE: Does SEGGER JLink version affect BLE programming?

RK — Wed, 17 Aug 2016 23:43:13 GMT

No it doesn't matter at all as long as your JLink version is recent enough to support the chip you're using (eg very old JLinks didn't support the nRF52), so anything newer is fine, modulus the occasional bug which gets added. So 6.0 is fine and nothing needs to go into any compatability matrix.

Adding one note that if you're using something compiled against the JLink SDK there can be issues however again for the most part even that is very forward compatible.

Try JLink from the command line to figure out whether it's the python tools which don't work or if your basic JLink package doesn't work.