S130 v2 Soft device size in future and protection

[Jon (jono)]

Hi

Question

What is the risk/chance that future revisions (>2.0.0) of S130 will be incompatible with the setting UICR.CLENR0 = 0x1C000?

Background

Today we would like to use S130 V2.0.0 and set UICR.CLENR0 to 0x1C0000. We will then only be able to upgrade to a soft device having a size <= 0x1C000 since we cannot erase UICR once product leaves factory.

Alternately we could use a soft device partitioned in such a way that any code residing after 0x1C000 does not touch protected peripherals or memory, but then that would need to be provided by Nordic.

Not programming UICR.CLENR0 seems not to be an option since at least the call

    sd_mbr_command_t com = {SD_MBR_COMMAND_INIT_SD, };
    err_code = sd_mbr_command(&com);

changes NRF_MPU.RLENR0 to 0x08 which later causes a hard fault in sd_softdevice_vector_table_base_set() at 0x00019C96 STR r0,[r1,#0x00], r1=0x20000004

---

As described in comments below, later I was not able to reproduce the setting of NRF_MPU.RLENR0 to 0x08. Reason for not being able to reproduce is unclear, but could possibly be related to clearing of low ram. I have not been able to prove this.

Answer to main question:

Yes, if you intend to update the firmware on the chip then you should not set the CLENR0 register.

[bjorn-spockeli]

Setting UICR.CLENR0 to 0x1C0000 will prevent you from updating the SoftDevice in the future. If the SoftDevice size increases, then parts of the SoftDevice will be located above the address set in CLENR0, resulting in that part not being able to access the other parts of the SoftDevice. The same situation will occur with the application if the SoftDevice size decreases, parts of the application will be protected against itself.

There should not be any issues with leaving the CLENR0 unset, i.e. 0xFFFFFFFF.

-Bjørn

[Jon (jono)]

Hi, and thanks!

2 followups:

• Do you recommend us to leave protection off? (main question)
• I have confirmed this not working when run as above from boot loader. Crashes in S130 V2.0.0 @0x00019C96 on store to protected RAM (writes to addr 4, ram-protection set to 8 -> mpu fault (ram protection set by MBR on SD INIT))
• Now 0xFFFFFFFF works, reason why is unclear. Could be related to clearing low ram 0x20000004..0x20002800.

[bjorn-spockeli]

Yes, if you intend to update the firmware on the chip then you should not set the CLENR0 register. Ok, so if you do a full erase of the chip and re-flash the firmware, the device does not enter the hardfault handler with the CLENR0 set to 0xFFFFFFFF?

[Jon (jono)]

Hi,

Q1: thanks.

Q2: Yesterday i got hard fault with UICR.CLENR0==0xFFFFFFFF (set ram prot to 8 in _SD_INIT), i then changed UICR.CLENR0 to 0x40000 and worked around some issues with that. Today I added clearing of ram and changed back to 0xFFFFFFFF after seeing a compare to that value when stepping in mbr or softdevice. Now the verry same code (but with ram cler) that didn't work yesterday works. (I also write to NRF_MPU.RLENR0 in the keil load script to place flash alg in protected region, after loading I reset NRF_MPU.RLENR0 to 0 in the same script. Since I dont have the source to MBR and init of SD, the understanding when stepping is quite sparce... but theres somthing that I miss out here..., now i cannot reproduce the hard fault any more...)