Its an internal error which should never be exposed. It should only
occur with wrong driver implementations. We log to the user and return
an Overrun error since handling DmaUnsynced as an Overrun will resolve it.
This commit addresses #3256 by disabling dma NVIC interrupt enablement at startup.
Instead, per-channel NVIC interrupt enablement is now done with the rest of the dma channel configuration.
This ensures that each core will only handle the interrupts of the DMA channels that it uses.
The half transfer irq needs to be enabled in order for the hardware to
notify the waker when the transfer is at half. This is needed to ensure
no overuns occur when using `ReadableDmaRingBuffer`'s `read_exact`.
Otherwise we are only notified when the DMA has completed its cycle and
is on its way to start overwriting the data. The docs in the dma_bdma
buf module also seem to imply that the half transfer irq must be enabled for
proper operation. The only consumers of the `ReadableDmaRingBuffer` api
are the sai module and the `RingBufferedUartRx`. The former enables the
irq manually when constructing the transfer options while the
latter does not. This may also be the cause for #1441.
if you have `PeripheralRef<'a, AnyPIn>` for pin A, and `AnyPin` (owned) for pin B, you can `mem::swap` them.
so, getting access forever to pin A, just by "sacrificing" pin B
this defeats the point of PeripheralRef, which is if you got a `PeripheralRef<'a, T>` then you're only allowed to use the peripheral for `'a`.
Also some drivers rely on the fact only one instance of a singleton exists for soundness, so this is a soundness fix for those.
see e.g. STM32H503 RM section 15.4.4...
1. Write 1 into GPDMA_CxCR.SUSP
2. Poll GPDMA_CxSR.SUSPF until it is 1
3. Write 1 into GPDMA_CxCR.RESET (occurs upon next init, in new_inner())
