nrf52833 - Partial flash erase best practices

[KWolfe81]

I am using nrfx_nvmc_page_partial_erase_init() and nrfx_nvmc_page_partial_erase_continue() to erase flash in-between wireless connection events.  The datasheet states:

"The bits in the page are undefined if the flash page erase is incomplete, i.e. if a partial erase has started but the total erase time is less than tERASEPAGE."

I am looking to add protection/ensure data integrity of flash in cases when the device is reset in the middle of the page erase (e.g. after calling *_init() and before *_continue() returns true). 

• When the device resets, can we trust flash was successfully erased if it reads 0xFF?
• If we write data to the page and read it back successfully, can we trust that it is fully written (e.g. the flash is not in some meta-stable state)?
• If I want to proactively stop the erase after beginning, can I write 0x00 to one of the bytes in the page to mark it as invalid?
  

If there are any other best practices regarding partial page erases, please do share.

[Kenneth]

Hello,

So in general: In the nRF Connect SDK, flash erase/write operations are synchronized with the BLE radio using Multi-Protocol Service Layer (MPSL)-managed timeslots (when MPSL is enabled). In practice, this means that if you use the standard Zephyr flash API on an nRF52833 (e.g. flash_erase()/flash_write() or higher-level storage like NVS/Settings) while BLE is running, the system will not perform the flash operation immediately in the middle of a radio event. Instead, the operation is deferred and executed in a radio idle window obtained via the Multi-Protocol Service Layer’s timeslot mechanism. MPSL essentially coordinates flash access with the BLE stack to avoid timing conflicts. So the absolute simplest is just to use the flash api as-is, even if that means it may skip a few connection intervals while executing an erase operation which is timing consuming, but to answer your questions:

When the device resets, can we trust flash was successfully erased if it reads 0xFF?

Not until this has occurred: ""The bits in the page are undefined if the flash page erase is incomplete, i.e. if a partial erase has started but the total erase time is less than tERASEPAGE.""

If we write data to the page and read it back successfully, can we trust that it is fully written (e.g. the flash is not in some meta-stable state)?

Yes, the CPU will be blocked during the necessary time to write, so once CPU resumes you can trust the content. Presuming of course that the page have been erased the necessary time in the first place.

If I want to proactively stop the erase after beginning, can I write 0x00 to one of the bytes in the page to mark it as invalid?

Bits that are written to 0 cannot go back to 1 without an erase no. The only way for a bit to go from 0 to 1 is through an erase, and it should do that for a total of tERASEPAGE to ensure it's a 1.

Edit: I was tipped off that partial erase is also supported by the zephyr driver, so it is not needed to use nrfx directly, see:
https://github.com/nrfconnect/sdk-zephyr/commit/143f9bfd4e1aed2320d46df6de4dbf1d09f4d69d 

Kenneth

[KWolfe81]

Kenneth,

Thank you for the reply. Without going into detail, my product is very timing constrained on our chip and cannot use the standard zephyr APIs.

I will need to drill down into this a bit more and be explicit about the situation.

1) If we can't trust a read of 0xFF, what should we do if the device resets mid partial erase (for instance, the user removes the battery)?

2) If we write data to a page that didn't get fully erased (such as in my question above), what is the expected result?  Can we trust that newly programmed data if it reads back correctly?

[Kenneth]

KWolfe81 said:

1) If we can't trust a read of 0xFF, what should we do if the device resets mid partial erase (for instance, the user removes the battery)?

My suggestion would be to write a magic word somewhere in the page after a full erase is done. 

KWolfe81 said:

2) If we write data to a page that didn't get fully erased (such as in my question above), what is the expected result?  Can we trust that newly programmed data if it reads back correctly?

You can't really rely on anything in that case.

Kenneth

[KWolfe81]

Thank you!

[KWolfe81]

Kenneth,

Sorry to be annoying - I want to be REALLY clear.  You meant to write "CAN" and not "CAN'T" in the sentence:

You can really rely on anything in that case.

Right?