Writing to UICR from application code

RE: Writing to UICR from application code

GT — Tue, 08 Mar 2016 09:10:12 GMT

Thanks for the help RK! You were right my code was righting to the same memory location twice.

RE: Writing to UICR from application code

RK — Tue, 09 Feb 2016 11:15:35 GMT

Down to guesswork at this point. If the value is correct after the write, then the next logical guess is that you're writing it again somewhere else, either before the chip power cycles or straight afterwards, and putting in a different value. 0x0000220 is what you would get if you wrote 0x00001234 followed by 0x22222222, sure you're not doing that?

Can you set a memory write breakpoint at that address, segger supports those, which should tell you if you or something else writes there again.

RE: Writing to UICR from application code

GT — Tue, 09 Feb 2016 11:06:33 GMT

I am adding more details related to the problem in this post. In general the code that I am debugging is in two files. The first file contains a variable which is retrieved and stored in the UICR from the second file.

Data provider (provider.c):

 ...
static uint32_t data;
...

uint32_t get_data(void)
{
    return data;
}

UICR write (write.c)

...
extern uint32_t get_data(void);
...
static void update_uicr_customer_data()
{
    data = get_data();

    if(data != 0){
        NRF_NVMC->CONFIG = NVMC_CONFIG_WEN_Wen << NVMC_CONFIG_WEN_Pos;
        while (NRF_NVMC->READY == NVMC_READY_READY_Busy){}
        *(uint32_t *)0x10001080 = data;
        NRF_NVMC->CONFIG = NVMC_CONFIG_WEN_Ren << NVMC_CONFIG_WEN_Pos;
        while (NRF_NVMC->READY == NVMC_READY_READY_Busy){}
    }else
    {
        NRF_NVMC->CONFIG = NVMC_CONFIG_WEN_Wen << NVMC_CONFIG_WEN_Pos;
        while (NRF_NVMC->READY == NVMC_READY_READY_Busy){}
        *(uint32_t *)0x10001080 = 0x22222222;
        NRF_NVMC->CONFIG = NVMC_CONFIG_WEN_Ren << NVMC_CONFIG_WEN_Pos;
        while (NRF_NVMC->READY == NVMC_READY_READY_Busy){}
    }
}

With the debugger I can verify that the content of the "data" variable is "1234" after the function returns and this is what I expect to get as a result. Then the if statement is executed. The else is there just to prove that data != 0.

The content of the 0x10001080 at this point is:

0x10001080: 00001234 FFFFFFFF FFFFFFFF FFFFFFFF

However, after a power-cycle of the chip the content of the memory location reads back as:

0x10001080: 00000220 FFFFFFFF FFFFFFFF FFFFFFFF

Furthermore, if i replace the call to the external function with a call to function in the same file (write.c) the writing procedure goes as expected and the value is preserved after power-cycle.

It looks like I am doing something wrong, but I was blaming the UICR write... Do you have comments on this? Thank you in advance.

RE: Writing to UICR from application code

GT — Tue, 09 Feb 2016 09:42:40 GMT

I can verify with the debugger that it returns a legal values as expected. I will post another code snippet shortly.

RE: Writing to UICR from application code

Susheel Nuguru — Tue, 09 Feb 2016 08:24:51 GMT

get_data() seems to be biggest suspect here. I think it is returning 0 then.

RE: Writing to UICR from application code

RK — Mon, 08 Feb 2016 15:59:19 GMT

ok that makes zero sense then. At this point I'd put a breakpoint in the assembler at the point of the store and look at the registers at that level because I can't think of a reason it wouldn't work.

RE: Writing to UICR from application code

GT — Mon, 08 Feb 2016 13:38:12 GMT

The value of the UICR before I try to write to it is 0xFFFFFFFF. This is just after a full erase. However, if I try to write a hard-coded value instead of the content of the "data_to_write" variable, then it works:*(uint32_t *)0x10001080 = 0xAAAA5555

RE: Writing to UICR from application code

RK — Mon, 08 Feb 2016 13:28:00 GMT

What's the value in 0x10001080 before you do the write? UICR is like flash, it's non-volatile memory, which means you can only change bits from 1 to 0 in it. Then you have to erase it which sets it all back to 1s again before you can clear the bits again.

So if it has 0x00000000 in it before you start, that's all you're going to get, you can't set bits back to '1', nor, I believe can you erase the UICR from within program code.