During use of fStorage, getting error of NRF_ERROR_NO_MEM. Related to use of fStorage in custom bootloader application.

[rsoc16]

Hi,

I have implemented a custom bootloader/firmware package, but have recently been running into issues when integrating the two. I have found in some instances when using the fStorage library in my bootloader, then launching my application, I will get a NRF_ERROR_NO_MEM response to an fStorage erase command in the firmware. This is odd because I never see this issue, unless the bootloader used the fStorage to write or erase information prior to launching the application.

Is there some kind of de-init I need to do for fStorage to release memory before jumping to the new application? I currently am using the standard nrf_fstorage_uninit() which returns success, so I dont think there is an issue here.

Edit-- On further debugging, I've noticed that when I trigger any sort of write or erase of memory in the bootloader, the operation never completes. I always have a "busy" designation from the fStorage instance. Following this, the same observations on application launch apply.

Appreciate any and all help.

[Vidar Berg]

Hi,

Would you be able to upload your custom implementation here if I made the case private? I am afraid I cannot really think of anything obvious to explain why the fstorage issues would carry over to the main application, or why it's failing in the bootloader code.

I always have a "busy" designation from the fStorage instance.

A common reason for this is when Softdevice flash events are not propagated/forwarded back to the nrf_fstorage_sys_evt_handler(). This causes the fstorage queue to fill up because it never gets the confirmation from the softdevice when a flash operation is completed.

Best regards,

Vidar

[rsoc16]

Vidar

I converted the ticket back to public because i solved the issue and do not need to upload the problem code.

For reference to anyone that comes across this in the future, my issue was there was a memory overflow during a read out of fstorage in my bootloader. This was causing memory corruption in my RAM, and the memory overflow issue for fStorage actually carried over into the firmware, which is very surprising. 

Vidar-- is this expected for the library?

I say it carried over because the fstorage operations were faulting on account of no available memory after this call and jump to firmware application.

[Vidar Berg]

Glad to hear that you were able to resolve it, thanks for the update!

I would not say this is expected for the libary. The fstorage read operation is performed with memcpy() internally in the module, so there's is a potential for buffer overruns if the input arguments are bad. But I a memory corruption in the bootloader should not impact the application because RAM is re-initialized by the application's reset handler anyway.  

[rsoc16]

Thanks Vidar. 

Another follow up--you mentioned

Vidar Berg said:

events are not propagated/forwarded back to the nrf_fstorage_sys_evt_handler().

How do I ensure this is occurring? Is there a link operation I need to complete? I still see the busy designation sometimes, after heavier use post solving the memory corruption.

Also, is it good practice to call NVIC_SystemReset to restart the program with the bootloader, after downloading the application in the firmware? Will that reset any soft device IRQ handling? Or do I need to do a proper application jump? Let me know if that doesnt make sense.

[Vidar Berg]

I guess the easiest way to verify this would be to place a breakpoint inside the handler and see if it every receives a flash event from the Softdevice.

Depending on protocol activity, it may actaully be expected to occassionally get 'busy' errors. This is because flash operations need to be scheduled between as this chapter in the SDS explains: Flash memory API.

rsoc16 said:

Also, is it good practice to call NVIC_SystemReset to restart the program with the bootloader, after downloading the application in the firmware? Will that reset any soft device IRQ handling?

 I would say it's generally good practice to ensure the application boots into the same state whether it's after a DFU or normal system reset. Our bootloader ensures this by doing a NVIC_SystemReset() after having received the new FW image, but before jumping to the new app.