STM32G0B1KC - USART stops receiving when external serial data starts transmitting during boot

[KPN1]

Code runs fine and decodes USART1 when the STM32G0B1KC boots up and then the external serial data starts transmitting. When the external transmission (38400Bd) is starting while the micro is booting up the Rx interrupt hangs after the first character is received.

Rebooting the micro after the receiver hangs often restores functionality even when the external data stream continues. But that is a poor way of recovering, I would rather resolve the underlying problem.

A little tricky to debug because of the timing. Everything is setup on STMCubeIDE using the HAL libraries. Has anyone seen similar behaviour before?

Happy to post some code snippets if needed, the whole receiver code is a bit long though.

Regards,

Peter

[waclawek.jan]

What do you mean by "hang"? Does it go into hardfault? Then debug it as you debug usually hardfaults. Or does it return to the ISR permanently? Do you handle UART errors? Or is "hang" something else? Then start there.

> Everything is setup on STMCubeIDE using the HAL libraries.

It doesn't matter, whatever "library" or clicking tool you use, the result is now your code so you have to debug it as such.

JW

[KPN1]

Thanks Jan,

OK, I should have been clearer. Here is a bit more detail:

The receive interrupt fires, but does not return new characters. It is aways the same character. It also does not show receiver errors. (But I will do more tracing to confirm that)

The application is a display circuit that reads a broadcast stream of characters. If there is not new data coming in, it shows standby. So with the receiver stopping it remains in standby.

Knowing that standby could mean the receiver has locked up I re-initialise the receiver hardware and clear the FIFO in the timeout routine. This does not reactivate the receiver hardware. Only a reset will.

The remainder of the code runs as expected, so this is not a hardfault as far as the CPU is concerned.

So my question remains: Is this a known error and has anyone seen this before?

Peter