This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

UICR

Hello,

during production test we wrote in the UICR a signature saying that the test has been performed succesfully. 

It happens that the signature is not written correclty. Some bits are zero instead of one. THe supposed signature is 0x04 0x11 0x17 0x05 and I got 0x07 instead of 0x17.

It does not happen often, but it is annoying (roughly one chip every 100).

I have copied below the procedure we use to store the info into UICR registers.

Before running this test, the chips are erased (using the chip erase functionaltiy) with a Segger ATE programmer, so I suppose that the register content should be completed 0xFFFFed before running the code below. 

https://www.segger.com/products/production/flasher/models/gang-programmer-flasher-ate/

But maybe it is not and this is the cause of the issue. Are you aware of any problem in the Segger algorythms?

Is the procedure to write UICR correct?

Thanks

Andrea

int signProductionTest(uint32_t signValue)
{


// Switch off soft device
BLE_and_SD_DEInit();

NRF_NVMC->CONFIG = (NVMC_CONFIG_WEN_Wen << NVMC_CONFIG_WEN_Pos);
while (NRF_NVMC->READY == NVMC_READY_READY_Busy) {}
NRF_UICR->CUSTOMER[1]= signValue;
while (NRF_NVMC->READY == NVMC_READY_READY_Busy) {}
NRF_NVMC->CONFIG = (NVMC_CONFIG_WEN_Ren << NVMC_CONFIG_WEN_Pos);
while (NRF_NVMC->READY == NVMC_READY_READY_Busy){}

return 0;
}

and this is the other function involved in the matter:

void BLE_and_SD_DEInit(void)
{
uint8_t sd_enabled;

sd_softdevice_is_enabled(&sd_enabled);

if (sd_enabled)
{
kippy_ble_adv_stop();

sd_clock_hfclk_release();

softdevice_handler_sd_disable(); 

sd_softdevice_disable();
}

}

  • On the off chance you are not aware of this "UICR can only be written nWRITE number of times before an erase must be performed using ERASEUICR or ERASEAL" where nWRITE is 181 times. Each write to any location within UICR counts as one of those 181 times, even if the same data is written to the same location. Failure following too many writes (> 181) is evidenced by some '1' bits being read as '0', never the other way round. The errors are also marginal, depending on VDD and number of total writes.

    So .. does anything else write to any part of UICR? Including all those UICR writes in SystemInit() in system_nrf52.c?

    For the code presented above, the safe correction would be to at least apply the following conditional test:

    // Never write to any part of UICR unless a change is required
    if (NRF_UICR->CUSTOMER[1] != signValue)
    {
       blah blah
    }

    Also not good to ignore the returned error code from trying to turn off the softdevice:

    // Switch off soft device
     result = BLE_and_SD_DEInit();
     
     if (result == shan't) uh_oh

Related