This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

McSPI timing anomaly

Good Afternoon!

I wrote some code (under SYS/BIOS fwiw) to use SPI1-CS0 to transfer data.  The SPI clock frequency was set to 12MHz.  I tested it both using an ISR to transfer data to and from the FIFO, and using the EDMA controller. 

When I put a scope on the clocks, I saw a gap between the 8 clock byte groups.  With the EDMA, there was a 500ns delay between bytes.  Using the ISR to move data to the FIFO, the gap went down to 200ns.  It did not matter whether it was  tx only or tx/rx mode.

I could not find an explanation or quantification of this phenomena in either the TRM or the timing information in the DS.  How can I get rid of that dead time?

Gerry Belanger

  • Hi Gerard,
     
    Have you checked the CS0? Does it stay low all the time?
     
    Best Regards
    Biser
  • Biser,

    CS0 is yet another issue. The short answer is, yes, it goes active, but not the way I would like it to.

      It's behavior depends on the PIN34, Single/multi channel mode, and the FORCE bit.  Here is what I have found so far:

    If PIN34 is set to 3 pin mode, CS is not used, and I would have to control it as a GPIO bit.

    In 4-pin mode, CS is controlled one of 2 ways

    SINGLE channel mode: the FORCE bit makes it active, and it HAS to be active for a transfer to occur. This has to be controlled manually in software.

    MULTI channel mode: CS automatically goes active during data word transfers, but goes inactive between them.

    Ideally, I would like the CS to go active automatically before the first transfer, and go off after the last transfer, without going inactive between words. My hardware would be mush happier with this, but I could not find a way to do it.

    As far as the inter-byte gaps in the data, if I do not use the DMA, and use an ISR to feed the FIFO, with the transmit FIFO trigger level level set to 10, and the ISR feeding 10 bytes at a time, I get a 200 ns gap between bytes without TURBO, and a 100 ns gap with TURBO.  Data got lost when I used Multi-channel mode, so I had to stick with Single.

    With the DMA, I get a 500 ns gap between bytes.  The example from Starterware I based this on has the FIFO trigger level set to 1, and the DMA parameter ram set to also transfer 1 byte at a time. 

    I would like to figure out a way for the DMA to utilize the SPI FIFO.  Based on the ISR experiment, the 200ns gap appears to be the FIFO overhead, which is reduced to 100ns in Turbo mode.  I think the 500ns in DMA mode is some overhead with having to do a memory fetch and parameter ram update on every byte.  By using the FIFO, some of that overhead could be overlapped with the SPI FIFO feeding the SPI transmitter.  Which was my original question.

    Gerry Belanger

  • Hi All,

    Is there any results on this?  We are having the same problem on a BeagleBone with a 1us gap between each word in TX/RX mode and a 500ns gap in TX only mode.  The gap does not seem to matter on the clock rate.

    We have a custom CS, we set it high for the transfer and then low at the end of the transfer for 1us, before setting it high again for the next transfer.

    Thanks,

    Paul

  • Paul,

    The best SPI performance I got was by NOT using the DMA.  By using the McSPI FIFOs and the McSPI FIFO interrupts, I was able to get the gaps down to 100 ns using TX only and TURBO.

    With the EDMA, I could not find a way to get the controller to make use of the McSPI FIFO.  Ideally, I would want a fifo low water transfer request to cause the DMA to put more than one word into the fifo.  The only combination that I found that worked and did not lose data was ACNT = 1, BCNT = number of words to transfer, CNT = 1.  But this does not utilize the FIFO.  The 500ns (400 with turbo) inter-word delay is probably the memory access for the next data, and PaRAM update overhead.  If we could use the FIFO, at least the memory access overhead would overlap SPI transfers, reducing the inter-word gap, and thus our entire transfer time. 

    I know this does not help you, but maybe someone at TI knows how to make the EDMA play nice with the McSPI FIFO.  I really don't want to use my CPU cycles to run an ISR to feed the fifo when there is a dma controller which should be able to do it for me.

    Gerry Belanger

  • Gerard,

    My apologies about bumping this old thread. However, I was wondering how you got DMA to control the SPIEN FORCE bit? I've done quite a few experiments with chaining a "set CHCONF register" DMA channel to the MCSPI0TX0EVT and MCSPI0RX0EVT but so far nothing seems to work. The biggest obstacle being that as soon as I deactivate SPIEN, DMA events are no longer generated.

    Brian
  • Brian,
    I just reviewed my notes on this topic. My post from Sept 10, 2012 still stands. I could find no way to make the CS behave automatically how I wanted it to. I ended up setting the FORCE bit in my spi dma setup, and clearing it in the DMA complete ISR.
    GerryB