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

How to flash with JLink command line

I have set up the gcc toolchain on Mac OSX to compile my BLE nRF51822 code and I tried to flash the code. Here are the 3 scenarios that I have tried (JlinkExe on Mac)

Case 1 : code compiled with Keil on Windows, is flashed (bootloader + softdevice + app), all works well. The memory is then read from flash with Windows in 1 hex. I flash it with Mac, it works

Case 2 : I flash with my Mac the softdevice.hex (from case 1) then app.hex (from case 1). It doesn't work

Case 3 : same as case 2 but app.hex comes from compiled code from mac, not from windows

Here is my script :

device nrf51
speed 1000
w4 4001e504 2
w4 4001e50c 1
sleep 100 
r
# case 1   : OK
# loadbin soft_device_bootloader_app.hex 0x0

# case 2   : FAIL
# loadbin s110_nrf51822_7.0.0_softdevice.hex 0x0 
# loadbin app_windows.hex 0x16000

# case 3   : FAIL
# loadbin s110_nrf51822_7.0.0_softdevice.hex 0x0 
# loadbin app_mac.hex 0x16000
sleep 100 
r
g
exit

Note : this is soft device S110, 7.0.0. Thanks!

Parents
  • Instead of using the loadbin command use loadfile.

    loadfile s110_nrf51822_7.0.0_softdevice.hex loadfile app_mac.hex

    Notice that you don't include any address when loading a hex file. This comes to the problem you were seeing: a .hex file has more info than just binary data to be loaded into memory. Info like the addresses where data should be loaded etc.. So you don't need to specify an address offset for hex files when programming them because this info. is included in the hex file.

    In case 1 you were reading back memory from the device so you would read back a binary file (just pure data). And thats why this worked. (even though you then saved it as a .hex file extension).

    In case 2 and 3 you actually had a hex file (Intel hex) which has more info and this probably screwed up JLink's loadbin as it was expecting binary data and got something else. (I guess Jlink didnt check that this was actually a .bin file)

Reply
  • Instead of using the loadbin command use loadfile.

    loadfile s110_nrf51822_7.0.0_softdevice.hex loadfile app_mac.hex

    Notice that you don't include any address when loading a hex file. This comes to the problem you were seeing: a .hex file has more info than just binary data to be loaded into memory. Info like the addresses where data should be loaded etc.. So you don't need to specify an address offset for hex files when programming them because this info. is included in the hex file.

    In case 1 you were reading back memory from the device so you would read back a binary file (just pure data). And thats why this worked. (even though you then saved it as a .hex file extension).

    In case 2 and 3 you actually had a hex file (Intel hex) which has more info and this probably screwed up JLink's loadbin as it was expecting binary data and got something else. (I guess Jlink didnt check that this was actually a .bin file)

Children
No Data
Related