Missed interrupt question

Go To Last Post
4 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi All,

I've inherited a huge XMega code base (~60kloc) with a strange problem: Throughout there are code snippets of the form

while (!something_finished) ;

...

ISR(SOME_vect)
{
  something_finished = true;
}

but once every 20-50 times the while loop is invoked, it hangs indefinitely. The variable in question is correctly declared volatile.

When I pause execution on the debugger, the SREG I bit is set, the PMIC level enable bits are all set, the peripheral has a non-zero interrupt priority, the specific interrupt enable bits are set, the interrupt flag is set, but the ISR has never been called!

I'm fairly sure this is a software problem as I've got a big switch I can use to disable 2/3rds of the code base and if I do that, all seems to work fine. Note that the bit of the code I turn off doesn't directly (intentionally!) touch the peripherals in question, but will play with the PMIC in various ways.

The question is, before I go sifting through 40kloc, what should I be looking for? What kind of software construct can cause an ISR to stop being called when ever single bit down the chain is still set? I'm stumped..

Cheers,
-S.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'll start with the stupid suggestions :) stack corruption.

Do you have a breakpoint set in the ISR to see if it actually fires (hardware ok) and then the program goes into outer space?(software issues)

Of course I know next to nothing regarding the Xmegas :(

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Cheers JS, you're pretty much bang on :)

Turns out under some circumstances a low priority interrupt was corrupting its stack such that it worked in every way, except returned with a 'ret' rather than a 'reti'. This meant that the 'low priority executing' flag was never cleared in the PMIC and that priority level was effectively locked out. Most of the irqs operate at a higher priority, so the system would continue in this state with no ill effects for tens of minutes, but eventually another low priority interrupt would be queued and not fire.

By the time the problem appeared everything appeared normal, the corruption had worked its way out and the system had been working fine for ages - except that that PMIC bits indicated I was in an ISR when the PC actually pointed to the polling loop.

Ah feels good to get a win once in a while :)

Thanks,
-S.

EDIT: ps for those interested, and just for a giggle, the condition that caused the corruption was linked to some data read from an accelerometer - the bug came and went depending on the angle at which the board sat on my desk :DD

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Had my lucky undies on today therefore the good guess. :lol:

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly