Strange Watchdog Behavior After OTA on STM32: Is Flash Corruption the Culprit?

Hello

I have been seeing a peculiar issue on an STM32L4 project after performing OTA firmware updates using a dual-bank bootloader. :slightly_smiling_face: Everything works fine after the first boot post-update but after several hours / a few reboots, the device consistently hits the watchdog.

This only happens after OTA updates not after a full flash erase-and-program via SWD. I’ve verified checksums & signature validation during OTA, and nothing seems to be obviously wrong. :innocent:

Interestingly; when the crash is inspected using Memfault’s core dump feature, it sometimes shows corrupted stack frames or invalid PC values, pointing toward potential flash corruption / memory boundary issues. :thinking:However, no such corruption is visible in the firmware image itself.

I am wondering if the issue could relate to incorrect cache invalidation, improper vector table remapping / even missed reinitialization of peripheral states after the bootloader hands off control. :thinking: Checked Robust OTA Updates For Linux Devices, the Easy Way | Interrupt with JIRA Course Online guide for reference .

Has anyone run into flash corruption or watchdog resets tied specifically to OTA scenarios on STM32 platforms? :thinking:Would love to hear if there are best practices or hidden pitfalls when dealing with ICache, DCache, or the bootloader reset vector handoff on STM32 MCUs.

Thank you !! :slightly_smiling_face: