• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 80 subscribers
  • Views 144 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

MSP430FR5994: MSP430 DMA transfers SPI communication data out of order

xi.yan.kiana
Intellectual 340 points
Part Number: MSP430FR5994

HI teams:

     In the MSP430FR5994 chip, if I want to use the DMA module to receive the data sent back by the sampling chip, how should the DMA bottom layer be configured correctly?
Problem background:
    I want to collect data from 8 boards. When I request data, I request it one board at a time. Currently, the communication between my MSP430 and the sampling chip is SPI communication. When the SPI in the MSP430 receives the data, UCB2RXIFG is established. Using this flag as the trigger source of DMA, DMA starts to transfer the data from the SPI receiving buffer to the voltdest_buff array I set, and then I will extract the valid data in the array for subsequent processing.
Problem Description:
According to the above description, the whole process is for the host to send the data request frame of board No. 1. After the acquisition chip No. 1 responds, the SPI receiving flag is established, and the DMA starts to move data. After waiting for a certain period of time, the host starts to send the data request frame of board No. 2, and the acquisition chip No. 2 After the chip responds, DMA starts to move data, wait for a certain period of time, and the host starts to send No. 3... This cycle continues until all the board data is read. I now find that if the voltdest_buff array size is set to the size of the data  returned by one board. The size of the array will cause the data in the array to be out of order (the data is correct, but the order is wrong). If the size of the voltdest_buff array is set to the total size of the data returned by 6 boards, the array will have data coverage. The initial data of the array It's messy, but if you look down, you can find the complete data valid frame.
Doubtful points:
(1) Using UCB2RXIFG as the trigger source for DMA transfer will cause the timing of DMA transfer to be uncontrollable. I still don’t know how to solve it. How should the timing be controlled?
(2) Using DMAREQ as the trigger source for DMA transfer, the transfer has not been successful. I don’t know how to modify my configuration correctly. I understand that using DMAREQ as the trigger source will make the entire transfer process controllable.
My configuration is as follows:

Do you have any better suggestions or routine reference?

I look forward to your reply, thank you

  • 0
    Guru 90890 points

    The SPI is full-duplex, i.e. you always get as many Rx bytes as you send Tx bytes (even if some of them are not interesting). Corollary: You get the Rx (DMA) packet size you want by controlling the Tx size.

    If each transaction sends NC request packet bytes, and expects ND data bytes back, the entire transaction is (NC+ND) bytes long, and you will both transmit and receive that many  bytes. That does mean you have to account for the NC (useless) Rx bytes in each transaction, which is, yes, a bit annoying.

    The DMA knows nothing about Chip Selects. There's no reason you couldn't leave the Rx DMA active for all 8 targets, collecting 8*(NC+ND) bytes in one (Rx) transaction, while the Tx transaction is performed 8 times (each (NC+ND) bytes long).

    What is the significance of the number 138? Also, in what way are the data bytes out of order? (Gaps? Byte-reversed?)

  • 0
    Guru 20115 points

    Configuring DMA can be a bit tricky. Usually only used when absolutely required. Getting it all to work requires careful reading of the MSP430 and target device data sheets. I have no clue what the target is.

    When configured as shown you get a single transfer (byte) per trigger. Setting DMAREQ in software is a single trigger. (The channel isn't configured to look for that trigger - DMA4TSEL__DMAREQ.) You would have to test for RXIFG and set DMAREQ for each byte. Hardly worthwhile since handling the transfer in response to RXIFG would be simpler.

    Your code for the SPI transfer would be useful to look at. From what you say it appears that the MSP430 is the master and is generating the clocks. The SPI port generates clocks only when it has data to send. Unless that data is being transferred via DMA, using DMA for the receive side is kind of pointless.

**Attention** This is a public forum