TMS320F28379D: Interrupt configured in CPU1 not being triggered in CPU2.

Hi Raghavendra,

Have you handed over permissions of the ePWM1 peripheral to CPU2? I believe the recommended way to do this is to configure the ePWM1 and PIE on CPU2 after permissions have been passed over.

There are some good IPC examples that would be helpful to take a look at in the C2000ware path: [C2000ware install]/driverlib/f2837xd/examples/dual/. I would suggest looking at the SCI example to see how permissions are passed over for a peripheral and the DMA example to see how interrupts on CPU2 are configured.

Best Regards,

Delaney

Hello Delaney,

Thanks for providing the response and the example links.

To elaborate on my workflow:

I am deploying Simulink models on both cores of the target. The ePWM1 is configured on CPU1, while CPU2 does not configure ePWM1, except for servicing its ISR.

In this context, is it still necessary to transfer the ePWM1 peripheral permission to CPU2?

In reference to the shared DMA example, there appears to be additional code that enables the corresponding Peripheral Clock via the 'SysCtl_enablePeripheral()' function. I attempted to incorporate similar code to enable the ePWM1 clock on CPU2 using the following line: 'SysCtl_enablePeripheral(SYSCTL_PERIPH_CLK_EPWM1);'

However, this change did not have any impact, and the ISR remains unserviceable on CPU2.

Could you please advise if there are any additional registers or settings that need to be configured?

Thanks for your assistance.

Best Regards,

Raghavendra

Hi Raghavendra,

Delaney is currently out of office but will get back to you as soon as she can after her return.

Best Regards,

Aishwarya

Hi Raghavendra,

If you are servicing the ISR from CPU2, then CPU2 will need permissions for the ePWM1. In most ISRs, the peripheral registers are accessed which as well you would not be able to do if the current CPU didn't have permissions for the peripheral. You also would usually configure the ePWM from CPU2 as well.

I'm a little confused why you are trying to have do all initializations/ownership on CPU1 but just service the ISR from CPU2? I suppose if you really wanted this, you could just set up a IPC interrupt on CPU2 that your software trigger from inside the ISR on CPU1.

Also, in the folder I mentioned previously, I would suggest taking a look at the dma example in here. It has a good example of using different peripherals on each CPU and configuring interrupts on each. You should be able to do your implementation in a similar way.

Best Regards,

Delaney

Hello Delaney,

Kindly refer to the snapshot from the F2837xD Technical Reference Manual (TRM) attached below:

Referring to the highlighted section, the peripheral can be owned by either CPU & the corresponding interrupt can be triggered on the other CPU if PIE is configured on it.

Transferring the ownership of the peripheral from one CPU to another in order to service the ISR would contradict the information specified in the TRM.

Could you please confirm this?

I agree that if the interrupt is both configured and serviced on the same core, it'll work as expected.

Thanks,

Raghav

Hi Raghav,

My mistake, yes you are correct. You can indeed trigger ISRs on both CPUs even though a peripheral can only be owned by one at once. Even though you can trigger an ISR on the non-owning core, that core still wouldn't be able to access peripheral registers inside the ISR (or anywhere) without access to the peripheral. So, in most cases, it wouldn't be very useful to trigger an ISR on a core synchronized to an IP the core doesn't have access to. 

How have you tried debugging this for your project? Did you add a breakpoint into the ISR on the non-owning core? Can you verify that the IER for the group, PIEIER for the interrupt and global interrupts are enabled from that core's context in the Register window?

Best Regards,

Delaney

Hi Delaney,

Yes, I have tried debugging it in my project. The interrupt is not being serviced on the non-owning core, code isn't entering the ISR.

I have verified the PIE & global interrupts are enabled on the non-owning core i.e.

• PIE Registers: PIECTRL -> ENPIE & PIEIER3 -> INTx1 are set to 1.
• Core Registers: IER->INT1 is set to 1.

As you mentioned, I can't view or modify any of the values in the ePWM registers from the non-owning core.

Thanks,

Raghav

Hi Raghav,

I apologize for my delay in response.

Instead of a breakpoint in the ISR can you try incrementing a counter in the ISR (and checking this in the expressions window with Continuous refresh enabled)?

Can you also verify that the ACK is for that group is closed when you are expecting this interrupt to happen? Since only the owning core can close the ACK it may be some synchronization issue. With this sort of implementation, there could be some timing issues between the CPUs. I would suggest using IPC for each to synchronize the operations.

Also, in the non-owning core, you want to keep the ISR as short as possible so that the timing again is not interfering. I would suggest just using the ISR in CPU2 to set a global flag then checking for this in your main loop and performing any needed code there.

Best Regards,

Delaney