MCU-PLUS-SDK-AM243X: System Interconnect - connection between MCSPI and Timer

Hello Mathias,

On AM243x, there are three possible approaches for timer-based cyclic SPI transfers:

1. Timer-Based SPI Transfers Without DMA

• A DMTimer is configured to generate a periodic interrupt.
• In the timer ISR, the CPU writes data directly into the SPI TX FIFO to start the transfer

2. Timer-Based SPI with PKTDMA (Manual Trigger)

• A DMTimer generates a periodic interrupt.
• In the ISR, the CPU enqueues a descriptor into PKTDMA, which then transfers data from memory to the SPI TX register.

3. Auto-Triggered SPI with DMA (BCDMA)

• In theory, BCDMA supports event-triggered channels where a timer event can directly trigger a DMA transfer to SPI.
• This would allow fully autonomous, timer-aligned, cyclic SPI transfers without CPU involvement.
• ️Limitation:
  
  • On AM243x, only PKTDMA is supported in the MCU+ SDK.
  • BCDMA auto-triggered DMA is not available, so this method cannot be used in practice.

Regards,

Anil

Hello Anil,

Thank you for the clarification. Actually, that's not what I wanted to hear, because we want to avoid using an interrupt if possible. As I understand you, solution #3 is not feasible at all. But can you explain in more detail what the limitations you mentioned are?

Our system has a cyclic control cycle. We use it to process information that we read in via SPI interfaces. Starting the read process (start SPI transfer) is therefore synchronized with the cycle, but with a time delay. Is there another way to achieve this time delay (in the range from 0us to about 50us)?

One ICSSG is reserved for real-time Ethernet communication. On the second ICSSG, it is still possible to execute something else. As far as I understand, there are three PRUs. We have reserved PRU0 for SigmaDelta converters. Can either PRU1 or PRU2 be used for this task?

Thank you,
Mathias

Hello Mathias,

If you are working only with the R5F cores, then above methods  are valid. However, since you are already familiar with the PRU cores, I would recommend moving forward with them for this requirement.

Your requirement is to transfer data once every X µs, with the ability to configure a delay in the range of 0 to 50 µs before starting the transfer.

On the PRU cores, this can be achieved using the IEP  timer. The IEP timer counter can be programmed with a compare value corresponding to the required delay (0–50 µs). When the compare event occurs, the PRU firmware can then control its GPIO pins (R30/R31) to generate the SPI signals at the exact programmed time.

This approach allows you to Achieve highly deterministic timing .Since this requirement involves detailed PRU programming, I am routing your query to our PRU experts, who can help with implementation details and provide example code snippets.

Regards,

Anil

Hello Anil,

Thank you for your explanation. At the moment, I don't need a detailed solution, but it's enough for me to know that there are two different options (R5F core with interrupt and PRU). We are only in the process of planning resources.

I wouldn't say that I'm familiar with the topic of PRU. I only have a rough idea of what it is. Unfortunately, ti uses a lot of abbreviations sometimes for the same thing, which doesn't necessarily make it easier to understand. Perhaps you could clarify a few general questions:

• Do slices 0 and 1 (Figure 6-175, Reference Manual) refer to PRU_ICSSG0 and PRU_ICSSG1?
• Are the PRU blocks within a slice independent of each other, or...?
• How many independent tasks can be implemented with one slice?
• Which peripherals can be addressed from a PRU, i.e., is it possible to use an MCSPI, or does a full duplex SPI have to be implemented via firmware?

Thank you!
Mathias