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

Writing to UICR from application code

Hello,

I am truing to store data in the UICR register "customer area" from application code. The procedure is invoked only once when the registers are still empty. The code is as follows:

void write_to_uicr()
{
        uint32_t data_to_write;

        uint32_t err_code = sd_softdevice_disable();
        APP_ERROR_CHECK(err_code);

        interrupts_disable();
        //...

        data_to_write = get_data();

        NRF_NVMC->CONFIG = NVMC_CONFIG_WEN_Wen << NVMC_CONFIG_WEN_Pos;	
        while (NRF_NVMC->READY == NVMC_READY_READY_Busy){}
        *(uint32_t *)0x10001080 = data_to_write ;
        NRF_NVMC->CONFIG = NVMC_CONFIG_WEN_Ren << NVMC_CONFIG_WEN_Pos;	
        while (NRF_NVMC->READY == NVMC_READY_READY_Busy){}

}

Unfortunately the only data written to the registers is 0x00000000 even though I can verify with the debugger that the value of the "data_to_write" variable is different than zero and it is as expected. Optimizations are switched off. I would be more than glad to get any input on this problem. Thank you in advance!

Parents
  • 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.

Reply
  • 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.

Children
Related