On a C6678. I can't seem to get Indirect Semaphore2 Interrupts to fire to save my life. It's not helped by the fact that the docs (SPRUGS3A) don't really seem to relate too closely to the actual hardware's behavior. For example, that document doesn't mention at all that you can directly take a semaphore by READING its control register at hSEM->SEM[0].
So I manually claim SEM0 on another core (say, Core 2). Then, I run this on Core 3:
void initializeSemInterrupt ()
{
CSL_GpioHandle hGpio;
Hwi_Params hwiParams;
Hwi_Handle hwiHandle;
Error_Block eb;
// this clears the SEMINT0 interrupt flag for core 3
hSEM->SEMFLAGL_CLEAR[3] = 1;
// this signals the EOI (end-of-interrupt) for SEMINT0, and re-arms it
hSEM->SEM_EOI = 0;
hSEM->ISEM[0] = 0; // writing a 0 to this register should claim it for myself, if it's available
printf ("after trying to take the semaphore 0 (D, I, Q) reads as 0x%x 0x%x 0x%x\n", hSEM->SEM[0], hSEM->ISEM[0], hSEM->QSEM[0]);
//Create HWi
Hwi_Params_init(&hwiParams);
Error_init(&eb);
hwiParams.arg = 5;
hwiParams.eventId = 16; // SEMINTn (SPRS691D/Table 7-38) where n is this core
hwiParams.maskSetting = Hwi_MaskingOption_SELF;
hwiParams.enableInt = FALSE;
// 5 is CPUINT5 - same as the VSYNC so don't use these at the same time
hwiHandle = Hwi_create(5, semIsr, &hwiParams, &eb);
if (hwiHandle == NULL)
{
printf ("you failed to create the Hwi hook. FAILED!!!\n");
}
Hwi_clearInterrupt(5);
Hwi_enableInterrupt(5);
// handle any error that the system feels like telling you about
if (Error_check(&eb))
{
printf ("oh crap\n");
}
} /* +initializeSemInterrupt */
Once that's run, I go back to core 2 and release the interrupt by writing a 1 to hSEM->ISEM[0]. It changes, as expected, from 0x00000200 to 0x00000300, because Core 3 was on the queue from the code above. The flags indicate that the Semaphore Module has sent an interrupt. But alas, no interrupt.
Is there a semaphore module-wide interrupt enable that I've somehow failed to set?
Overall, I get the impression that this module isn't used by a lot of people. If it were, it seems to me the docs would have been kept up to date, and there'd be appropriate examples somewhere.
The attempt was to establish a backdoor fast-messaging system between cores, for time-critical events, if I could get it running faster than MessageQ. Should I abandon that hope and not try to get this module to work?
