Andrew Zonenberg on Nostr: Ok, looks like I had maybe blank flash content but the ECC metadata was partially ...
Ok, looks like I had maybe blank flash content but the ECC metadata was partially written. Straightforward to just call the block partially written in this situation, fall back, and retry on a new blank flash block.
Where it gets scarier is when you have a half-written block that is malformed to the point of triggering a double ECC fault.
On STM32H735 a double flash ECC fault (sanely) triggers a data bus fault, which can be masked and the status register bit handled by application firmware easily enough.
But on STM32L431 it instead triggers a NMI. Which, by definition, can't be masked.
In order to avoid this forcing my board into a boot loop or hang every time I touch config flash, I need to be able to cleanly recover even in this scenario.
Whiiiich basically is going to involve implementing a SEH-like framework on ARMv7-M that can catch the NMI, return to application code with an error somehow, and cleanly recover.
Dis gon b gud. *rolls up sleeves and opens ARMv7-M architecture manual to study details of exception handling and stack frame unwinding*
Where it gets scarier is when you have a half-written block that is malformed to the point of triggering a double ECC fault.
On STM32H735 a double flash ECC fault (sanely) triggers a data bus fault, which can be masked and the status register bit handled by application firmware easily enough.
But on STM32L431 it instead triggers a NMI. Which, by definition, can't be masked.
In order to avoid this forcing my board into a boot loop or hang every time I touch config flash, I need to be able to cleanly recover even in this scenario.
Whiiiich basically is going to involve implementing a SEH-like framework on ARMv7-M that can catch the NMI, return to application code with an error somehow, and cleanly recover.
Dis gon b gud. *rolls up sleeves and opens ARMv7-M architecture manual to study details of exception handling and stack frame unwinding*