Tool/software:
I have a long-running product whose new firmware build started to fail occasionally when subjected to heavy incoming serial port traffic. Using the analysis tools built in our firmware and a debugger I have been able to isolate the problem to very specific part of the firmware code.
The firmware reads the UCARXBUF (UART mode) repeatedly using TST.B instruction, even if there is no pending character. (Do not ask why; but I have not found any document that forbids reading the UCA0RXBUF even if UCRXIFG is not set.) However, sometimes, like once per 1000000 executions, the CPU jumps over the subsequent instruction with no apparent reason.
Because this subsequent instruction is RETA, jumping over it causes the execution to flow into completely incorrect path rendering the device nonoperational.
0x37C64 TST.B 0xC(R12) ; this instruction reads UCA0RXBUF (R12=0x05C0)
0x37C68 RETA
0x37C6A MOVA R13,0x8(R12) ; unrelated instruction that should be never executed but is anyway sometimes executed after 0x37C64
0x37C6E RETA
Whenever the execution is halted by a breakpoint on the not-to-be-executed instructions, State Storage shows that the execution has indeed skipped over RETA instruction at 0x37C68:
The occurrence probability and the fact that there must be incoming bytes for this to happen gives me a feeling this is related to situations where UCRXIFG is set by hardware at the ~same time when the RXBUF is read. However, UCRXIE and GIE are set, so all incoming characters should trigger interrupt processing but no interrupt processing can be seen in the State Storage. (State Storage shows "Irq=1" shortly after the TST.B instruction reading the RXBUF. Why it is there and why no interrupt processing started if it was an interrupt?)
I cannot find any advisory on MSP430F5437A errata that could cover this kind of execution runaway. What is happening and how to ensure the reliability of the firmware? Of course I could add a dummy instruction after reading the UCA0RXBUF but without any confirmation of the root cause I cannot be sure that it would fix the issue reliably. Undocumented behavior should not happen on CPU in the first place anyway.