Posted on January 04, 2017 at 17:56Hi all,
I'm wrestling with a couple problems with UART interrupt receive. Processor is STM32F745IET6 on a custom board. Startup code is generated using CubeMX 4.18.0 and HAL library version 1.5.1. (This all seems to be current.) The project includes LwIP and FreeRTOS. USART6 is configured for asynchronous operation with interrupts and DMA enabled. I'm using character by character interrupt input and DMA output for modest buffer sizes - up to about 100 characters at this point.
This code works without difficulty in a separate project with UART baud rates up to 115200. When combined with the present project I am running into two likely related problems. (Reducing baud rate to 9600 seems to make no difference.) First, I am seeing a lot of DMA FIFO errors on the UART on output. They seem to occur after the data is sent. (This goes to a terminal emulator so I can see what has been sent.) If I ignore the DMA FIFO errors then console input to my application causes an overwrite of a FreeRTOS variable that results in a failed assertion. The variable being overwritten is assigned once on startup (by FreeRTOS) so it is easy to track the overwrite by setting a data write breakpoint on that variable. What I have found is that the UART handler has a negative receive character count when the breakpoint triggers and the buffer pointer does not point to where it should. Relevant code includes initiation of UART read:
&sharpdefine UART_HANDLE huart6
&sharpdefine UART_RCV_BUF 1 // character by character input
static uint8_t uartRcvBuf[UART_RCV_BUF];
st = HAL_UART_Receive_IT(&UART_HANDLE, uartRcvBuf, UART_RCV_BUF);
The place where the data breakpoint was triggered (line following the write) was line 1655 in stm32f7xx_hal_uart.c. At that point huart->RxXferCount is 65530 which seems to indicate that the counter has been decremented past zero. The huart->pRxBuffPtr is 0x2000B6B2 and the address of the buffer passed to the call above is 0x2000B6AC. The address of the variable being overwritten is
0x2000B6B1.
I haven't tracked exactly where the bug happens but it is pretty clear that the driver has gotten out of bounds with the data pointer. This input is from me banging on a keyboard so I don't think it is an overrun issue. I don't bang that fast.
Any help resolving this is most welcome! And I should remind that there seem to be two problems. First the DMA FIFO error and second it seems to provoke a bug in the driver. Perhaps I am misusing library APIs but I tend to think that no
use of an API should result in this kind of error.
Thanks!
#uart-fifo-error-dma
