2023-10-02 12:27 PM
When transmitting with a UART on this H747 board, a sent string will only get through two characters before HAL_UART_Transmit() hangs. No matter how I format the string (e.g., with or without snprintf() ), this same behavior occurs for UART8 and UART4.
HOWEVER, what I found is that I simply change the number of stop bits from 1 to 2, the entire string successfully transmits. The timeout value in HAL_UART_Transmit() has no effect (I've tried up to 1000).
The attached file shows the UART configuration details. The picture doesn't show these settings shown below. No other settings (NVIC, DMA, GPIO) have been altered from their default settings.
TX and RX Pins Swapping - Disable
Overrun - Enable
DMA on RX Error - Enable
MSB First - Disable
Does anyone have any idea why 2 stop bits work but 1 fails?
Solved! Go to Solution.
2023-10-04 04:02 PM - edited 2023-10-04 05:06 PM
The problem was two things:
1) There is a 44.1KHz timer interrupt routine, and its service routine takes about 20% of the CM4's time. Somehow that has an effect on the 9600 bps UART.
2) On the same UART8, there is bursty data being received but not serviced.
I've moved the UART and its associated code over to CM7 and the problem has disappeared. That is, I can use 1 stop bit and the UART transmit packets are perfect every time.
I suspect that the 44.1KHz timer interrupt was the biggest source of the problem, but the incoming and un-serviced receive data on the same UART has some effect when it's connected, too, because I see it affecting the Tx side over on the lightly-loaded CM7 core.
EDIT: When I use HAL_UART_Transmit_IT() on CM7 then receiving data bursts on the Rx side has no effect on the Tx side. I tried to use HAL_UART_Transmit_IT() when this UART servicing was on the CM4 side, but it just did not work. I'm not sure if that was due to the 44.1KHz timer interrupts.
2023-10-02 04:22 PM - edited 2023-10-02 04:23 PM
> Does anyone have any idea why 2 stop bits work but 1 fails?
Let's be objective here. Probably isn't a huge hardware bug that causes the peripheral to fail after 2 characters. So if it's not the hardware, it's probably a bug in the program, or a bug being exposed by a slight change to timing. Just because 2 stop bits "works" doesn't mean the bug isn't here. Showing more code is going to lead to more informed answers.
Debug the code, hit pause when it's "hangs", where is the CPU execution at? What is preventing it from continuing? How are you determining that it hangs? Are you viewing the characters in a terminal or logic analyzer or something else?
Try a UART example from the CubeMX repository. Does it work? That should rule out quite a bit.
Reduce the code to the bare minimum, where you initialize UART and call HAL_UART_Transmit on a single constant string. Does that work? Also rules out quite a bit.
2023-10-04 04:02 PM - edited 2023-10-04 05:06 PM
The problem was two things:
1) There is a 44.1KHz timer interrupt routine, and its service routine takes about 20% of the CM4's time. Somehow that has an effect on the 9600 bps UART.
2) On the same UART8, there is bursty data being received but not serviced.
I've moved the UART and its associated code over to CM7 and the problem has disappeared. That is, I can use 1 stop bit and the UART transmit packets are perfect every time.
I suspect that the 44.1KHz timer interrupt was the biggest source of the problem, but the incoming and un-serviced receive data on the same UART has some effect when it's connected, too, because I see it affecting the Tx side over on the lightly-loaded CM7 core.
EDIT: When I use HAL_UART_Transmit_IT() on CM7 then receiving data bursts on the Rx side has no effect on the Tx side. I tried to use HAL_UART_Transmit_IT() when this UART servicing was on the CM4 side, but it just did not work. I'm not sure if that was due to the 44.1KHz timer interrupts.