2023-04-03 05:24 PM
STM32L496 micro is hard faulting when power is cycled, but only on some builds of firmware, others are ok. I've been able to track it down to a specific path in the assembly, what looks like is happening is a vector table address is loaded into R3 with and LDR command, and then a branch is done to that address with a BX. Sometimes, it seems to grab the address in the vector table but off by a byte. Here's a brief summary:
How it should work:
LDR R3, [R0] ---> R3 = [0x20001188] = 0x080422F0
LDR R3, [R3, #8] ---> R3 = [0x080422F8] = 0x0801E421
BX R3 ---> branch to addr 0x0801E421
Vector Table data:
[0x080422F8] = 0x0801E421
[0x080422FC] = 0x0801E441
But what I see sometimes on reboot with a hardfault and the core dump shows:
R3 = 0x410801E4
Which is actually the proper data but as if it was read off by one byte (that is, reading from 0x080422F9 not ...F8). NOTE the MSB is the LSB of the next address from above in the vector table. When changing the code, that byte (41 here) will change but always shows up like that in the fault, so I'm pretty confident it's referencing the address but off by a byte.
NOTE: This never happens in debug mode, stepping through the code, but is quite repeatable just cycling power.
I know the cortex m4 uses Thumb instructions, and the thumb uses bit[0] set to '1'. Is this somehow not properly jumping in this one path of the code and why only certain builds?
2023-04-26 05:37 AM
Hello @BEdwa.2,
Please provide minimal amount of code/configuration necessary to reproduce the issue.
To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
2023-04-26 05:44 AM
Without the debugger you can instrument the code and add sanity checks.
I'd work backward to how the value gets written in RAM
Seems oddly placed/aligned for the actual Vector Table. Needs to be placed on 512 byte boundary.
Going to need more context..