TMS570LC4357: How to interpret table 20-3.

Hello Grimm,

The DMA controller on this device has 32-channels and 48 hardware DMA requests. The HW DMA requests (3rd col) have been pre-assigned to the peripherals (2nd col in Table 20-3).

Yes, each MibSPI offers up to 8 DMA channels (RX and TX) and 16 DMA request lines. You can pick one of them for your application. From table 10-3, 16 request lines (the number in parentheses following MibSPI1) from MibSPI1 are connected to DMA request #0, 1, 4, 5, 8, 9, 12, 13, 16, 17, 22, 23, 26, 27, 30, 31. 

For example, if you pick DMA request #12 and #13 for MibSPI DMA RX and TX, also you want to use DMA channel 8 and DMA channel 9 for MibSPI1 RX and TX:

 1. assigned DMA RX packet to DMA ch 8, and DMA TX packet to DMA ch 9:

     dmaSetCtrlPacket(DMA_CH8, g_dmaCTRLPKT_RX);

     dmaSetCtrlPacket(DMA_CH9, g_dmaCTRLPKT_TX);

2. Assign DMA channel 8 to DMA request #12, and DMA channel 9 to DMA request #13

     dmaReqAssign(DMA_CH8, 12);     

     dmaReqAssign(DMA_CH8, 13);

3. RXDMA_MAP and TXDMA_MAP in MibSPI DMAxCTRL register

    RXDMA_MAP and TXDMA_MAP should be the numbers in parentheses mentioned above. RXDMA_MAP=6, and TXDMA_MAP=7 

Hi QJ Wang,

Thanks for the quick reply, your answer was very helpful for my understanding of DMA architecture. I do have one last question though. In table 20-3 there is a footnote attached to MIBSPI request lines 0 and 1 for each that reads "SPI1, SPI2, SPI3, SPI4, SPI5 receive/transmit in compatibility mode" does this mean that these request lines should not be used when not using compatibility mode?

We have experienced some problems with our hardware triggered MIBSPI1 DMA that seem to occur only when using DMA_REQ0 / DMA_REQ1 with MIBSPI1_REQ1 / MIBSPI1_REQ0. With any other configuration we do not experience problems, could this be caused by this compatibiltiy mode? As far as we can tell from the datasheet the choice of request lines should have absolutely no impact on the behaviour of the DMA transfer.

Hello Grimm,

Not all 16 DMA request lines can be used for SPI compatible mode. Only the first two lines can be used, and request line 0 is for SPI TX only, and request line 1 is for SPI RX only.

I tried MibSPI1 DMA using DMA_REQ0 / DMA_REQ1 with MIBSPI1_REQ1 / MIBSPI1_REQ0 before, I didn't notice any problem. Did you program RXDMA_MAP and TXDMA_MAP properly? MibSPI can be used either in multi-buffered mode or SPI compatible mode. 

Your understanding is correct that the choice of request lines should have absolutely no impact on the behaviour of the DMA transfer.

We have a peripheral on MIBSPI1 that is performing transfers with DMA requests at 200hz on REQ0 and REQ1. On its own this will run perfectly for as long as we have been able to measure. 

We also have other peripherals on MIBSPI 2 and 5, both performing transfers with DMA at 25Hz as well as occasional asynchronous transfers triggered externally (a few per second at most). On its own these peripherals also run indefinitly.

All DMA transfers use different channels, requests and memory regions and have properly configured RXDMA_MAP and TXDMA_MAP according to 20-3.

Only when we combine them (all three peripherals active), the transfers on the 25Hz peripherals will break after what seems like a random amount of time (somewhere between 0-10 minutes). However when we change the request lines of the MIBSPI1 peripheral to any configuration other than REQ0 and REQ1 (keeping the channels and everything else the same) it will suddenly run correctly seemingly forever.

When the transfer breaks in MIBSPI 2 and 5 it looks like it hangs on a flag of the buffer mode of the MIBSPI (we use 7, wait for TXFULL and RXEMPTY).

While we now have a configuration that allows us to run our application correctly we are still trying to understand why it was breaking in the first place using REQ0 and REQ1. Like you said the choice of the request lines should have no impact. If you have any Ideas we would love to hear it.

Does this error occur if only two MibSPIs are used at the same time? I will run 3 MibSPI3 with loopback to see if I can get the error. Thanks for reporting this issue.