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.

CCS/RM57L843: DMA with compatiblity SPI

Part Number: RM57L843

Tool/software: Code Composer Studio

Hi,

I am working with RM57Lxxx development board on compatability SPI with DMA.

I am using SPI two SPI's----SPI1-MASTER and SPI-2 as SLAVE.

SPI-1 is working in external loop back (MOSI and MISO pins are shorted in SPI-1.) SPI-2 SIMO pin is connected to SPI-1 of MOSI pin.

Chip select SCS[0] is connected from SPI-1 to SPI-2. This means When master SPI-1 transfer 260 bytes of data, the same 260 Bytes data master SPI-1 is received through loop back and also received by the slave SPI-2.

I configured DMA transfer to master SPI-1 as well as DMA receive to SPI-1 and DMA receive to SPI-2.

1.DMA_CH0 is configured to get SPI-1 TX DMA request DMA_REQ1

source and destination address for DMA SPI-1 TX is

g_dmaSpiTxCTRLPKT1.SADD = ((uint32_t) (u8_transBuffer));

g_dmaSpiTxCTRLPKT1.DADD =(uint32) (&(spiREG1->DAT1));

Question:

In the DMA control packet configuration for destination address whether I have to use SPI-1 DAT0 or SPI-1 DAT1 register for transferring data thru SPI.

If DAT0 register used how the Chip selection will be done when DMA is used with SPI in transferring the data. For example If I have two slaves and I have to use SPI with DMA how chip selection need to be done?

If DAT1 register used how the control field location are written in DAT1 register. Before Enabling DMA request I need to write DAT1 control field

spiREG1->DAT1 = ((uint32)FALSE << 28U)

| ((uint32)FALSE << 26U)

| ((uint32)SPI_FMT_0 << 24U)

| ((uint32)SPI_CS_0 << 16U) ; then enable DMA request in INT0 register

 

2.DMA_CH2 is configured to get SPI-1 RX DMA request DMA_REQ0

Source and destination address for DMA SPI-1 RX

g_dmaSpiRxCTRLPKT2.SADD = ((uint32)(&(spiREG1->BUF))); /* source address which is nothing but RAM location */

g_dmaSpiRxCTRLPKT2.DADD = ((uint32) (u8_receiBuffer1)); /* destination address which is nothing but RAM location*/

 

3.DMA_CH3 is configured to get SPI-2 RX DMA request DMA_REQ2

Source and destination address for DMA SPI-2 RX

g_dmaSpiRxCTRLPKT2.SADD = ((uint32)(&(spiREG2->BUF))); /* source address which is nothing but RAM location */

g_dmaSpiRxCTRLPKT2.DADD = ((uint32) (u8_receiBuffer2)); /* destination address which is nothing but RAM location*/

Question:

I am unable to receive the data in u8_receiBuffer2 buffer location but receiving the data u8_receiBuffer1 buffer location. Why DMA is not triggering SPI-2 RX request? When I checked the SPI-2 RX buffer register the chip select fields are ZERO.

Request you to help me in this regard.

Thanking you

Praveen

  • Did you connect the clock as well? You need SOMI, SIMO and the CLK connected at minimum.

    -Anthony
  • If it's more complex than just not having the CLK connected, please look at www.ti.com/.../getliterature.tsp

    While this appnote is mainly about parallel mode that's just a layer on top of the basic example showing two SPIs talking with DMA ..
  • Hi Anthony,
    Thank you for your reply.

    Yeah Clk line is also connected.
    I already refered to the app note given in your pre vious response.It is based on multi buffered SPI n DMA.

    My query is on SPI without multi buffer mode and DMA operation.
    If I have use Spi without multi buffer n dma ,in dma transfer packet intialization which register address spidat0 or spidat1 has to give.If spidat0 register ,than if i have two slaves and one master how spi will select slaves.if spidat1 how the control bits of spidat1 are updated.
  • Praveen,

    Yes -- I know the clock question was sort of obvious; but I saw all the other pins in your post
    except for clock so thought it was worth asking.

    SPIDAT0 and SPIDAT1 are both pointing at the same transmit shift register and writing to either one will
    kick off the transfer; but by choosing SPIDAT1 you could change the CSNR, DFSEL, WDEL, and CSHOLD with the same write as the data.

    If you want to do that, then your transmit buffer size in RAM should be 32-bits, with data to be transferred in the lower 16-bits and the CSNR, DFSEL, WDEL, and CSHOLD for each transfer in the upper 16 bits of each 32-bit word. Then you should setup the DMA to transfer 32-bit words to SPIDAT1.

    This lets you setup a sequence of transfers to different chip selects using different formats etc. as a list in RAM, and the change in chip select and format etc. gets handled automatically by the DMA transfer.

    If you want to change the chip select only with intervention from the CPU, then you can set the DMA to write to SPIDAT0. You would configure the CSNR, DFSEL, WDEL, and CSHOLD with the CPU before starting the transfer and any time you want to change these settings. Then you would let the DMA run all the transfers. In this case the transmit buffer in RAM can be smaller (16-bits per transfer) and you can write 16-bit values to SPIDAT0; but it just comes at the expense of more CPU intervention.

    If you turn on the MIB unit, then it's a bit of a mix because you get the finer grain control of the sequence without the CPU intervention every time (since the fields from SPIDAT1 that control chip select etc. will stay in the MIB unit RAM) but you can still do long transfers with the assistance of the DMA.

    The part you are using has Mib units on all SPIs so unless you are targeting a smaller part in the Hercules family -then starting with Christian's appnote and example code may not be a bad idea.

    Now I don't know if any of this answered your original problem statement. I thought that that statement had to do with not receiving data. Did you track that down to a bad chip select pattern or something and therefore question SPIDAT0 v.s. 1?

    -Anthony
  • Anthony,

    Thank you very much for detailed explanation of the SPI DAT registers and DMA operations.

    I have used SPIDAT1 register and solved the issue.I am able to communicate with Slave.

    Thanks once again.

    regards,

    Praveen