USART stuck condition, waiting on TC? CTS? STM32F411

[apullin]

Posted on August 18, 2017 at 01:13

So, I have a system here that I recently observed a non-reproducible lockup in, so I rushed over and attached a debugger to the running target to see where the problem was.

I saw that the UART driver code (at an SDK level outside of STM's HAL) was busywaiting for TC=1 after firing off a DMA transmit.Of note may be that the USART is set up with RTS/CTS to communicate with another STM32 micro, which was apparently alive and running (although I had no way of debugging the state of the UART peripheral on that end).Also of note is that SR.CTS = 1 at the time.

I have not quite been able to parse from the manual what state the UART might have been in, especially due to the mention of both nCTS for the pin state and SR.CTS for the status register.

As far as I can tell, none of the interrupts are enabled, and the intended usages is to initiate DMA and then busywait for completion.What could cause a waiting situation like this, with no TC = 1, but SR.CTS = 1?#uart #usart #stm32f411

[Tesla DeLorean]

Posted on August 18, 2017 at 02:13

I'd generally be wary of viewing the USART via the debugger, there are bit flags that change based on register being read, by whomever. ie You, the debugger, interrupt callbacks, etc.

Ideally pull data from you own USART code and loops, and push telemetry via the SWV channel. Using a logic analyzer on the pins, along with GPIOs you have reflecting internal register states, etc could also help.

I prefer TXE over TC, assume it's waiting on the USART TC not the DMA TC as these are different things.

Make sure the DMA hasn't faulted. Make sure TXE indicates the USART is empty.

TC will only go to one if TXE=1 when the last bit shifts out for the last byte.

Watch for race conditions, or bit manipulations which could result in TC being cleared. The processor cannot act on the peripheral atomically, so RMW actions can be problematic.