AnsweredAssumed Answered

K22 SPI DMAs with "Transmit or Receive" Sources Revisited

Question asked by Matt Boytim on Sep 18, 2019
Latest reply on Sep 23, 2019 by Matt Boytim

Has anyone used the suggestion here by Mark Butcher


K22 SPI DMAs with "Transmit or Receive" Sources 


for overcoming the single DMA source limitation of some SPI's?  Specifically the suggestion:


3. If both are used, the Rx trigger needs to be selected (the Tx trigger occurs too early and so Rx data would not be ready on first transfer). This can be used to trigger the next Tx transfer, followed by chaining to a second DMA transfer which saves the Rx value.


I tried this but it doesn't seem to work.  The problem appears to be that by using the RX to trigger a TX transfer the DMA request doesn't seem to get cleared so it keeps sending data to the transmitter until I guess the chained DMA for RX actually transfers the receive data and clears the request.  This happens even though I am using a higher DMA priority for the chained-to RX channel.


Looking at the SPI traffic on a scope I see fewer transfers than I expect, and the state of the (hardware driven) ChipSelect seems erratic - it depends on what TX transfers are lost/overwritten.  For example if I lose the one that deasserts CS at the end of the SPI transaction then the CS hangs asserted until the next frame.


If my SPI frame consists of only one or two transfers then it works as expected - since the transmitter is double buffered it can't be overrun with only two transfers.  But I see this behavior for three or more.


I did not try channel preemption to see if that might allow the RX transfer to occur sooner and avoid the overwritten TX data.