C6474 IPC - doesn't receive an Interrupt

HR said:

I'm using the IPC for the 6474 cores sync, generally it is working well but sometimes one or two cores does not received an interrupt, what can be the issue? should I use the SEM for accessing the IPCGR?

Check the errata file for the version of silicon that you are using. There might be issues stated that could have affected your use of this module. The intention of the IPC module is that no SEM use would be required and that all interrupts would be forwarded to the intended core. There are a lot of things you could be doing in software that contribute to missed interrupts. If you can narrow down the problem, it will help.

HR said:

what happen if two cores are trying to access the same IPCGR at the same time?

The SCRs and Bridges guarantee that only one core will actually write to an IPCGR register on any clock cycle. Arbitration occurs to select which one goes through [first] when there are simultaneous writes. And since the IPCGR register latches any SRCSn bit that is set to one by any core, there should be no problem with Core1 writing to IPCGR0 immediately followed by Core2 writing to IPCFR0. Of course, you would have both cores setting different SRCSn bits; otherwise there would be no way to know which core was signaling the interrupt.

And you may need to be careful about possible race conditions that could occur if Core1 causes an interrupt to Core0 and Core2 writes to IPCGR0 during the execution of the Core0 ISR.

Thank you very much, RandyP

I really appreciat for your help.

Best Regards.

@_@|||   I replied to a wrong post...

Hi Randy,

I reviewed the errata and I'm not using the SEM and the FSYNC, I will check the race condition, in case core#0 is executing the IPC ISR and core#2 is writing to IPCGR0 will core#0 gets another interrupt or he will miss it?

Many Thanks for your help,

HR

HR said:

in case core#0 is executing the IPC ISR and core#2 is writing to IPCGR0 will core#0 gets another interrupt or he will miss it?

My concern was that an interrupt could be missed. But this was only because I have not looked at it closely. As long as you do not clear a bit in IPCGR without servicing it, you will probably not miss an interrupt. It does make sense that an extra interrupt could be generated in some cases, too, but this would easily be handled by reading IPCGR and handling the simple case where no SRCSn bits are set.

Randy,

OK, but does it mean that unless I clear the IPCGRn SRCSn bits I will always get an Interrupt ? what I thought was that I will get only one Interrupt by setting the IPCG bit in the IPCGRn regardless the SRCSn bits,

Many Thanks,

Haim

You are correct that only a write of 1 to the IPCG bit will cause an interrupt. If one write to IPCG occurs and then another write of 1 occurs to the same IPCG bit, then you may get just one call to the ISR and you may get two calls to the ISR. This will depend on the timing (how close together) of the two writes and the timing of the second write relative to the operation of the ISR.

Randy,

Understood, Many Thanks for the help,

HR