Attachments (0)
Nordic Case Info
  • Case ID: 115813
Options
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?

Ladasky

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.

Parents
  • 0

    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.

Reply
  • 0

    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.

Children
  • 0 in reply to RK

    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.

  • 0 in reply to RK

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

  • 0 in reply to RK

    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?

  • 0 in reply to RK

    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.

  • 0 in reply to RK

    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.

Terms of service