• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 80 subscribers
  • Views 198 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.

MSP430FR5994: HW_SPI DMA block transfer cannot be configured efficiently

jinghua chen
Prodigy 115 points
Part Number: MSP430FR5994

When using the MCU hardware SPI interface, it is expected that DMA can be configured as block transmission, the transmission byte is 4 bytes, the DMA4 channel is used, and the triggering mode of 4 channels is triggered by software, the specific code is as follows,

byteLength = 4；

DMACTL1 = DMA3TSEL__UCA3RXIFG; // per SLASE54C Table 6-11
DMACTL2 = 0;
// SPI Rx side: single, byte(s), increment dest, not source.
__data20_write_long((uintptr_t)&DMA3SA, (uintptr_t)&UCA3RXBUF); // __SFR_FARPTR nonsense
__data20_write_long((uintptr_t)&DMA3DA, (uintptr_t)DataRx); // __SFR_FARPTR nonsense
DMA3SZ = byteLength;
DMA3CTL = DMADT_1 | DMADSTINCR_3 | DMASRCINCR_0 | DMADSTBYTE | DMASRCBYTE ;

DMA3CTL |= DMAEN;

DMA4CTL |= DMAEN;
DMA4SZ = byteLength;
// Timer+SPI Tx side: single, bytes(s), increment source, not dest
__data20_write_long((uintptr_t)&DMA4SA, (uintptr_t)DataTx); // __SFR_FARPTR nonsense
__data20_write_long((uintptr_t)&DMA4DA, (uintptr_t)&UCA3TXBUF); // __SFR_FARPTR nonsense

DMA4CTL = DMADT_1 | DMADSTINCR_0 | DMASRCINCR_3 | DMADSTBYTE | DMASRCBYTE ;

but in actual circumstances, it will only send 16bits, and no data is sent out, may I ask if there is a problem with such configuration? At the same time, the Rx channel obtains 4 bytes of data by configuring the DMA3 channel and using RxIFG as the trigger source

  • 0
    Guru 99415 points

    > DMACTL2 = 0;

    You need to enable a trigger for the Tx side as well, something resembling:

    > DMACTL2 = DMA4TSEL__UCA4TXIFG; // per SLASE54D Table 9-11

    -----------------------

    Also, you should use DMADT_0 so it transfers one byte per trigger.

    -----------------------

    The way the flow works:

    1) A TXIFG trigger causes a DMA4 transfer into TXBUF, which starts the SPI (clocks)

    2) As the Tx byte is shifted out, an Rx byte is shifted in; when the byte is done, RXIFG is triggered.

    3) The RXIFG triggers DMA3 to read RXBUF.

  • 0 in reply to Bruce McKenney
    Prodigy 115 points

    I was able to use a single byte transfer, using the software to enable DMAREQ, which needed to be triggered several times, so that DMA would complete the 4-byte transfer. But I expect to be able to use DMA block transfers, after configuration, software no longer participates, but after configuration block transfers are invalid.

    In addition, the configuration you gave just now had no effect. After the configuration was completed, I manually enabled TxIFG of SPI, and the transmission could not be triggered

    DMACTL2 = DMA4TSEL__UCA3TXIFG; 

  • +1 in reply to jinghua chen
    Guru 99415 points

    A Block transfer (DMADT=1) isn't appropriate for what you're doing -- it will write all the (4x) bytes in a single burst (based on the first trigger), which will overrun TXBUF and lose most of them. Rather you want to do 4x single-byte transfers (based on 4x TXIFG triggers) with DMADT=0.

    ----------------

    > DMA4CTL |= DMAEN;

    I just noticed that you're doing this before configuring DMA4. You should do this afterward. This step will start the DMA.

    ----------------

    I don't know whether having the CPU (or debugger) set TXIFG results in a DMA trigger (I haven't tried it). I expected that TXIFG would already be set.

  • 0 in reply to Bruce McKenney
    Prodigy 115 points

    After the DMA is set up, the TXIFG is cleared first, and then manually triggered to make it send continuously

**Attention** This is a public forum