What if corruption of STM32 option bytes is detected?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2023-12-06 11:13 AM - edited ‎2023-12-06 11:15 AM
Dear experts,
A question in relation to OB behavior discussed this thread: https://community.st.com/t5/stm32-mcus-embedded-software/stm32-is-getting-stuck-frozen-and-enables-read-out-protection-at/td-p/615228
Is there documentation or App note that explains what happens (by design or otherwise) when STM32 detect corruption of OBs during load? Especially, considering possible radiation damage, torture attacks etc. causing denial of service?
-- Pavel
- Labels:
-
Flash
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2023-12-06 11:36 AM
For the L4 (chip in question), which has complementary bytes to enable this sort of checking, behavior is specified in the RM:
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2023-12-06 12:06 PM
So let's see... BOR=0 assume OK... WRP none - assume OK. RDP level 1 - assume OK, can be recovered via debug interface... But RCROP on whole flash? this will cause immediate failure of firmware not built in the PCROP mode (execute-only). Results in denial of service.
