question: interrupt nesting

hi folks,

I'm experiencing some problems on a Renesas M32C:

it seems that a higher priority interrupt can't interrupt a lower priority one. To be honest, the datasheet doesn't anything about this thing, so I assume that it is impossible for this CPU to interrupt a lower priority interrupt to serve a higher one.

My question is:

can CPU's interrupt a lower priority interrupt to serve a higher one?

thanks Enrico

Reply to
Enrico Migliore
Loading thread data ...

I am not familiar with this CPU, but on most CPU's interrupts are disabled on entry of the handler. So you have to re-enable interrupts as soon as possible, preferably *after* 'removing' the reason for the current interrupt. I once made the mistake on an AVR to re-enable interrupts in the handler for the serial port, *before* reading the received byte from the UART...... endless waiting.......:-(


Reply to
Meindert Sprang

Hi Meindert,

yes! your right! I've just fixed this thing.

thank you Enrico

Reply to
Enrico Migliore

Enrico, it will be the same as with the M16C: You have to set the global interrupt enable bit upon function entry to any ISR if you want it to be interruptible.

The M16C , when it gets an interrupt request, jumps to the vector which contains the jump to the ISR address. The return address and the FLAG register is stored on the stack. At the same time the I flag is cleared by hardware and: -- only after RETI the FLG register is restored.

Thus, for every ISR that you want to have interrupted (or cascaded) by a higher priority ISR you will have to set the global interrupt enable flag as one of the first instructions in the ISR.

regards /jan

Enrico Migliore schrieb in im Newsbeitrag:

Reply to
Jan Homuth

Been there, done that !!! Pain is indeed a wonderful teacher. Glad to see others do it the same way.

-- Mike "mikey" Fields

formatting link
outgoing email scanned by Norton Antivirus ... is that good ?

Linux users brag on how long their system stays up, Window users assume it's a temporary condition ...


Reply to
Mike Fields

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.