• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 80 subscribers
  • Views 729 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

MSP432E401Y: Triggering SPI DMA using a GPIO trigger

Bob Benjamin
Guru** 113765 points

Part Number: MSP432E401Y

Hi,

I have a sequence of 18 bytes that I need to transmit on the SSI3 peripheral ASAP after a GPIO event.  I'm using the uDMA.  If I monitor the GPIO using an interrupt I can start the sequence from within the interrupt routine and the contents of the associated buffer transmits to completion.  I would like to eliminate the small overhead by triggering the DMA directly from the GPIO instead of triggering the SSI3 transmit inside the GPIO interrupt routine.  I have a GPIO trigger event that starts the transmit sequence, but when the GPIO triggers only 4 bytes of the buffer contents are transmitted (4 bytes equating to the arbitration value).

The next GPIO trigger sends out the next four bytes in the buffer, and each subsequent trigger follows the same action until the buffer has completely transmitted.  So instead of one trigger event sending out 18 bytes of data, I now require 5 GPIO trigger events to transmit the complete buffer.

So my question is if it is even possible to transmit 18 bytes continuously out of the SSI with a single GPIO trigger?  And if so how would I accomplish this and is there any examples of how this might work?

Best regards,

Bob B

  • 0
    Guru 102665 points
    No one has suggested an elegant way, so I'll suggest a slightly Rube-Goldberg-ish way.

    The catch is that you really want the SPI DMA to be paced (triggered) by the SPI signals, not your "start" signal. So you create a second DMA which triggers on the start signal and does a one-word memory-memory copy of some relevant word to start the operation.

    I did this on the P series; it started the ADC by copying a word with the Start Conversion bit on into the appropriate ADC control register, and after that the ADC+DMA ran at its own pace. The "start" DMA was triggered by DMAE0 since the P series doesn't have GPIO triggers. In your case, maybe DMA-ing a word with the appropriate bit into DMAENASET would do it?

    I guess I'm not clear why you can't send more than 4 bytes for each Enable. On the P series the uDMA is capable of e.g. 18 one-byte transfers as a group (paced by e.g. TXEmpty), and the E series DMA seems to cooperate with the FIFO. I should defer to the E series experts for that one.
  • 0 in reply to Bruce McKenney
    TI__Mastermind 22640 points
    Hello Bob,

    Apologize for the delay in response.

    Can you try to increase the arbitration size to > 18 (UDMA_ARB_32)?

    You also try to set-up the transfer in Auto mode as in this mode the data will be transmitted as long as it is available. This mode is normally used with Software triggered transfers.

    If the above two approaches fail, then you can use the Scatter-gather method (similar to what Bruce suggested).

    Thanks,
    Sai
  • 0 in reply to Sai Reddy
    TI__Guru** 113765 points
    Hi Sai,

    Thanks for responding. The problem I was having revolved around the issue with the FIFO for the SPI transfer triggering an SPI event once the FIFIO was half full regardless of arbitration size. I could transfer 16 bytes with no problem (FIFIO length of 8 words, and half-full is 4 words times 32 bit word length for a total of 16 bytes). I could brute force another event, but that was causing a longer delay than just triggering from inside the GPIO interrupt handler. So instead of directly triggering the SPI DMA transfer from the GPIO event itself, I now call the handler for the event that then sets up the SPI DMA transfer which then completes the entire transfer to whatever buffer length I choose. I have a small delay to start, but the I get 144 continuous SCLKs with no break in between. I still have the initial delay from the event to SCLK, but things seem to work ok and is scalable the way I'm doing it .

    Best regards,
    Bob B

**Attention** This is a public forum