nrf52833 - Partial flash erase best practices

RE: nrf52833 - Partial flash erase best practices

Kenneth — Tue, 27 Jan 2026 23:31:02 GMT

Have in mind that when you write to flash, you are turning ones to zeros. You are not doing the ones any better until a complete erase.

RE: nrf52833 - Partial flash erase best practices

Kenneth — Tue, 27 Jan 2026 23:28:22 GMT

Sorry. It should be "can't" yes.

Fixed it now.

Kenneth

RE: nrf52833 - Partial flash erase best practices

KWolfe81 — Tue, 27 Jan 2026 21:50:57 GMT

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?

RE: nrf52833 - Partial flash erase best practices

KWolfe81 — Tue, 27 Jan 2026 16:28:44 GMT

Thank you!

RE: nrf52833 - Partial flash erase best practices

Kenneth — Tue, 27 Jan 2026 15:33:52 GMT

[quote user="KWolfe81"]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)?[/quote]

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

[quote user="KWolfe81"]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?[/quote]

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

Kenneth

RE: nrf52833 - Partial flash erase best practices

KWolfe81 — Tue, 27 Jan 2026 15:26:50 GMT

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?

RE: nrf52833 - Partial flash erase best practices

Kenneth — Tue, 27 Jan 2026 08:44:18 GMT

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:

[quote user=""]When the device resets, can we trust flash was successfully erased if it reads 0xFF?[/quote]

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.""

[quote user=""]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)?[/quote]

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.

[quote user=""]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?[/quote]

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