sd_flash_write function sometimes writes zeroes instead of expected data

[embGangsta]

When enabling BLE on nrf52840, we are using specific API to access flash erase and write commands. All is working fine 99% of the time in term of read / write / erase into flash when BLE softdevice is enabled but however in some rare cases, I can see that sd_flash_write function writes zero values in flash instead of expected buffer data and I can't understand the reason ...

Is it a known problem ? Do we need to take care about something special when reading back to memory after write operation in sd_flash_write ?

We are using softdevice S140 6.1.1 version

[Einar Thorsrud]

Hi,

I have not found any reports of sd_flash_write not successfully writing all data. Also, erased flash is all '1's, so all '0' means something was written. Did you ensure that the target page was erased in the first place (which would make all bits '1')? Also, do you make sure to not touch the source buffer before the write has completed? Perhaps you can share your code?

[embGangsta]

Hi,

Yes the sector has been erased, I was able to check it by reading back data after and before the area where data was supposed to be written. Right after the erroneous 0s, we have FFFFFFs and before we have correct data from previous correct write operation.

I also verified that source buffer was not 0 right after the use of sd_flash_write.

However what are the expected timing to make sure sd_flash_write will effectively perform the write ? Is there a potential delay to take into account ?

[Einar Thorsrud]

Hi,

embGangsta said:

However what are the expected timing to make sure sd_flash_write will effectively perform the write ? Is there a potential delay to take into account ?

Yes, there is a  delay, and it is not easily predicted. The key point here is that sd_flash_write() is asynchronous. It will return immediately, and the SoftDevice will schedule the flash write when it fits with other activities (typically in between BLE events). Therefor the source buffer must remain intact until you get a NRF_EVT_FLASH_OPERATION_SUCCESS or NRF_EVT_FLASH_OPERATION_ERROR.

[embGangsta]

Thanks for confirmation. Indeed our driver is correctly design as per this requirement, but in my case I have maybe buffered too much that now need to be written for too long time and then buffer is updated before buffer is completely written to flash.

I am receiving data regularly from a caracteristic and I write this data in flash for firmware update purpose. The data occurs by packets of max 20 bytes (MTU size) but timings are never really "fixed". We have however an average of 1kbytes/s for datarate. I am buffering data in order to do less calls to sd_flash_write. I designed a sort of "ping pong" write scenario so that A is written to flash when B is fed with new data, but in my case it seems some write occurs too late or one of A/B part is filled too quickly ....

I did buffering to perform 32bit data grouping because writes in flash are made on word size multiple.

Now I certainly need to make a tradeoff with the size of buffering so that writes will be done in time.

For information my A / B  buffers are 240bytes each, I must probably have to reduce this size.

[Einar Thorsrud]

Hi,

I see. The key is that it is your responsibility to ensure that the buffer remains intact until the FDS operation has completed. Exactly how you do that is up to you. If it is difficult to do this elegantly, then you can simply use a dedicated buffer for flash writes that you copy your data to, and then use that for writing to flash, and ensure you never write to it again until the last flash operation has completed.