iHC12 Interrupt problems

[patti]

Hi, I am developing on processor HC12 and working with interrupts.

I am having interrutps for SCI, TIMER, and MSCAN RX/TX

I have noticed that when an interrupt interrupts an other interrupt the processor get's lost and works unexpected. What shall I do?

thanks in advance, Patrik

[mke_et]

Well, basically single step it through and find out where you're colliding.

I know, you didn't want to hear that...

Usually the most common problem, at least for me, is a tendency to write your interupt handler such that it thinks it's the only one in there. Then when a second interupt occurs, it's out of sync.

For example, you have a flag byte. One interupt sets bits 3 and 7, the other 2 and 6. But if you're ISR reads the flag byte, plays with it, then writes it back out, that can be a problem, since the other ISR can get in and read and write between your read and write. The result is that one ISR essentially erases what the other ISR has done.

The other problem, harder to find, is when one interupt does something the other ISR depends on. And not just in the ISR itself. This can get tricky when the ISR calls outside 'foreground' tasks. What if the ISR calls the outside foreground task while the outside task is currently being executed? Have to watch for those collisions too.

There's not a good solid hint here. It's a 'mindset' that you have to have to write ISRs. And the only real way to find the problems is to just set down and start single stepping...

[patti]

Thanks for your relplay...

So what can I do, to prevent interrupts from distracting each other?

Are there any magic code for recommended interrupt ímplementation? :smileywink:

thanks

[mke_et]

Magic code? Sure, I'll sell you some cheap! It does require a bit of customization though. Actually, it's a blank page. Seriously, always make sure you save EVERYTHING in every interupt, and write it so that it only touches things it knows about and won't care. And always write your interupts from the point of view that they may stack, and ALSO that they may be phantoms. What happens if you get an interupt and in the process of servicing it you clear another interupt? Can your routines handle that case? I always write my ISRs so that the interrupt is the trigger and they 'loop till empty'. That way if they trigger empty, they just fall though cleanly. (I guess that's an outgrowth of writing ISRs for PCs with 8259 controllers, which would issue phantom IRQ7's all the time!)

But really, I'd look for the problem first, rather than a workaround. I got bit on my 08 project when I was getting lots of interupts. Turned out I was relying on one of the high bytes being saved. Well, 99.999% of the time it didn't matter, but there was a single case where the high byte wasn't at the default, and since it wasn't saved, guess what? Blowup time.

[patti]

Hi, yes thank you for your answer.

Let's start working

[mke_et]

All right... What are you willing to pay???

Sorry, couldn't resist!