how to enable readback protection

[nimalhuang]

Hi, Guys,

I am trying to enable the readback protection for the code region 0 and code region 1, I know that the NRF_UICR->RBPCONF register is flash_backed, so I have to include uicr_config.h file and uncomment the line
const uint32_t UICR_RBPCONF attribute((at(0x10001004))) attribute((used)) = 0xFFFF0000;

However, I use eclipse and gcc, so it seems the "at" keyword doesn't apply in eclipse gcc, so is there any equivalence in gcc or how should I enable this readback protection in the application but not using nrfgo, I know that the nrfgo can definitely do that. Thank you:)

[Clem Taylor]

I ended up putting quite a bit of stuff in UICR (128 bytes of user data and 512 bytes of crypto keys).

I have 2 sections, .infoUICR and .keysUICR, each contains a single structure (otherwise ld might swap the order)

xxxUICR.c:

xxxInfoUICR_t xxxInfoUICR __attribute__((section(".infoUICR"), used));
xxxKeysUICR_t xxxKeysUICR __attribute__((section(".keysUICR"), used));

xxx.ld:

MEMORY
{
        /* manufacturing time data (customer UICR region) */
        UICR (r)          : ORIGIN = 0x10001000, LENGTH = 0x080 /* 128 bytes */
        INFO_UICR (r)     : ORIGIN = 0x10001080, LENGTH = 0x180 /* 384 bytes */
        KEYS_UICR (r)     : ORIGIN = 0x10001200, LENGTH = 0x200 /* 512 bytes */
}
...
SECTIONS
{
        /* UICR info data (manufacturing time data) */
        .infoUICR (NOLOAD) :
        {
                KEEP(*(.infoUICR))
        } > INFO_UICR
 
        /* UICR key data (manufacturing time data) */
        .keysUICR (NOLOAD) :
        {
                KEEP(*(.keysUICR))
        } > KEYS_UICR
}

I ended up writing a host C program to build up the UICR data because I have several CRC values in the various data blocks. I also did not want the UICR data embedded in the bootloader hex file so the bootloader image for the factor and the bootloader image for DFU are exactly the same.

The host tool builds up the 1024 byte UICR page writes it to stdout as binary data which is converted to a hex file with bin2hex.py. The hex file I send the factory is a hexmerge.py of the softdevice, application, bootloader and uicr hex files.

[RK]

Did you ever get proper confirmation that the UICR really is and is guaranteed to stay a full 1024 bytes of FLASH which can be used and not just the documented 160 bytes with 32 reserved for customer use?

[Clem Taylor]

Nope, I didn't get a reply and I never bother to ask support or my sales rep. I really should ask. I suspect the answer will be something like 'yes it is 1K but we don't test the full 1K in production'.

I still have some time to move the key data out of UICR and stick it someplace else, but UICR seemed like a good place for manufacturing time data.

I'd be willing to bet that FICR is also a full flash page as well. I need to take one of the bits of broken hardware I have lying around and see if I can stomp on bits in FICR just by setting NVMC_CONFIG = 2.

[Hung Bui]

@Clem: user supposed to use only 128 bytes UICR from 0x10001080 to 0x100010FF to store user data. Accessing UICR outside of that area is not recommended. Please have a look at chapter 8 in the nRF51 Reference Manual. I would suggest you to use a normal flash page to store your key and info.