AM620-Q1: ipc example without interrupt

Hi Owens, sorry for the delay reply, I have been out of office. Could you please clarify your request? what exactly is the modification required? Do you want to change ipc_notify from "interrupt" to "polling"?

thank you,

Paula

hi，Paula

     Yes. In this project, the processing response requirements for ipc are not high (ms level is allowed and polling processing can be carried out), but the interrupts used at the bottom layer of RPMSg need to be removed (to avoid the jitter impact of these interrupts on the IO timing).

linux runs on A53 and no rtos runs on M4F.

Regards,

Owens

Hi Owens, as you might know, the bottom layer of RP Message, in MCU+ RTOS cores, is IPC Notify. IPC Notify's underlying implementation uses HW mechanisms to interrupt and HW mailbox based HW FIFOs to transport the message and interrupt the receiving core. While Linux has a low-level mailbox driver that can be used by other higher-level Linux drivers (like RPMsg).

In both cases changing from interrupt to polling would be a re-work.

What is the current jitter you are observing? what is the maximum or expected jitter in your application? are you using RT Linux?

thank you,

Paula

Hello Owens,

How is RPMsg IPC being used?

Please also tell us how you are using IPC RPMsg. (what data is getting passed? How much data is getting passed? Are there latency needs or throughput needs?)

If you are not actually passing data back and forth between Linux and the M4F core, then you can simply remove the IPC RPMsg drivers from the M4F firmware.

Regards,

Nick

hi Paula & Nick

   We are using non-real-time linux

  We will transmit some short instructions and short logs of M4F to A53. The length of a single frame is less than 300 bytes. The real-time requirements for ipc data are not high and can reach 1ms to 2ms.

   A53 will need to send some instructions and configurations to M4F

   M4F needs to report some status and faults to A53

Owens, please allow us few days to discuss this and come back to you when Nick is back (early next week).

thank you,

Paula

Hi Owens, help me to confirm, the issue is that M4F gets interrupt too often (IPC Notify) and this is creating jitter in some IO tasks. If so, do you know how much jitter?

If only non-critical instructions/configurations are sent by A53 to M4F. Could those be moved to a shared memory?

thank you,

Paula

hi，Paula

1. We identified this issue during the project risk assessment stage at the beginning of the project. The specific jitter delay data cannot be obtained in the short term.

2. Both M4F and A53 have bidirectional data interaction

3. If shared memory is used, can the queue method of RPMsg also be adopted to solve the problem of read-write locks? What is the minimum interval allowed for reading and writing?

thank you,

Owens

Hello Owens,

Please tell us more about the waveforms and how you intend to generate them 

If the waveform can be generated by the PWM module, then nanosecond jitter requirements are fine.

However, your statement "IO of the M4F" makes it sound like you are also planning on having the M4F "bitbang" signals by directly driving GPIO signals high or low. Can you please comment more?

Please confirm the part number, and automotive grade or not

I do NOT suggest using the M4F to manually bitbang IO signals if you need nanosecond precision. The M4F was not designed for this usecase. However, the PRU core was designed to read and write input signals with nanosecond level latency, and nanosecond level precision.

For more details about how the PRU GPI / GPO signals are different from the M4F writing to a GPIO module, refer to
[FAQ] What is a PRU core? Why are PRU GPIO signals different from regular GPIOs? 

1) please confirm the exact part number you are using (are you actually using AM620-Q1, or are you using something else, like potentially AM623 or AM625?)

2) Are you looking for a processor that is specifically an automotive part? (a -Q1 part number?)

It does not look like we are planning to release an AM620-Q1 part with a PRU subsystem. However, if an automotive part is needed, we will release AM625-Q1 with a PRU subsystem in late October / November.

Regards,

Nick

hi，Nick

    Most of our waveforms are generated by the PWM controlled by M4F, but there are still a few pin waveforms that are generated by controlling the GPIO when the pwm is interrupted (pwm cnt == 0). The removal of ipc interrupts is to optimize the jitter of these signals。

   We are using the automotive-grade. 

   We initially used the AM6204-Q1. After the 625x was launched, we will switch to the AM6254-Q1

Regards,

Owens

Hello Owens,

I have unlocked the thread to continue the discussion.

1) If the GPIO signal truly needs nanosecond precision, I do not trust M4F to do that. Even if interrupts to the M4F are disabled, the writes to the GPIO module through the SoC bus infrastructure can have nanosecond jitter due to things like the other processor cores using the same infrastructure. I would suggest using the PRU for a usecase like that instead, especially if you are already planning to use AM625-Q1.

2) RPMsg is one potential implementation of inter-processor communication (IPC), but any kind of communication between cores is IPC. You could write a custom IPC implementation with shared memory, where Linux would write to the shared memory (and maybe write to a "ready" memory address after the data has been successfully copied to the memory region), and then the M4F polled the "ready" memory address to see when the data from Linux was ready for consumption.

We do not have an example of a shared memory region without a notification mechanism. The zerocopy example does show a shared memory region between Linux and the MCU+ core, so if you wanted to try implementing 2) on your own you could use that as a starting point, and then modify the notification mechanism to be polling based: https://git.ti.com/cgit/rpmsg/rpmsg_char_zerocopy/

If you do implement a custom IPC mechanism, please keep in mind that we are limited to supporting TI hardware and TI software on these forums. We are unable to support questions about custom code that TI has not written and validated.

Regards,

Nick

hi， Nick

1. " the writes to the GPIO module through the SoC bus infrastructure can have nanosecond jitter due to things like the other processor cores using the same infrastructure"This sentence is not very clear. Could you elaborate on it?

2. After adopting the zerocopy example solution at the bottom layer on the M4F side, can the code on the linux side maintain the original RPMsg framework?

Regards,

Owens

Hello Owens,

Jitter on GPIO writes 

If you haven't read the FAQ I linked above, I would start there:
[FAQ] What is a PRU core? Why are PRU GPIO signals different from regular GPIOs?

basically, with PRU cores, you have a direct connection between the core's internal registers and the pin. That is deterministic.

With M4F writing to a GPIO module and then the GPIO module writing to the pin, the signal has to go through a lot of bus infrastructure and other connection fabric. That is NOT deterministic.

Is it good enough for your usecase? That depends. If you could handle microseconds of jitter, it would be fine. However, if you truly need nanosecond precision, all that extra stuff between the M4F registers and the pin itself can add a variable latency to the signal toggling on the pin.

If you wanted to run experiments on silicon:

You could start by disabling RPMsg in the M4F. Set up the rest of your system to behave about how you would expect it to work in your system (i.e., do NOT use a tiny filesystem where Linux is not doing anything. This is not an accurate representation of the actual behavior of your final system). Measure the GPIO waveform with a highly accurate oscilloscope and see if the jitter is acceptable for your usecase.

What are the options for RPMsg? 

Option 1: leave RPMsg enabled, but do not send any RPMsg messages from Linux to the M4F, only from the M4F to Linux

Option 2: Disable the RPMsg driver entirely on the M4F core. You can still use Linux to initialize the M4F. Refer to the AM62x academy:
Multicore > Application Development on Remote Cores > Adding an empty resource table
https://dev.ti.com/tirex/explore/node?node=A__AdPW6wIW5LMq75KPg4Ojuw__AM62-ACADEMY__uiYMDcq__LATEST

Either way, you would need to implement a custom IPC solution.

Regards,

Nick

hi，Nick

  How does PRU establish communication with M4F or A53? Is it also through RPMsg？

Regards,

Owens