Programming nRF51 bootloader with nrfjprog.exe 7.5.1

[Adrian Eggenberger]

Hi

I've installed the new tools in version 7.5.1 to support the new nRF52 family. While working on the nRF51 again i found out, that the old parameters i used for programming my bootloader are not working anymore. Old call: nrfjprog.exe --reset --program "bootloader.HEX"

This call programmed my bootloader at address 0x3C000 and programmed the bootloader address in the UICR page (if not already done).

I adapted my call to work with the new tool and ended in the following call: nrfjprog.exe --family NRF51 --program "bootloader.HEX"

The problem is, that it only works if the UICR bootloader address is not yet written. If the same value already is programmed an error occurs.

How can we reach the same behaviour with the new nrfjprog?

Regards Adrian

[Susheel Nuguru]

normally this should work

nrfjprog.exe --eraseuicr
nrfjprog.exe --erasepage 0X3C000-0X40000
nrfjprog.exe --reset --program "bootloader.HEX"

But i have problem with --eraseuicr not working for pca100028 with nrfjprog version: 7.5.1 JLinkARM.dll version: 4.98c

EDIT:

--eraseuicr is not available on nRF51 chips if it is not pre programmed with software at the production time. So you probably have to erase full chip if you want to write your bootloader file.

nrfjprog.exe --eraseall
nrfjprog.exe --reset --program "bootloader.HEX"

[Adrian Eggenberger]

Thank you Aryan. I'll use the old version for nRF51 until an update is released.

[Susheel Nuguru]

Hi Adrian, I am sorry, I have forgotten that --eraseuicr option on nRF51 chips is only available if the chip is pre factory programmed. In your case it is not so --eraseuicr will not work. I have edited my answer.

[Adrian Eggenberger]

Oh i didn't see that either. Will there be a corrected version of the nRF tools that can work the same way as the old version did?

[Susheel Nuguru]

No, I think the newer tools will always check that the memory they are writing to is erased (clean) before writing, this is diverging from old versions behavior.

[Adrian Eggenberger]

That would make development of bootloader parts a lot harder, because before programming a new bootloader the chip has to be erased (all data and application gone). In my opinion this would be a step backwards. In general i agree that the nrfjprog should check if area to be programmed is clean, but for the UICR it brings a lot of negativ consequences.