STOP instruction with IRQ low? - MC68HC9S08GB32

[BlkStang]

What happens when a 9S08GB32 executes a STOP intruction when the IRQ pin is low?

We use stop1 in our product for the very, very low power consumption it offers and use IRQ to wake it up. Normally everything is fine but we have found that if conditions are "just so" and our shutdown logic executes, the code may inadvertently run the stop instruction when IRQ is still low. It appears to me that the micro doesn't actually stop and re-start as if a POR occured but may continue executing at the instruction following the stop opcode.

This makes bad things happen in our code... We're working to correct the code to prevent this but I'm wondering if someone has any information on what the uC actually does when IRQ is already low and stop executes.

Thanks.

Added p/n to subject.

Message Edited by NLFSJ on 2008-07-17 07:28 AM

[bigmac]

Hello,

By default, the external IRQ interrupt is negative edge triggered.  This means that the next interrupt will not recur until the pin goes high, and then again low.  It is possible to configure for both edge and level sensitivity, but this might present other issues that would need to be addressed - the repeated re-entry to the ISR code whilst the IRQ pin remains low.

For some stop modes, the execution of the wakeup source ISR, then followed by execution of the instruction following the STOP instruction, is normal.  If you always require a reset following stop, independent of the stop mode entered, the code immediately after STOP should force a reset.  The illegal opcode method might be appropriate here.

By the way, it is very important that the STOP instruction never be placed within any ISR code.  This is because interrupts are automatically globally enabled prior to entering stop mode.

Regards,

Mac

Message Edited by bigmac on 2008-07-18 11:09 AM

[BlkStang]

---

bigmac wrote:

Hello,

By default, the external IRQ interrupt is negative edge triggered.  This means that the next interrupt will not recur until the pin goes high, and then again low.  It is possible to configure for both edge and level sensitivity, but this might present other issues that would need to be addressed - the repeated re-entry to the ISR code whilst the IRQ pin remains low.

For some stop modes, the execution of the wakeup source ISR, then followed by execution of the instruction following the STOP instruction, is normal.  If you always require a reset following stop, independent of the stop mode entered, the code immediately after STOP should force a reset.  The illegal opcode method might be appropriate here.

By the way, it is very important that the STOP instruction never be placed within any ISR code.  This is because interrupts are automatically globally enabled prior to entering stop mode.

Regards,

Mac

Message Edited by bigmac on 2008-07-18 11:09 AM

---

Thanks for the reply.

Just to clarify: In the document MC9S08GB60/D V1.5, section 3.6.1, the description of the
stop1 mode indicates that the IRQ pin "[i]is always an active low input when the MCU is in stop1, regardless of how it was configured before entering stop1.[/i]" I've always assumed this to mean low-level, not low-going. The fact that the processor seems to continue on past the stop instruction when IRQ is low indicates that the level matters in stop1, not the edge. That is, it didn't need a low-going edge to get out of stop mode...it never even stopped.

The pdf goes on to say "[i]Upon wake-up from stop1 mode, the MCU will start up as from a power-on reset (POR). The CPU will take the reset vector.[/i]" This is the root of my query: If after waking from stop, the micro acts exactly as if it is a POR, then the way the machine is behaving right now tells me it doesn't go into stop1 mode after executing stop when IRQ is low because instead of resetting, it seems to simply continue on past the stop instruction.

I really agree that a trap be put in after the stop to force a reset and that's what we're going to be doing. COP and ILOP won't work because we trap those in the boot/reset code as serious fault conditions. What I've been doing lately is something like:

Code:

.
.
.
//force a soft reset
DisableInterrupts;asm{ ldhx  $fffe ;get POR vector
 jmp ,x ;pass control there

}//asm

 Not pretty and not a true machine reset but a way to get back to the code that runs out of POR.

[peg]

Hi,
This scenario does not seem to be covered by the manual.
That is, if STOP is executed while IRQ is held low, does it enter stop mode and immediately come out?
OR
Does it simply continue on as if it wasn't there?

The following two statements seem to indicated that it is level triggered:

5.5.2 External Interrupt Request (IRQ) Pin
External interrupts are managed by the IRQSC status and control register. When the IRQ function is
enabled, synchronous logic monitors the pin for edge-only or edge-and-level events. When the MCU is in
stop mode and system clocks are shut down, a separate asynchronous path is used so the IRQ (if enabled) can wake the MCU.

3.6.1
.....
Exit from stop1 is performed by asserting either of the wake-up pins on the MCU: RESET or IRQ. IRQ is
always an active low input when the MCU is in stop1, regardless of how it was configured before entering
stop1.

[bigmac]

Hello,

Your observed symptoms might appear to fit the following scenario -

1. IRQ pin level sensitive only for wakeup, as has been pointed out.
2. If IRQ pin is low when STOP instruction is encountered, stop1 power down does not occur and there is no reset operation - perhaps actual operation might be as for stop3 or wait modes.

Does IRQ ISR code execute under these conditions?  If so, the indexed jump to the vector address could alternatively occur within the ISR.  Normal exit requirements from the ISR code would not apply since the stack pointer would always be re-initialised.

Regards,

Mac