BLE does not work after writing a value to UICR

[alex kim]

Hi, Everyone

My Environment: nRF52840, SDK15.3, Keil

My code is:

err_code = nrf_sdh_disable_request();
APP_ERROR_CHECK(err_code);

NRF_NVMC->CONFIG = NVMC_CONFIG_WEN_Wen << NVMC_CONFIG_WEN_Pos;
while (NRF_NVMC->READY == NVMC_READY_READY_Busy){};

NRF_UICR->CUSTOMER[AES_KEY0] = aes_key0;

NRF_NVMC->CONFIG = NVMC_CONFIG_WEN_Ren << NVMC_CONFIG_WEN_Pos;
while (NRF_NVMC->READY == NVMC_READY_READY_Busy){};

err_code = nrf_sdh_enable_request();
APP_ERROR_CHECK(err_code);

BLE works before writing data to UICR

However, after writing data to UICR, the name does not appear when scanning from nRFconnect.

Please advise.

[Einar Thorsrud]

LarsH said:

Does this mean that if you allocate 5 pages you can perform 50 000 writes?

 No, much more than that, depending on how large sections of data you write. You will continue to fill up a flash page with every update. Data will not be overwritten until you do a garbage collection, which is typically after you have written to all reserved flash pages. You can calculate this yourself, just remember that there is a flash page tag of 2 words (8 bytes) and a record header of 3 words (12 bytes).

For example, a page is 1024 words (4096 bytes), so if you are writing data that is 16 bytes that is 4 words, this means that you can write (1024-2)/(3+4) = 146 times to each page without overwriting anything. And so on, until you do a garbage collection. And when you do a garbage collection, data is shuffled so that you can delete pages. And so on. You can read up on the detail in the FDS documentation, but the key here is that you can significantly increase the life span of the flash by this approach.

[LarsH]

Thus, you get a lifetime of 1.46 million updates (ie 166 years) on a single flash-page with one hour key exchange.

That should be sufficient, I think! :-)