UART Glitch On Startup Causes Hardfault in FreeRTOS

[jefftenney (Jeff)]

@joe

None of the ISRs call FreeRTOS API as far as I can see.

This would be a rare design in my experience. Recommend reading Richard’s book here especially the preface and chapter 6.

@joe

If the interrupt is prevented in the area where the hardfault occurs, then it would make sense that this would work.

I’m not sure I agree. Interrupts and ISRs should not contribute to hardfaults any more than non-interrupt conditions and code.

@joe

I see that FreeRTOS cannot seem to run at a higher priority than the baremetal ISR

I think you mean that no matter a FreeRTOS task’s priority, any interrupt and its associated ISR always interrupts the task. That is true. Task priorities are completely different from interrupt priorities. Chapter 3 of Richard’s book will help there.

@joe

Reading the RX buffer after the FRAMING ERROR just before the TX/RX packet exchange also stops the hardfault from occurring.

I assume you are not talking about the USART’s RX buffer here – your code already reads that buffer after the framing error and before the TX/RX packet exchange. Instead I assume you are talking about an RX queue in software. If you pull the errant 0 byte out of the software queue before the parser consumes it, and if that solves your problem, that is an excellent clue.

@joe

Perhaps this is the time during which the stack is getting manipulated for a context switch and it is getting interrupted.

No, I don’t think so. FreeRTOS protects itself against such things by design.

Regarding your logic analyzer images, can you tell us what the edges mean? Are you toggling per function execution? Are you pulsing during function execution? etc.

Also what can you tell us about CalcAuth()? Do you have source code for it? Does it utilize hardware assist (like a CRC or AES module or similar)?

Finally, you may need analyze the hard fault using guidance here:

Debugging and diagnosing hard faults on ARM Cortex-M CPUs