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

Hello Mathias,

Sorry for the delayed replies as I was out of office.

My suggestion is to go with PRU core rather than an R5F core interrupt.

If you go with R5F core plus  interrupt, you may not achieve the time critical requirement.

I am routing your query to a PRU expert.

Regards,

Anil.

Hello Mathias,

I am out of office today and Monday. We can chat more next week.

Answering your specific questions

Each PRU subsystem on AM243x/AM64x (where AM64x is basically AM243x + A53 cores) is a PRU_ICSSG. There are 6 cores per subsystem, and each subsystem is divided into 2 "slices" where there are 3 cores per slice (PRU, RTU, TX_PRU). Each core has the same processing capabilities, but connections to PRU GPI/GPO pins is different. It sounds like you do not care about reading/writing to processor pins with PRU cores at this point in time.

So AM64x has 12 PRU cores total.

We split each PRU subsystem into 2 slices because (as long as the shared memory regions are divided properly) it allows us to set each slice to work independently. That is why a single PRU subsystem can support 2 gigabit ethernet links, one Ethernet link per slice.

FYI: PRU Academy is coming later this month 

I am currently in the process of writing the PRU Academy for AM243x, which will show up as a new module in the AM243x academy:
https://dev.ti.com/tirex/explore/node?node=A__AEIJm0rwIeU.2P1OBWwlaA__AM24X-ACADEMY__ZPSnq-h__LATEST

as well as getting the new open-pru repo ready for the initial release:
https://github.com/TexasInstruments/open-pru

PRU academy will include a bunch of information, including porting the PRU Getting Started Labs to AM243x. For now, please avoid spending too much time looking at open-pru until I have at least merged in the documentation updates:
https://github.com/TexasInstruments/open-pru/pull/58 

But if you can afford to wait a few weeks, it will be a much smoother experience when I have the code and documentation up for the full PRU Academy.

Please send me a direct message with your email address if you would like a notification when the first version of the PRU Academy goes live.

Sample code for interacting with IEP timer? 

The PRU subsystem has a bunch of accelerators & peripherals, and PRU cores can do some cool programming things that are challenging on other cores. My eventual goal is to have sample code for each peripheral and accelerator in the PRU academy.

I have not written the IEP code yet. But if you decide to use PRU & IEP timer in your design, we can work together to write some code for you and for the academy. I would have bandwidth for that starting around October. There are some existing pieces of code from earlier PRU processors that we could use as a reference, like https://git.ti.com/cgit/pru-software-support-package/pru-software-support-package/tree/examples/am335x/PRU_IEP 

Regards,

Nick