This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Does SEGGER JLink version affect BLE programming?

Yesterday, I asked a question (so far, no one has answered) about how an OS upgrade on my desktop computer might have broken my ability to flash and run BLE apps on the nRF52 Preview DK, PCA10036.

devzone.nordicsemi.com/.../

I had questions about the version of SEGGER JLink I was using before (which I did not write down) versus the SEGGER JLink I currently have installed (version 6.0.6). Today I came across this post:

devzone.nordicsemi.com/.../

...which implies that Nordic included SEGGER 5.10 in a Win32 command-line support package intended for PCA10036 development. I work in Linux, but I am still noting the difference in versions.

I know that JLink is not Nordic's software, but are there known differences between the various JLink versions? If there are problems, should this information be added to the Compatibility Matrix page (infocenter.nordicsemi.com/index.jsp

Thanks for any advice.

  • 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!

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

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

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

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

Related