• 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

    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.

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

Children
No Data
Related
Terms of service