Skip to main content
KPN1
KPN1
Associate II
July 15, 2022
Question

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

  • July 15, 2022
  • 2 replies
  • 1074 views

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

This topic has been closed for replies.

2 replies

waclawek.jan
waclawek.jan
Super User
July 15, 2022

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
KPN1Author
Associate II
July 17, 2022

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

Terms & ConditionsAccessibility statement