usart_process_data() gets called with zero length

[bluehash]

Hello, thanks for sharing this framework. I've ported the F4 project to IAR here: https://github.com/bluehash/STM32_USART_DMA_RX

One thing I've noticed is that usart_process_data() gets called with zero length. It is as if the IDLE line interrupt takes over when the DMA HT/FT finishes. I'm not sure if there is a way to ignore this. If I have alot of data coming in, that is a good number of interrupts that use up CPU cycle time with zero length.

I put in a simple check here(https://github.com/bluehash/STM32_USART_DMA_RX/commit/e2a180a7f5f1310a15a7303da12f15b407ec0aca) so that I can breakpoint the code.

I've also added a test under idle_line_irq_rtos_F4/test using TeraTerm. My environment: STM32F413ZH Nucleo Board IAR 8.30.2

[MaJerle]

@bluehash this happens (as you pointed already) when IDLE is detected on HT/TC events and then DMA holds same number in first and second process. To avoid these scenarios you may:

• Increase RX buffer to have HT/TC events less often
• Make sure device on the other side sends data in a bursts rather than byte-per-byte (to avoid triggering often IRQs)

However, there is a check if old_pos != pos which should prevent this behavior. I believe this happens only when in overflow mode when usart_process_data is called twice in a row. Here it may be necessary to add check if pos > 0 before calling second time: https://github.com/bluehash/STM32_USART_DMA_RX/blob/master/projects/idle_line_irq_rtos_F4/Src/main.c#L132

[bluehash]

Works great with the pos > 0 fix(https://github.com/bluehash/STM32_USART_DMA_RX/commit/fa784fcd3d999bba90dca3457ffd8e181f2976f2), as usart_process_data gets called again with zero length with pos = 0.

[MaJerle]

Perfect, I will update code as it makes sense to do the check. Commit https://github.com/MaJerle/STM32_USART_DMA_RX/commit/e916a5971b269cfa321e71be98ba5032202857cc