OK, first, I'm not including code quite yet because I want to see if anyone has heard of this problem. Code is available, though.
What I want: USART to act as a console USART driving a queue for reception, and being fed by a queue for transmission.
Details: FreeRTOS latest in the packs, STM562VETQ processor, custom hardware. CubeMXIDE 14.1.
Software, from the archives/examples, the one that uses the LPuart and L5 processor.
Copying the software (direct blocking transmit, circular DMA buffer scanned and read out to external buffer) and running it (changing LPUART to UART1) works perfectly. This is the direct bare metal application transported over with the USART changed. NO FreeRTOS used. So far, so good.
Main Program from CubeMXIDE, sets up tasks, etc, calls bridge program (C++) which starts main program task (C++). For this test, main program task is disabled. DMA example moved into separate C module. FreeRTOS running.
Program does not work.
if (HAL_OK != HAL_UARTEx_ReceiveToIdle_DMA(&CONSOLE_USART, CONSOLE_aRXBufferUser, CONSOLE_DMA_BUFFER_SIZE))
{
Error_Handler();
}
to be specific, the program hangs somewhere in the call to HAL_UARTEx......, does not return to the program.
If I put a breakpoint at this line, then single step through it, the program is likely to work, and this is with FreeRTOS running.
"Timing Problems, says I"
Disabling all references to FreeRTOS (in this module and the main module where needed.....
Program works.
I'm not familiar enough with the innards of the drivers to be sure where the problem is. I looked at Majerle's solution, but other than using low level drivers, it looks remarkably similar. I have a similar problem in my own version that uses DMA receive. The DMA doesn't happen and seems to be that the USART is never interrupting anything.
Anybody heard of this kind of thing happening? Suggestions?
