I am using an STM32L562VET6Q. My device contains both a (custom) bootloader and an application. The bootloader jumps into the application by reading the address of the Reset_Handler from the application's ISR vector then branching to this address. I have had absolutely no issues with this until the other day. I performed a firmware upgrade on a group of devices after which about 10% ceased responding. I placed a few of these on a debugger and they all, after branching to the application, throw an Undefined Instruction Hard Fault at the same instruction. This is not happening immediately at the start of the application but after hundred of instructions in. Keep in mind, this exact same firmware is running without issue on the other 90%. I have performed the following tests:
- I downloaded (via the debugger) the contents of the flash memory and compared it to the image I uploaded. They match byte-for-byte (which is what I expected since the bootloader hash check passed)
- I re-flashed a failed chip with the image using the debugger. The device still throws the same fault
- I looked at the PC pushed into the stack by the fault handler to see at which address the fault was occurring. Looking at the list file, the instruction at this address is perfectly valid.
- I downloaded the complete contents of a faulting device's flash, replaced the MCU on the board with a new MCU, then flashed this new chip with the image I cloned. The chip now boots without faulting.
- I replaced the MCU on a working board with the one I removed in (4). Now this board faults. This leads me to the conclusion that this fault is related to the MCU itself and not the surrounding hardware.
- I added a DSB and ISB instruction right before the branch to the application (thinking that the pipeline might hold a bad instruction after the branch). This made no difference.
- Both the bootloader and application have the instruction cache enabled. I disabled the instruction cache in the bootloader (without changing the application image). The device now boots without issue.
- I had the debugger break just before the address at which the fault occurs in the application and stepped through each instruction. When stepping, the fault does not occur and the application boots normally.
At this point, I am forced to the conclusion that something in internally wrong with specific chips in combination with the specific sequence of instructions/addresses that are being executed. Based upon my testing, it appears to be related to the instruction cache. I believe the instruction cache is somehow becoming "corrupted."
I have looked through the errata for this chip, but have not found any related entries to this issue. I would appreciate any further debugging steps I can follow to narrow down this issue.
