Repository navigation
machine/rp2: report SPI DMA bus errors - #6012
Conversation
SPI.Tx returned nil after a DMA bus error during a write-only transfer. The error flags stayed set, so the next transfer on that bus hung with no clocks. Tx now returns ErrSPIDMA and the next transfer succeeds. Tested on RP2040 and RP2350. Fixes tinygo-org#6011
|
@deadprogram i'm going to have a stab at sending a commit to tinyhci to see if we can lock this in with a test as the setup and testing required some messy logic probe shenanigans IMG_2810.MOV |
|
This is outside the scope of this PR, but I wonder about concurrent SPI access. We had to handle synchronization between cores and interrupts quite carefully in USB CDC (#5391). Could SPI need similar consideration, especially with the cores scheduler? Or is synchronization expected to be handled by the caller? |
Good question, many things need to come in pairs with the cores scheduler. Let me test this tomorrow |
deadprogram
left a comment
deadprogram
left a comment
There was a problem hiding this comment.
Thanks @davecheney now merging.
Write-only SPI transfers on RP2040 and RP2350 return nil after a DMA bus error. The next transfer then hangs with no clocks. Report the error and allow the next transfer to complete.
Fixes #6011.
Hardware tests on both chips used builds that also contained tinygo-org/tinygo#6010. This branch has not been tested without that change.
The SPI0 traces below show both chips before and after the fix. SPI1 gave the same result. Before the fix, the test watchdog stops the stalled call after about 1 ms. This is not a driver timeout. After the fix, the next call sends all 64 bytes without watchdog action.
Fault on the first DMA read
Fault after 16 bytes