Open Dirbaio opened 1 year ago
I cannot reproduce this on f4.
Here is my local diff relative to current master:
Here are the tests that I have done. Note that I use usart2 instead of usart6. I have adjusted the interrupt priorities accordingly. The priorities does not seem to make any difference.
1) Loopback:
Simply short the rx and tx pin.
Build embassy-stm32-tests
with cargo build --bin usart_rx_ringbuffered --release --features=stm32f429zi
.
The output from defmt
gives an indication that the test runs.
2) With host PC.
Wire rx pin to a serial port on a pc.
Build embassy-stm32-tests
with cargo build --bin usart_rx_ringbuffered --release --features=stm32f429zi
.
Run the build firmware.
Run test-utils
with cargo run com2 --idles
.
The output from defmt
gives an indication that the test runs.
Setting a lower DMA_BUF_SIZE
to, say 64 bytes gives me immediate overrun errors.
I think I am getting the same issue, if I am recreating the Uart instance on each loop iteration it works fine, but if use it constantly it stops working after a few kB received, doesn't metter if the rx buffer is 256 or 512, it stops basically always at the same point. Sometimes it does recover after a few secs more but not always. What is strange is that this does seam to only happen on USART2, my program uses USART6 too and even more data goes through it and it works perfectly fine. My MCU is STM32F401RET6.
@dragonnn Could you try and assign the same interrupt priority to USART2 as you have on USART6, and verify that it still does not work?
I am running default interrupt priority and as far I can tell both are running at P0? Using this code to check:
use embassy_stm32::{
interrupt::{InterruptExt as _, Priority},
pac::Interrupt,
};
info!("current usart2 priority: {:?}", Interrupt::USART2.get_priority());
info!("current usart6 priority: {:?}", Interrupt::USART6.get_priority());
How about the dma priority? USART2 uses DMA1 and USART6 DMA2.
It is actually strange, as if not configured, USART2 and DMA1 should have default higher priority than USART6 and DMA2 according to table 38 in the resource manual.
I guess it is not a priority issue then.
Hmmm
0.003969 INFO current usart2 priority: P0
└─ <mod path> @ └─ <invalid location: defmt frame-index: 309>:0
0.004005 INFO current usart2 dma1 ch6 priority: P0
└─ <mod path> @ └─ <invalid location: defmt frame-index: 310>:0
0.004042 INFO current usart2 dma1 ch5 priority: P0
└─ <mod path> @ └─ <invalid location: defmt frame-index: 311>:0
0.004117 INFO current usart6 priority: P0
└─ <mod path> @ └─ <invalid location: defmt frame-index: 314>:0
0.004153 INFO current usart6 dma2 ch6 priority: P0
└─ <mod path> @ └─ <invalid location: defmt frame-index: 315>:0
0.004189 INFO current usart6 dma2 ch1 priority: P0
Does embassy zero out all priority?
steps to reproduce:
cargo run --release --features stm32f103c8 --bin usart_rx_ringbuffered
sample output: https://gist.github.com/Dirbaio/49fae6ef02747bcdbd3ad2df5e5f6671
repro on f4:
cargo run --release --features stm32f429zi --bin usart_rx_ringbuffered