UICR values not stable

[Andrea Lombardo]

During the End Of Line test of one of our device, based on nRF52832, we write the serial number of the device in some non volatile registers, specifically CUSTOMER[8] and CUSTOMER[9].

We realized that some time the writing procedure was failing, leaving in the registers something very similar, but not equal, to what was intended to be written.

For this reason, we added a procedure to check the rightness of the writing and, in case of failure, the overall EOL test procedure fails and we reprogram the device starting from scratch.

Occasionally, it happens. It is annoying, but manageable (around 0.5% of cases).

What worries us more is what we have recently discovered. 

We have a couple of devices that present themselves with different names at different times. 

Usually the two names differ for just one bit. For example one of them it advertise itself as  AJTCDNZ" instead of AJTWDNZ".

The difference between the right character is just one bit: 0x43 vs 0x53.

How is possible? Is possible that sometime CUSTOMER memory region is written "poorly" and the readback is "volatile"?

Please see below the code we use to write the CUSTOMER registers. We are trying to get the device back to further investigate and read back the memory area via JTAG, to see if the content of the area is valid and persistent.

Thank you for your thoughts.

Andrea

// Switch off SD and BLE 

if (!BLE_and_SD_DEInit()) return;

CRITICAL_REGION_ENTER();

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

uint32_t chunk;

chunk = 0;
for (uint8_t i = 0; i < 4; i++ )
{
chunk |= bf[i] << (i * 8);
}

NRF_UICR->CUSTOMER[8] = chunk;
while (NRF_NVMC->READY == NVMC_READY_READY_Busy){}

chunk = 0;
for (uint8_t i = 0; i < 3; i++ )
{
chunk |= bf[i + 4] << (i * 8);
}

NRF_UICR->CUSTOMER[9] = chunk;
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){}

CRITICAL_REGION_EXIT();
return;

[Jared]

Hi,

The code looks ok. 

What worries us more is what we have recently discovered. 

We have a couple of devices that present themselves with different names at different times. 

Do you mean that the UICR register change in the field after you have verified that the correct value is writing during production?

regards

Jared

[Andrea Lombardo]

Yes, exactly. This is what looks that happens.

Thanks

Andrea

[Jared]

Hi,

Does any of the other registers in the UICR change or is it just the CUSTOMER registers? Do you write to the UICR any other place in your application? Are you using a bootloader?

regards

Jared 

[Andrea Lombardo]

Hi,

UICR are written only during production phase. Specifically, customer[8] and customer[9] are written only after the reception of a special command from the cloud to give a name to the device. 

Yes, there is a bootloader on the board, but we have not released any OTA yet, so the device in the field is running with the same fmw version it was produced.

See the extract from the database in our cloud system

as you can see, the device presents itself as ATJGDNZ that is its proper name, but it happens that it reports AJTWDNZ.

It looks that one bit has not been programmed to 0 "well enough" as the difference between the two character is just one bit.

I never rule out firmware bugs, but if the fmw should zero that bit, this would be forever and it will not show up high again after few seconds.

Any thoughts?

Thanks

Andrea

[Jared]

Hi,

Ok, so you haven't checked the register directly, you've only by checked via the cloud? The UICR register bits can only be flipped once before you have to erase the flash. If it switches between 0 to 1 without an erase, then it means that it's probably something else that is the problem such as your application. Could you check the registers directly on a sample by using the SWD interface and reading out the UICR?

regards

Jared 

[Andrea Lombardo]

I have asked the customer to return the device. Hopefully I should have it here within two weeks. In the meantime I have upgraded the firmware to another device that was switching between two configurations. The modification was in the reading routine of the UICR register. I read them for 1 seconds (do not know how many times) and I return the value only if every reading is coherent. So far I did not get any wrong reporting, but it is early to say (usually they report the wrong number every 2 days). I was thinking it could be related to battery power or GPRS RF field power.

I will update the ticket with some news as soon as I get the device or I have more robust findings from the one that have been reprogrammed.

[Jared]

Hi, 

Andrea Lombardo said:

I was thinking it could be related to battery power or GPRS RF field power.

It's plausible that an unstable supply would give wrong readings, but in that case the power supply supervisor should do a brownout reset. Could you also check the reset register when your receive the device?

regards

Jared