Closed bluehash closed 5 years ago
@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:
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
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.
Perfect, I will update code as it makes sense to do the check. Commit https://github.com/MaJerle/STM32_USART_DMA_RX/commit/e916a5971b269cfa321e71be98ba5032202857cc
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