Add documentation to dma_channel_abort regarding errata RP2040-E13 #816
Conversation
…ossible spurious IRQ during channel abort)
| * not require any additional work, as aborting a channel which may be about to complete, when you have a completion | ||
| * IRQ handler registered, is inherently race-prone, and so code is likely needed to disambiguate the two occurrences. | ||
| * | ||
| * If that is not the case, but you do have an channel completion IRQ handler registered, you can simply |
There was a problem hiding this comment.
"an channel completion" -> "a channel completion"
|
I fixed the typo pointed out by @lurch. I also made another change, which might be more contentious, so feel free to back out: poll BUSY rather than ABORT to check for ABORT completion, to guarantee the channel is returned to a quiescent state before the function exits. ABORT clears prematurely due to the erratum (in fact this is the erratum). The difference in timing is the time taken for the in-flight transfers to drain from the bus FIFOs, which should be a few cycles. |
There was a problem hiding this comment.
Approval for the docs updates, @kilograham please merge if you are happy with the ABORT -> BUSY polling change
|
Does the ABORT->BUSY change have an effect on what happens if the channel is disabled? |
|
No. BUSY clears once the in-flight and not-yet-issued transfer counts both reach 0. The not-yet-issued count is cleared by the ABORT, and EN=0 does not prevent in-flight transfers from completing. |
| * | ||
| * Function will only return once the DMA has stopped. | ||
| * | ||
| * Note that due to to errata RP2040-E13, aborting a channel which has transfers |
There was a problem hiding this comment.
Another typo: "to" is twice.
|
Note I force merged this as the only change after approval was a type in a comment |
4 participants
See raspberrypi/pico-feedback#224
Note this is a documentation only fix, as
dma_channel_abortdoes not have enough information to efficiently workaround the issue on the callers behalf.