PROCESSOR-SDK-AM64X: AM64x

Hello,

Are you using the Linux SDK or MCU+ SDK?

Thanks,

Jianzhong

Hello Jianzhong,

i am using the MCU+ SDK. The example is the freertos implementation.

best regards,

Robert

Hi Robert,

As it described in the following section of AM64x TRM, the data size written to the TR/RX FIFO depends on the Y*X which can be changed in PDMA_PSILCFG_RX_STATIC_TR (CSL_PSILCFG_REG_STATIC_TR), so it is possible to make the data size written to TR/RX FIFO <= 4 bytes. 

Udma_chConfigPdma --> Udma_chSetPeerReg --> CSL_FMK(PSILCFG_REG_STATIC_TR_Z, pdmaPrms->fifoCnt);

11.3.1.3.4.4.1 X-Y FIFO Mode Channel
The PDMA channel will remain idle until a pulse is detected on the associated input DMA request event pin.
Once the pulse is detected, the DMA will sequentially issue a total of 'Y' parameter writes of 'X' parameter
bytes to the data FIFO address specified for the channel. Each write that the DMA performs will be a single
'X' element in size (no large bursts). Once the total specified number of transactions has been completed the
channel will return to an idle state and wait until it is triggered again. The write transfers that are performed
will be accomplished as quickly as possible given availability of data in the Tx channelized FIFO and given the
arbitration that may occur as a result of other channels also using the same write unit.

Best regards,

Ming

Hi Ming,

i investigated the MCSPI DMA driver, in my understanding the initialization of Udma_chSetPeerReg will end up in setting of X, Y, and Z of CSL_PSILCFG_REG_STATIC_TR.

If this is correct, current implementation of MCSPI driver in MCU PLUS SDK 08.02.00 configures these values for a MCSPI transfer of 68 Byte with
   X = UDMA_PDMA_ES_8BITS
   Y = 1 (ElementCount)
   Z = 68 (FifoCount)

This configuration will fill the available FIFOs with up to 256 Bytes. Only additional bytes could be modified before the transfer happens.

Additionally i have modified the MCSPI UDMA Driver, Mcspi_dma_udma.c, Line 496:

pdmaPrms.fifoCnt = 4U; // numWords <- old value

But this change had no effect. Even with this modifcation the FIFOs will be fully filled.

Is there any other solution?

Best regards,
Robert

Hi Robert,

I looked into the MCSPI DMA example in MCU+ SDK. It is a loopback example using DMA to move data. The same example send out data (in gMcspiTxBuffer) and then receive data to gMcspiRxBuffer. Since the data is transmitted and received with single call to MCSPI_transfer() via MCSPI internal loopback and copied from memory to MCSPI by PDMA AND copied from MCPSI to memory by PDMA, so it is hard to know the PDMA channel FIFO status. I am not sure how do you know the two 128 bytes FIFO have been filled all at once. According to the  11.3.1.3.4.4.1 X-Y FIFO Mode Channel, the PDMA FIFO copy is X*Y per DMA request event. In the above example you gave, each DMA event will copy 8 bit data, and the PDMA will be triggered 68 times. I believe both PDMA TX/RX FIFO only be used 1 byte at a time. In the second case, each time the PDMA copied 32 bit data for 68 times, so the PDMA TX/RX FIFO is only used 4 bytes.

On the other hand, I agree with you if you want to manipulate the TX data before its transmission, you probably want to set the Z to 1, because once you put the data in transmit buffer and the MCSPI transfer request, you have to assume it can go out anytime, especially when you are the MCSPI slave. You really do not know when the MCSPI master is going to read it.

Best regards,

Ming