Within RP1, DMA requests are handshake-based with request-acknowledge semantics. FIFO levels and thresholds are converted to a pending-request flag before being fed into the handshake FSM.
If the FIFO is very slow to clear the flag after reads, it could be the case that the DMA is retriggered after the acknowledge phase. But reading through relevant parts of the verilog, the FIFO and the flags are all using the undivided clock.
What's more likely is that the FIFO threshold doesn't match the configured DMA burst size. There's the rp1-specific pio_sm_set_dmactrl() in piolib that can alter the threshold but there's other bits in the respective control register that need preserving.
rp1sm <x> dumps the hardware state of the respective PIO state machine. Can you invoke this when your PIO program is running, note the dmactrl_rx value, then use this in your program to call pio_sm_set_dmactrl with the bottom 4 bits of the "ctrl" argument overwitten to 0x0..0x8 in sequence?
If the FIFO is very slow to clear the flag after reads, it could be the case that the DMA is retriggered after the acknowledge phase. But reading through relevant parts of the verilog, the FIFO and the flags are all using the undivided clock.
What's more likely is that the FIFO threshold doesn't match the configured DMA burst size. There's the rp1-specific pio_sm_set_dmactrl() in piolib that can alter the threshold but there's other bits in the respective control register that need preserving.
rp1sm <x> dumps the hardware state of the respective PIO state machine. Can you invoke this when your PIO program is running, note the dmactrl_rx value, then use this in your program to call pio_sm_set_dmactrl with the bottom 4 bits of the "ctrl" argument overwitten to 0x0..0x8 in sequence?
Statistics: Posted by jdb — Wed Jan 07, 2026 2:47 pm