New rules of UICR.CLENR0 for SOFTDEVICE V8.00?

[xc0903]

Hi, I updated to softdevice 8.00 recently, and found something different with softdevice 6.00.

When trying to program the new softdevice hex to the chip using nrfgo studio v 1.15, it fails. But using the "flash_softdevice" target of Keil project is OK, and the new example ble_hrs runs perfectly. Then I found the new softdevice is invisible from the nrfgo studio, implying something changed (I guess it's the UICR.CLENR0 identified the code region here).

Then I read the code of DFU. There's something different with the code in 6.00.

#define SOFTDEVICE_INFORMATION_BASE     0x0003000   
#define SOFTDEVICE_INFORMATION          ((SOFTDEVICE_INFORMATION_Type *) SOFTDEVICE_INFORMATION_BASE)   
#define CODE_REGION_1_START             SOFTDEVICE_INFORMATION->softdevice_size

The new code_r1 is defined by a new structure in 0x0003000, not by UICR->CLENR0. But the comment says:

/**< This field should correspond to the size of Code Region 0, (which is identical to Start of Code Region 1), found in UICR.CLEN0 register. This value is used for compile safety, as the linker will fail if application expands into bootloader. Runtime, the bootloader will use the value found in UICR.CLEN0. */

So I print them in my code. The UICR.CLENR0 is really 0XFFFFFFFF, and the SOFTDEVICE_INFORMATION->softdevice_size is 0x1c000 for s130 and 0x18000 for s110 (as same as the value in the example project setting). It seems that the system adopts a new mechanism here rather than the original UICR. But I can not find any documents about it. The newest specification I found is 3.0b, in which the UICR.CLENR0 is still valid. Can you explain this for me? Thank you very much.

[Susheel Nuguru]

Softdevice does not write to UICR.CLENR0 by default now. I think this has changed in 7.x. This means that by default softdevice is not protected and readback is not enabled. As you have noticed, softdevice size is located inside a structure located at memory address 0X3000. Application can write to UICR.CLENR0 if it wants to protect softdevice and make few peripherals restricted to application.

The reason for not writing to CLENR0 register now is to allow softdevice upgrades by DFU which could be larger in size than set in CLENR0 register. But once this register is written, it cannot be changed in DFU, because DFU will not be able to erase UICR registers as it only erase pages, never does an eraseall. I probably have confused you, please ask anything if you need more clarifications.

[xc0903]

Thanks for your explanation. It's late because visiting here is slow in China. Best wishes!

[Susheel Nuguru]

xc0903, ff this answer helped you then please click the ✓ to the left of the answer so that others can come and look here.