TMS320C6748: Interrupt wake up from IDLE?

Mike,

Mike Rosing said:

I thought the processor wakes up when an interrupt happens

That is how it works. Technically, the CPU is executing a multi-cycle NOP but it will slip off the IDLE when an interrupt occurs.

Mike Rosing said:

Is there some other bit that needs to be flipped before IDLE so that does happen?

I am pretty sure GIE needs to be enabled, but the interrupts do not need to be individually enabled. At least that is how it worked on earlier C6000 devices so should have been carried into the newer C674x core.

There is no other detail that I can find about coming off the IDLE, but you should be able to set up some controlled tests to get it working well. At first in your testing, I would make sure IFR=0x0000 before hitting the IDLE, make sure you are in supervisor mode and not user mode, make sure GIE=1, then after reaching the IDLE let an enabled interrupt get triggered.

Are you using the simple interrupt selector or are you going through the event combiner?

What are triggering your 4 interrupts? External events like GPIOs? Are you using one of the internal timers?

Regards,
RandyP

Hi Randy,

I'm using RTC, timer2 and the EMAC tx and rx.  I did not look at user vs supervisor mode bits, that is a good clue and I should check that.  Timer2 runs in 1 msec continuous mode, so I expect the idle to break once a millisecond.  I'm use the RTC to increment a counter, so it should test about 1000 times before it breaks out of the loop.  Here's what I've got:

void sleep(int n)
{
    int then;
    
    then = epocsec + n;
    while(epocsec < then) __asm("  idle");
}

epocsec is incremented in the RTC interrupt.  The debugger hangs when it gets to the idle, so then I push the "pause" button and see that epocsec is 27 and "then" is 14.  So the interrupts are still happening but the comparison never takes place.  It's like it returns to the idle instruction instead of to checking the loop.  If I put a break point in the RTC, it doesn't break either, but there might be something going on between the hardware debugger, software breaks and idle mode.  But still, it should execute code and then go into the infinite nop mode until the condition is satisfied.  Then it should leave the routine.

That's why I'm confused.  But I will check to see if the supervisor mode bit gets flipped somewhere.

Mike

Good guess! That fixed it.   I suspect it will also fix the break in the ISR, but since the ISR works there is no reason to continue beating my head on that.  The RTC increments epocsec once a second, and that is what is being checked, so it all works.

Thank you!!!

Mike