• State Verified Answer
  • +1 person also asked this people also asked this
  • Replies 5 replies
  • Subscribers 75 subscribers
  • Views 1289 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 249591
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

NRF_ERROR_STORAGE_FULL after DFU update

Martin Huber

In our project we use a nrf52832 with softdevice S132 and SDK15.3.

For booloader we use the DFU example form the nordic library.

After a DFU with BLE, which was done without any errors, we have now one device which crashes as soon as the BLE stack starts. (1of about 100)

That device Returns now an NRF_ERROR_STORAGE_FULL error after the fds_init() call.

Unfortunately a fds_gc() call won't be accepted since the fds_init() was refused and therefore the fds module is not initialized.

What can be done to overcome that problem?

Why could we get a corrupted flash area (peer settings) after DFU?

Thanks in advance

Martin

Parents
  • 0

    Hi,

    Please make sure the bootloader 'NRF_DFU_APP_DATA_AREA_SIZE' setting matches the size of your app data region (Memory layout). This will prevent the bootloader from overwriting/corrupting FDS pages during the DFU process. FDS may fail to initialize if the pages have been partially or fully overwritten.

    Best regards.

    Vidar

  • 0 in reply to Vidar Berg

    Hi Vidor,

    thanks for your Reply. We have an external flash in that Project, so we have to store only a few bytes in the application which is done with the uicr Register. Therefore we do not store application data on the flash. Anyway the 'NRF_DFU_APP_DATA_AREA_SIZE' is set to 4096 which should be sufficient for the fds module and as I mentioned, we saw that issue on one device of more than 100. The main problem is not that it could happen but that there is no mean to recover the issue (without a programer / debugger). Is there a way to recover the flash area (which is used in fds module) with the SDK when something like that happen?

    Regards,

    Martin

  • 0 in reply to Martin Huber

    Hi Martin,

    FDS requires a minimum of 2 flash pages as it reserves one page for swap. The total number of pages is configurable in sdk_config header and should as mentioned correspond with the NRF_DFU_APP_DATA_AREA_SIZE size setting.

    FDS can initialize even if it's not able to claim all data pages, but it will not initialize if the SWAP page has been corrupted. And swap is moved every time you run Garbage collection so maybe that explains the low failure rate in your case.

    The easiest way recover would be to fully erase the flash pages you have allocated to FDS  followed by a NVIC_SystemReset(). Would that be an option? All stored data will obviously get lost in the process.

Reply
  • 0 in reply to Martin Huber

    Hi Martin,

    FDS requires a minimum of 2 flash pages as it reserves one page for swap. The total number of pages is configurable in sdk_config header and should as mentioned correspond with the NRF_DFU_APP_DATA_AREA_SIZE size setting.

    FDS can initialize even if it's not able to claim all data pages, but it will not initialize if the SWAP page has been corrupted. And swap is moved every time you run Garbage collection so maybe that explains the low failure rate in your case.

    The easiest way recover would be to fully erase the flash pages you have allocated to FDS  followed by a NVIC_SystemReset(). Would that be an option? All stored data will obviously get lost in the process.

Children
Related
Terms of service