Hi all,
IMOD54415, Dev 2.7.7
Have there been any changes to the underlying hardware on the 54415 with respect to interrupts? Like, is there a new buffer or anything? I've been using the same code base for a few years, and it's always been pretty reliable. Lately, though, I'm starting to have problems with the interrupts. I can see the interrupt firing on the pin with my scope, sometimes it gets caught, sometimes it doesn't. It's just weird because I haven't seen this problem before. I'm totally pulling my hair out on this one. Is there anything that might be even a little bit different on the IRQ interface?
Thanks, Dan
Any IRQ changes to MOD54415?
-
DBrunermer
- Posts: 67
- Joined: Thu Apr 21, 2011 7:06 am
- Location: Pittsburgh, PA
Re: Any IRQ changes to MOD54415?
Nothing on hardware.
The newest compiler is more agressive in optimization, so if the ISR is changing a variable and
different task is using that variable, the change will be missed unless the variable is marked as volatile.
IE:
bool bInterruptHit;
interrupt bInteruptHit=true;
while(1)
{
if(bInterruptHit)
{
printf("ISR hit\r\n");
bInterruptHit=false;
}
}
The printf will never happen.
If the variable bInterruptHit is not marked as volatile.
The compiler is smart enought to see that nothing in the while loop can change bInterruptHit, so it reordered the code to only check on the way in, otherwise it just sits in the while, not checking.
The newest compiler is more agressive in optimization, so if the ISR is changing a variable and
different task is using that variable, the change will be missed unless the variable is marked as volatile.
IE:
bool bInterruptHit;
interrupt bInteruptHit=true;
while(1)
{
if(bInterruptHit)
{
printf("ISR hit\r\n");
bInterruptHit=false;
}
}
The printf will never happen.
If the variable bInterruptHit is not marked as volatile.
The compiler is smart enought to see that nothing in the while loop can change bInterruptHit, so it reordered the code to only check on the way in, otherwise it just sits in the while, not checking.