K22 SPI DMAs with "Transmit or Receive" Sources

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

K22 SPI DMAs with "Transmit or Receive" Sources

Jump to solution
764 Views
lsrbigfoot
Contributor III

Typically when setting up TX and RX SPI DMA transfers (on K20 for example), I would use dedicated (or separate) source numbers for TX and RX DMAs. For the K22, I can only use this approach for SPI0 but not for SPI1 and SPI2 because the DMA source numbers on both peripherals appear to be a share resource where I can only do either TX or RX (see below):

pastedImage_1.png

How can I still implement SPI DMAs (TX and RX) on SPI channels with shared DMA source numbers? Any examples?

If not possible, then will I have to set up the transfers such that one transfer is interrupt controlled (likely TX) while the other is DMA controlled (RX)?

0 Kudos
1 Solution
489 Views
mjbcswitzerland
Specialist V

Hi

I haven't used this technique, but have understood that it is what is intended when the DMAMUX has a shared slot for Rx or Tx SPI:
1. If only Rx DMA is used there is no restriction
2. If only Tx DMA is used there is no restriction
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.
The disadvantage is that the Tx trigger occurs at the end of each Tx byte (rather than earlier in the cycle) and so there may be more space between each Tx byte.
Potentially the Tx trigger could however also be used (if minimum inter-character space is required) but the first Rx byte would not be valid and after the complete sequence a further read from the Rx buffer is needed to collect the final data byte (and the first invalid byte at the start of the buffer ignored).

Regards

Mark

View solution in original post

1 Reply
490 Views
mjbcswitzerland
Specialist V

Hi

I haven't used this technique, but have understood that it is what is intended when the DMAMUX has a shared slot for Rx or Tx SPI:
1. If only Rx DMA is used there is no restriction
2. If only Tx DMA is used there is no restriction
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.
The disadvantage is that the Tx trigger occurs at the end of each Tx byte (rather than earlier in the cycle) and so there may be more space between each Tx byte.
Potentially the Tx trigger could however also be used (if minimum inter-character space is required) but the first Rx byte would not be valid and after the complete sequence a further read from the Rx buffer is needed to collect the final data byte (and the first invalid byte at the start of the buffer ignored).

Regards

Mark