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

nrfjprog --program seems to be overwriting values I've written to flash with nrf_nvmc

Hi all,

I'm working on an application with the nrf52840, and I'm having trouble making data persist over reprogramming (Using nrfjprog); after I reflash my board, the data that I've previously written is gone. My app-level code uses the nrf_nvmc functions to write to flash. So my question is this: do I need to use fstorage, or some other set of functions different than nrf_nvmc, to write to flash? Or is it based on how I configure my flash, rather than what functions I use to write to it? I've seen posts abut setting DFU_APP_DATA_RESERVED to create reserved space, but these were always in relation to DFU, rather than reflashing using nrfjrpog. Is there a difference between the two? Or should what works for one work for the other?

Thanks.

Parents
  • Hi, 

    The user data should not be overwritten as long as it doesn't overlap with the new application FW assuming you are not doing a full chip erase during reprogramming. 

    • nrfjprog --program *hex --sectorerase // erases necessary flash pages to fit the new program file.  

    Is the user data stored in a separate section of flash ensuring that it is not overwritten when you upload the new app?  

  • Hi Vidar,

    Thanks for the reply. I am not sure if I am programming into a separate section or not. The drivers that I've written use the `nrf_nvmc_write_bytes` function to write, and I am writing to addresses between 0x00 and 0x40. To be honest, I'm not sure where that is in the memory map. I had assumed that address 0 would automatically be set to just above the application and softdevice locations in memory, but perhaps that is not the case.

    After doing some more research, I think that the problem may be that I am using nrf_nvmc to write directly to the flash, but those operations are illegal while the softdevice is enabled, and I should be using fstorage instead, as it can be compatible with an enabled softdevice. I think that this may be my core problem, but I am still curious as to where in the memory map 0 lies when used as an address in a flash write. I am assuming that I will have to rework my drivers with fstorage rather than nrf_nvmc, and so I will still need to ensure that I am writing to the correct location.

Reply
  • Hi Vidar,

    Thanks for the reply. I am not sure if I am programming into a separate section or not. The drivers that I've written use the `nrf_nvmc_write_bytes` function to write, and I am writing to addresses between 0x00 and 0x40. To be honest, I'm not sure where that is in the memory map. I had assumed that address 0 would automatically be set to just above the application and softdevice locations in memory, but perhaps that is not the case.

    After doing some more research, I think that the problem may be that I am using nrf_nvmc to write directly to the flash, but those operations are illegal while the softdevice is enabled, and I should be using fstorage instead, as it can be compatible with an enabled softdevice. I think that this may be my core problem, but I am still curious as to where in the memory map 0 lies when used as an address in a flash write. I am assuming that I will have to rework my drivers with fstorage rather than nrf_nvmc, and so I will still need to ensure that I am writing to the correct location.

Children
Related