Hello,
I am working with a custom board communicating via USB-2-USART IC (FT234XD-R). Upon power up, the board operates as expected. I can communicate with the device . After some time--usually 60sec or so, but not perfectly periodic-- the device will stop responding. Using a logic analyzer, it shows the FT234 is still sending data to the chip, but the chip is not responding.The graph below shows a power up, communications start, MCU stops responding and reset button restores COMS indefinitely. I have left the board running for 24hrs and do not see the same issue after reset.
Using the hardware reset button on the board, I can reset the MCU and no longer have any issues. A few debugging techniques I have tried so far:
- Debug mode w/ break points
- Setting an LED flash if UART config changes or breakout of main loop
- Printf or LED flash within the HAL lib error function void Error_Handler(void)
Current band-aid
Setting the independent watchdog fixes the issue, but I would like the resolve, rather than band-aid, the issue.
Background information
STMCUBE v 1.14
USART2 with RX and TX both using the DMA on different channels.
Configuration
Initialization
HAL_UARTEx_ReceiveToIdle_DMA(&huart2, (uint8_t*)uartRxBuffer, RX_BUFFER_MAX);
Callback structure
Debug mode w/ break points
When operating in debug mode I am unable to recreate the issue. Everything works as intended after power-up. I no longer have to click the hardware reset.
{
/* USER CODE BEGIN Error_Handler_Debug */
/* User can add his own implementation to report the HAL error return state */
__disable_irq();
TIM21->CCR1 = 60000;
while (1)
{
}
/* USER CODE END Error_Handler_Debug */
}
Setting an LED flash if UART config changes or breakout of main loop
This debugging method did not show an relevant information. The UART would stop responding, but we never entered the error handler or broke out of the main loop.
Let me know if more information is needed. Thanks for stopping by!
Isaac.
Hello all,
Thank you for your responses. Update on data gathering. What complicates the issue is I can not recreate it when trying in debug mode, so I've had to set flags and visuals to see if certain blocks of code run.
Question 1: Could it be my code outside of the UART COMS?
Answer 1: When not communicating with the board. I do not see a reset, so thus the watchdog is getting pet and all is well. I do not believe there to be problematic code outside of the information I have presented. If the board were reset by the watch dog, we would see an anomaly int the heart beat pulse in red seen below.
Question 2(Tesla DeLorean :( UART isn't holding any sticky errors like noise, parity, framing, over-run, etc
Answer 2: I checked that the UART error callback is not called and checked the interrupt was enabled. (Watch dog is disabled now so I can glimpse into the issue) From the graph you can see that COMS start and everntually the MCU stops responding. In my UART error callback I turn off the heart beat light PWM, but notice that it never reaches that block of code from the graphs perspective.
Question 3(Karl Yamashita:( HAL_UARTEx_ReceiveToIdle_DMA returns busy & dead in the water
Answer 3:As a quick check if this would be the culprit, I put the HAL_UARTEx_ReceiveToIdle_DMA right in my main loop to be consistently re-initialized. From the graph, you can see that the issue still arises.
Great call out. I will be sure to add this redundancy checking in my code.
