nrfjprog --programs <hex_file> [--dfu]

[Rocky Liang]

Hi there,

I am using the nrfjprog to flash the nrf51822 via a J-Tag programmer. Here is the command I used in the command prompt:

nrfjprog --eraseall --programs softdevice.hex --program application.hex bootloader.hex --verify --reset

During the programming process, it prompts me this warning message:

"WARNING: Since the option "--dfu" was not given, the SoftDevice will include UICR settings. Please be aware that Device Firmware Update of the SoftDevice will not be possible with these settings."

Then, I included the "--dfu" in the command

nrfjprog --eraseall --programs softdevice.hex --dfu --program application.hex bootloader.hex --verify --reset

The SoftDevice (in Region 0 when the "--dfu" was not given) became in Region 1. I tested these two configuration on my device. They both worked. Is there any difference when SoftDevice is sitting at Region 1?

I tried to look for some information on the "--dfu" option. But I found no clear information.

--programs "hex_file" [--dfu] Programs the specified hex into the device. In addition, checks that the hex file is a well constructed SoftDevice: It contains a the FWID either in the UICR or the SoftDevice itself, it contains a valid value for the length of the SoftDevice, does not contain any data above the afore mentioned length, and only writes into SoftDevice reserved space in UICR. Can be combined with the erase operations, the reset operations and the other programming operations. If dfu option is given and the SoftDevice allows it, the device will not be run time protected. otherwise, the UICR.CLENR0 will be written. It will automatically disable the MPU NVM protection regions if enabled and enable it again after the program operation.

Thanks so much in advance for your help.

Cheers, Rocky

[Susheel Nuguru]

Hi Rocky,

First of all please update your nrfjprog tool as you seems to be using outdated version.

regarding your question, below is the text from Series Reference Manual from chapter UICR "The code area can be divided into two regions, code region 0 (CR0) and code region 1 (CR1). Code region 0 starts at address 0x00000000 and stretches into the code area as specified in the CLENR0 register. The area above CLENR0 will then be defined as code region 1. If CLENR0 is not configured, that is, has the value 0xFFFFFFFF, the whole code area will be defined as code region 1 (CR1).

Code running from code region 1 will not be able to write to code region 0. Additionally, the content of code region 0 cannot be read from code running in code region 1 or through the SWD interface if code region 0 is readback protected, see PR0 in RBPCONF.

The main readback protection mechanism that will protect the whole code, that is, both code region 0 and code region 1, is also configured through the UICR."

softdevice running as CR1 does not effect anything except that that application which is also in CR1 can modify softdevice code, also if you want readback protection enabled,it wont work if softdevice is located in CR1.

[Mike]

hi Aryan, thank you for your feedback. Just a quick follow up on your comments

1. if I want to implement the ability to update softdevice through Bluetooth DFU, should it be located in region 0 (without --dfu command) or located in region 1 (with --dfu command)?

2. does having readback protection affect DFU through Bluetooth at all?

Cheers, Mike

[Susheel Nuguru]

1. it does not matter, both should work just fine

2. do not enable readback protection in UICR->RBPCONF. Memory protection must be disabled to allow Device Firmware Upgrade of the SoftDevice

[Mike]

hi Aryan, regarding point #2, it seems like I am able to do DFU on the softdevice still even with the read back protection enabled. at this point, it doesn't pose any problems for me, though I would like to understand why my experience appears to be different from what you said. cheers.

[Susheel Nuguru]

Are you writing anything to UICR.CLENR0 explicitly from your application or nrfGo studio? if not then RBPCONF does not do anything as there is no code region 0 to protect. All the flash will be CR1 in that case. My second point was for cases which have written something to CLENR0. If there is a valid valude in UICR.CLENR0 and RBPCONF is set and your DFU is working then i need to know few things.Which version of Softdevice are you using? if it is taken from SDK7.x then i think the bootloader is reading the information it needed from UICR. After SDK7.x softdevice does not write to uicr by default and all the information bootloader needs is located in CR0 If CR0 is protected by RBPCONF then DFU cannot retrieve softdevice information. devzone.nordicsemi.com/.../