MCU-PLUS-SDK-AM243X: Routing an interrupt between cores

Felix Heil

Hello,

we currently had a use case where we use IPC but we also need really fast singaling from one core to the other.

We are using SDK 08.06. BoardCfg is not modified.

Is it possible to route an interrupt from one core to another? I think I understood how we can route interrupts via Sciclient_rmIrqSet. But I don't really see how I can trigger an interrupt via this route. for a connected Gpio it's quite understandable, but how does it works from another core?

I tried to understand by having a look at the IpcNotify-implementation but didn't get how the interrupt get's triggered. I guess simply the write to the Mailbox-address triggers an interrupt.

Is an equivalent implementation possible for the user?
I guess defining a memory-section in SRAM and write to it so it can automatically trigger an interrupt for the other core is not possible. But I think a manual trigger shall be possible? And which interrupts can be used for that?
The MAIN_GPIOMUX_INTROUTER0_OUTP I guess are reserved for any GPIO-interrupts.

Best regards

Felix

over 2 years ago

0 Ming Wei over 2 years ago

TI__Guru 54905 points

Hi Felix,

The IPC Notify example is designed for the low latency (~500ns) inter-core communication method. Please refer to the C:\ti\mcu_plus_sdk_am243x_08_06_00_45\examples\drivers\ipc\ipc_notify_echo for details.

The user guide for IPC Notify is AM243x MCU+ SDK: Understanding inter-processor communication (IPC)

Best regards,

Ming

0 Felix Heil over 2 years ago in reply to Ming Wei

Expert 1165 points

Hey Ming.

Yes I know this one. we already use RPMessage that's why IpcNotify is already occupied and cannot be used any other way.

Our scenario is that we need just a sync-interrupt from one core to the other (in the end it's about Profinet IRT and EtherCAT SYNC0 and SYNC1). Of course we could use our on-top-of-RPMessage-Message-Handler that we have implemented for our framework but it may be too slow for that since this relies on asynchronous communication since we would've running a FreeRTOS on every core and don't want to interfer with the priorities and shadow them by directly accessing one core from the other one. Here a high-priority-task can be interrupted by a low-prio task from the other core and we want to prevent this. That's also why we wanted a notify-callback for the Ipc (which was implemented in SDK 08.03 or 08.04 I think) so we can just throw an event and a task can then read out the buffer of RPMessage.

So via this way it is not possible with our setup. We may think of a solution in the future where we share priorities via cores in some way and introduce some small handler-tasks which take the temporary priority of the call from the other core but that may bring up more problems.
And still I'm not sure if RPMessage on top can ensure the low latency we would need.

Is there no possibility with the internal routing?

Best regards

Felix

0 Ming Wei over 2 years ago in reply to Felix Heil

TI__Guru 54905 points

Hi Felix,

Since you already used the IPC RPMessage, so the IPC Notify is not an option anymore.

The other option is to use the ICSSG IEP0 for inter-core synchronization. I am not an expert on this topic. Therefore, I will forward this thread to our experts for further help.

Best regards,

Ming

0 Nilabh Anand over 2 years ago in reply to Ming Wei

TI__Mastermind 44514 points

Hi Felix,

Apologies for the delay,

I am looking into the thread, could you please help me understand the use case

Felix Heil said:
Is it possible to route an interrupt from one core to another? I think I understood how we can route interrupts via Sciclient_rmIrqSet. But I don't really see how I can trigger an interrupt via this route. for a connected Gpio it's quite understandable, but how does it works from another core?

Which cores are we talking about here? Is it between the PRU cores or between PRU and R5F