cancel
Showing results for 
Search instead for 
Did you mean: 

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

Shakthi
Associate II

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.

16 REPLIES 16
Shakthi
Associate II

Yes, with proper protection

S.Ma
Principal

Anything of use in errata sheet? Any low power mode? Could therr be missing volatile or atomic configuration hw register issue? Use gpio which toggle under interrupt to check if it could be clock frequency shift. How about with and without hw dma?

Shakthi
Associate II

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.

Can you dig more using the other UART? Maybe dump NVIC state, syscfg... ?

Let me know what exactly should I get? I checked the NVIC, there are no pending interrupts for USART2. I can get the specific detail if you mention one.

ONadr.1
Senior III

At this stage, I would try to replace the MCU with another piece, preferably from a different series. It is very likely that this is a problem in the installed MCU.

Piranha
Chief II

It can be some bug in an ISR. For example, interrupt processing is delayed for some reason, TXE and TC interrupts are both pending, when the ISR starts, and code ignores the TC flag.