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*
Andrew Zonenberg /
npub1wp…rf386
2024-06-21 05:24:45
in reply to nevent1q…j6xl
Author Public Key
npub1wpgh8qdt8suzxy8f2luspksj4wpdfw53weq4v8dr7llqp3t72tds3rf386Published at
2024-06-21 05:24:45Event JSON
{
"id": "304475b729312c33e2e79ddb61c4eb9890e97314eb2c5b978a1b889120690919",
"pubkey": "70517381ab3c382310e957f900da12ab82d4ba917641561da3f7fe00c57e52db",
"created_at": 1718940285,
"kind": 1,
"tags": [
[
"e",
"04d64d6b62bfc56daff01943aa486cc56699efc3f844469263f0f389288f7932",
"",
"root"
],
[
"p",
"70517381ab3c382310e957f900da12ab82d4ba917641561da3f7fe00c57e52db"
],
[
"proxy",
"https://ioc.exchange/@azonenberg/112652470552423269",
"web"
],
[
"proxy",
"https://ioc.exchange/users/azonenberg/statuses/112652470552423269",
"activitypub"
],
[
"L",
"pink.momostr"
],
[
"l",
"pink.momostr.activitypub:https://ioc.exchange/users/azonenberg/statuses/112652470552423269",
"pink.momostr"
]
],
"content": "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.\n\nWhere it gets scarier is when you have a half-written block that is malformed to the point of triggering a double ECC fault.\n\nOn 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.\n\nBut on STM32L431 it instead triggers a NMI. Which, by definition, can't be masked.\n\nIn 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.\n\nWhiiiich 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.\n\nDis gon b gud. *rolls up sleeves and opens ARMv7-M architecture manual to study details of exception handling and stack frame unwinding*",
"sig": "186df0a81205b9bd1934fcc0a8fd41952a13c438287c14758635402162d2c6d609ace665a5f90665c9812ed594183635b47d9626a00ced7e7cf08133e67760f3"
}