• State Verified Answer
  • Replies 10 replies
  • Subscribers 72 subscribers
  • Views 5334 views
  • Users 0 members are here
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.

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

Reply
  • 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?

Children
No Data
Related
Terms of service