STM32WL Seeed E-5 UART2 HAL DMA won't work unless an APP_LOG is present int the main while(1) loop.

[NBrad.1]

I am currently using the Seed E5 chip with LoRaWAN. I need to get data from a uart system through the uart2 (Pins PA2 and PA3). If I add in an APP_LOG displaying the data recieved from UART2 in the main while loop, then the uart2 works fine, but if I remove it the uart2 never runs.

When I step through the program with the debugger, I find that it always fails at the huart reception type line.

 if (huart->ReceptionType == HAL_UART_RECEPTION_TOIDLE)
 {
 __HAL_UART_CLEAR_FLAG(huart, UART_CLEAR_IDLEF);
 ATOMIC_SET_BIT(huart->Instance->CR1, USART_CR1_IDLEIE);
 }

My code for the UART2 is almost line for line from the uart example made by STM (found here https://github.com/STMicroelectronics/STM32CubeWL/tree/main/Projects/NUCLEO-WL55JC/Examples/UART/UART_ReceptionToIdle_CircularDMA)

The only notable difference is that I am also using UART1 and I am running LoRaWAN along side the UART stuff.

I am pretty new to UART and to the STM32WL and would appreciate any help on this issue.

[TDK]

> I find that it always fails at the huart reception type line.

Fails in what way?

Setting the IDLEIE bit could cause it to jump into the interrupt.

[NBrad.1]

When the program hits line 1, the results end up as false and the code goes right into the error handler. Most of the time the error flag is set to 8 (ORE), but sometimes it is set to 0, no matter the case, the uart does not work. I have tried resetting the flags when an error is called, but that did not work. I have tried setting up the uart in several different ways, but the results always end up the same, I end up in the error handler.

The device I am listening to is running at BUAD9600. The uart is set up in the STM MX Cube to match the buadrate. I am using a ringbuffer to avoid overflow. I have even tried setting the buffer to some absurdly high value to ensure there wasn't an overflow error. None of these things worked.

I am really new to STM32 development and I am not quite sure if I am doing this right.

I guess I should note, that I am following the LoRaWan example from the github I linked above and then I added the uart example on top of it.

[TDK]

Not real sure. Stepping through with the debugger can be invasive. For example, reading the DR register will clear the RXNE flag. In addition, if there is data coming in and your debugger is paused, you can get an overrun. If ORE is set, you received a byte that wasn't processed by the time the next byte came in.

ReceptionType is set by HAL command so I don't see why that would be set incorrectly.

[NBrad.1]

I figured that stepping through the program was changing results, which is what has made tracking down the root problem so difficult. The other difficulty that I am running into is that I haven't found any examples of LoRaWAN, UART1 and UART2 all running on the same device. I have only seen the 3 programmed separately, and for whatever reason they are not playing nicely together.