USART stops working after two/some days in STM32L475RCT7 microcontroller.

[Shakthi]

We are facing problem with USART in STM32L475RCT7 microcontroller. Recently we have migrated an existing product from MCU stm32f103rct7 family to STM32L475RCT7.

All code changes are done properly and migration was successful. The product communicates with other hardware(xx) through USART over RS485 cable. The communication works fine for two days.

But after sometime our product (which is migrated with new MCU) did not respond to the other hardware (xx). The RS485 sniff shows that the xx hardware sends message to our product. But its clear that our product is not responding. This happens after running the communication for many hours. 

We did check the systick and priority of the USART used for RS485 communication. Everything looks fine. Unfortunately the issue occurs only at our customer site. We are unable to recreate the issue in our lab. The other USART ( actually there are three, our product uses only two of them) with lowest priority than the problematic USART works fine.

Are there any known problems with STM32L475RCT7 in USART peripheral driver ?

Note:The USART is interrupt driven. We dont uses DMA or code generated by cubemx tool.

I just created a debug firmware to dump all the register info to check the software sets (RXNEIE and TXEIE) like flags and others properly or not.

Should I need to track down any other register to get more information?

Please share your suggestions.

It is evident that the Transmission Complete interrupt is not generated by the MCU and caused the receiver to be in disables state. The TCIE flag is enabled and TXE bit is set after writing all the bits in TDR register. The communication works fine for sometime, but sooner the TC interrupt doesnot happen.

[TDK]

Gotta be a bug somewhere. I would check the OVR bit and make sure you're handling things fast enough and are also resilient to when things go wrong. Register info should help quite a bit.

[Tesla DeLorean]

On the newer parts you need to watch for and clear pending errors, especially NOISE and FRAMING errors.

[Shakthi]

Thanks for your response. I'm waiting for the issue to occur again with my debug firmware. I traced the registers that are associated with USART2. Lets see. Fingers crossed

[Shakthi]

Thanks Tesla for your response. I tried simulating the NOISE(NF), and FAMING Error (FE) by sending serial message @baud rate other than configured baud rate. I see the flags are set in the debugger. But still I see the communication is successful without clearing both flags.

Is there any other way can I simulate this scenario? ( By using hardware? as I know sending message with different baud rate is triggering the scenario by software method)

[ONadr.1]

Are you sure, that the only serial port is stucked? Perharps stucked MCU completely. Perharps some interference affect xtal oscilator or switching power suply. I would try testing the product in similar configuration and simulate similar data flows. When the problem not apear, it si very probably some HW problem or untreated HW situation (as oscilator failure ....) When problem appear, you have chance to detect the source of it.

[Shakthi]

Yes, I'm sure about it. Because, out of three USART , our product uses two peripheral. The one other than stuck works properly; meaning we are able to send and receive data through that USART. Also, our application code to raise some alarm events are working fine.

[ONadr.1]

Is the RS485 port galvanically isolated?

[Tesla DeLorean]

If the device continues to have a viable serial connection, or other PC connectivity, can you not add some diagnostic console or output that you could drive via TeamViewer or RemotePC at the customer site to perhaps better understand the nature of the failure, and query internal registers.

A basic diagnostic console/monitor could allow you to query/dump any memory sections in the device so you could inspect and understand better.

[Shakthi]

Yeah. As I mentioned in the issue description, I have already added a debug stuffs to dump registers associated with the problematic USART through the working USART.