AM623: SPI data transfer using BCDMA

Koichiro Tashiro

Part Number: AM623
Other Parts Discussed in Thread: SYSCONFIG

Tool/software:

Hi,

My customer wants to use BCDMA for SPI transfer. He uses "udma_memcpy_interrupt.c" example in mcu_plus_sdk_am62x_11_00_00_16 as a starting point.
BTW, there is "mcspi_loopback_dma" example in SDK, which uses PKTDMA.
He wants to use BCDMA as he already uses it in another process and reuse the code.

He added necessary changes in sysconfig/codes and now data transfer to/from SPI seems working.
But no interrupt is generated after data transfer.

[Debug situation]
He checked "cqEventPrms" parameters in Udma_eventRegister() function and found
vintrNum is 2Ch (44). It means 44th Interrupt Aggregator Virtual Interrupt is assigned to the event.
He also checked intrStatusReg at 0x4802C020 for 44th interrupt and confirmed the value changed to 0x00000001 after DMA transfer completion.
But "cqEventPrms", coreIntrNum is 0h which supposed to be mapped for core interrupt.

He also checked "rmInitPrms" parameter in gUdmaDrvObj after Udma_init.

startBlkCopyUhcCh    = 0x00000000 (0)
numBlkCopyUhcCh      = 0x00000000 (0)
startBlkCopyHcCh     = 0x00000000 (0)
numBlkCopyHcCh       = 0x00000000 (0)
startBlkCopyCh       = 0x00000012 (18)
numBlkCopyCh         = 0x00000006 (6)
startTxUhcCh         = 0x00000000 (0)
numTxUhcCh           = 0x00000000 (0)
startTxHcCh          = 0x00000000 (0)
numTxHcCh            = 0x00000000 (0)
startTxCh            = 0x0000000C (12)
numTxCh              = 0x00000006 (6)
startRxUhcCh         = 0x00000000 (0)
numRxUhcCh           = 0x00000000 (0)
startRxHcCh          = 0x00000000 (0)
numRxHcCh            = 0x00000000 (0)
startRxCh            = 0x00000012 (18)
numRxCh              = 0x00000006 (6)
startMappedTxCh      = {0x00000000,0x00000000,0x00000000,0x00000000}
numMappedTxCh        = {0x00000000,0x00000000,0x00000000,0x00000000}
startMappedRxCh      = {0x00000000,0x00000000,0x00000000,0x00000000}
numMappedRxCh        = {0x00000000,0x00000000,0x00000000,0x00000000}
startMappedRing      = {0x00000000,0x00000000,0x00000000,0x00000000,0x00000000,0x00000000,0x00000000,0x00000000}
numMappedRing        = {0x00000000,0x00000000,0x00000000,0x00000000,0x00000000,0x00000000,0x00000000,0x00000000}
startFreeFlow        = 0x00000000 (0)
numFreeFlow          = 0x00000000 (0)
startFreeRing        = 0x00000000 (0)
numFreeRing          = 0x00000000 (0)
startGlobalEvent     = 0x0000020D (525)
numGlobalEvent       = 0x00000080 (128)
startVintr           = 0x0000002C (44)
numVintr             = 0x00000012 (18)
startIrIntr          = 0x00000000 (0)
numIrIntr            = 0x00000012 (18)
startC7xCoreIntr     = 0x00000000 (0)

He thinks startVintr (44) is related to vintrNum. And startIrIntr (0) is related to coreIntrNum.

Questions:
Q1) First of all, is it possible to use BCMDA for SPI data transfer?
Q2) If an answer to Q1 is yes, what is the potential reason why DMA completion interrupt is not generated? Any debug suggestion?

Thanks and regards,
Koichiro Tashiro

1 month ago

0 Swargam Anil 1 month ago

TI__Mastermind 47066 points

Hello Koichiro Tashiro,

The SOC supports can either use the BCDMA or PKTDMA channels to transfer data from Memory to SPI FIFO or SPI FIFO to Memory.

In the MCU+SDK we do support only the PKTDMA and not the BCDMA.

If a customer is implementing BCDMA, then we need to check how the customer is implementing the TRPD for SPI.

Why does the customer want to go with BCDMA rather than PKTDMA and that BCDMA + SPI is not supported in the MCU+SDK as well.

Who is the customer ?

Regards,

Anil.

0 Koichiro Tashiro 1 month ago in reply to Swargam Anil

TI__Mastermind 22945 points

Hi Anil,

Swargam Anil said:
If a customer is implementing BCDMA, then we need to check how the customer is implementing the TRPD for SPI.

Do you want to get the customer's CCS project?

Swargam Anil said:
Why does the customer want to go with BCDMA rather than PKTDMA and that BCDMA + SPI is not supported in the MCU+SDK as well.

As I mentioned earlier, the customer already used BCDMA for other purpose, so they are familiar with BCDMA. This is why they prefer BCDMA rather than PKTDMA.

Swargam Anil said:
Who is the customer ?

I will let you know offline.

Thanks and regards,
Koichiro Tashiro

0 Swargam Anil 1 month ago in reply to Koichiro Tashiro

TI__Mastermind 47066 points

Hello Koichiro Tashiro,

Thanks for sharing the details.

In the MCU+ SDK, we support SPI with PKTDMA, and this path has been validated and tested properly.

If we try to use BCDMA with SPI, it may lead to multiple issues since this feature is not supported in TI’s E2E.

While the customer may already be familiar with BCDMA, reusing it for other peripherals like SPI is not the recommended approach.

The design in MCU+ SDK is as follows:
• BCDMA channels are intended for memory-to-memory transfers.
• PKTDMA channels are used for memory-to-peripheral or peripheral-to-memory transfers (such as SPI, UART, etc.).

This separation is intentional to ensure correctness and stability.

Regards,

Anil.

0 Koichiro Tashiro 1 month ago in reply to Swargam Anil

TI__Mastermind 22945 points

Hi Anil,

Based on your feedback, now the customer is trying to modify mcspi_loopback_dma example and use PKTDMA.
It seems data transfer can be done properly, but no interrupt is generated (interrupt handler is not called) after the transfer completion.
intrStatusReg value is updated to 0x00000001, so it looks an interrupt comes to INTAGGR.

Here are what the customer checked.
- When Udma_eventRegister API is used with eventMode = UDMA_EVENT_MODE_SHARED,
vintrNum is 62, coreIntrNum is zero.
- When Udma_eventRegister API is used with eventMode = UDMA_EVENT_MODE_EXCLUSIVE, masterEventHandle = NULL,
vintrNum is 63, coreIntrNum is 1.
The customer thought vintrNum should be between 0 and 39. coreIntrNum should be between 64 and 103.

- The customer also checked Udma_RmInitPrms after UdmaRmInitPrms_init and found initialized values are;
startVintr = 62
numVintr = 18
startIrIntr = 0
numIrIntr = 18
He thinks the interrupt is not generated properly because above initialized values are not correct.
Could you check these values are correct?
If not, how to correct them?

Thanks and regards,
Koichiro Tashiro

0 Swargam Anil 1 month ago in reply to Koichiro Tashiro

TI__Mastermind 47066 points

Hello Koichiro Tashiro,

May I know whether the customer is using which SPI MAIN or MCU or DM SPI ?

How did customer configure the syscfg for the SPI + DMA ?

How did the customer confirm the interrupt was not triggering ?

Did customer enable callback back mode and put the break point in the callback mode and the break point is not hitting ?

Regards,

Anil.

0 Koichiro Tashiro 1 month ago in reply to Swargam Anil

TI__Mastermind 22945 points

Hi Anil,

Swargam Anil said:
May I know whether the customer is using which SPI MAIN or MCU or DM SPI ?

McSPI1 in MAIN is used.
I will send you a part of customer codes with some explanation offline.

Thanks and regards,
Koichiro Tashiro

0 Swargam Anil 30 days ago in reply to Koichiro Tashiro

TI__Mastermind 47066 points

Hello Koichiro Tashiro,

I have looked at the code.

We do not officially support SPI + DMA in the MCU+SDK.

My suggestion is rather doing everything in the custom application like DMA and SPI integration in the example code.

Already the DMA SPI example is available on the A53 core.

The same code can be leveraged into the DM R5F core.

Please let me know how I can proceed further.

If I wanted to check the customer code, I need to validate each of the codes and it will take time.

Coming to other methods, the SPI with DMA is available on the A53 core and then we need to be integrated into the DM R5F core is easy.

Who is the customer, and what is their end product ?

When do they want to expect this code ?

Because this feature is not supported in MCU+SDK, but based on the customer details, we can work on that.

Regards,

Anil.

Processors

Processors forum

AM623: SPI data transfer using BCDMA