Waking XMEGA from sleep

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

If an XMEGA is woken up from sleep but misses the interrupt that caused it, does it go back to sleep or continue executing code?

Specifically, I have an xmega that needs to be woken from sleep mode by one of three things, two of which are port pins (the other is the RTC, but I'm not as worried about that). Thanks to some hardware design that was out of my control, at least one of the wakeup pins is only going to be partially asynchronous, which is to say that if it changes then changes back before the xmega can come out of sleep, the interrupt will not be generated. I'm not that worried about figuring out which interrupt woke me since they all do the same thing, I was just wondering what will happen. If the chip wakes up and sees no interrupts, will it go back to sleep, or continue executing code from where it left off?

Thanks

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

Quote:

if it changes then changes back before the xmega can come out of sleep, the interrupt will not be generated.

??? Is this pulse like a few nanoseconds? [full disclosure: I've only read about Xmegas] I'd assume any wakeup source will be like real AVRs and that interrupt flag bit will be latched until cleared. I'd assume "asynchronous port interrupts" on the Xmega would work just fine. While the pin state may have gone away, can't you put the wakeup pins on different "banks" and then you know which caused the event?

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

From the XMEGA A Manual, section 13.7 about port interrupts:

Quote:
For asynchronous sensing, only port pin 2 on each port has full asynchronous sense support.
This means that for edge detection, pin 2 will detect and latch any edge and it will always trigger
an interrupt request. The other port pins have limited asynchronous sense support. This means
that for edge detection the changed value must be held until the device wakes up and a clock is
present. If the pin value returns to its initial value before the end of the device start-up time, the
device will still wake up, but no interrupt request will be generated.

And the Manual section for the sleep mode I will be using (Power-Save Mode)

Quote:
8.3.2 Power-down Mode
In Power-down mode all system clock sources, including the Real Time Counter clock source
are stopped. This allows operation of asynchronous modules only. The only interrupts that can
wake up the MCU are the Two Wire Interface address match interrupts, and asynchronous port
interrupts.
8.3.3 Power-save Mode
Power-save mode is identical to Power-down, with one exception:
If the Real Time Counter (RTC) is enabled, it will keep running during sleep and the device can
also wake up from either RTC Overflow or Compare Match interrupt.

I don't really expect the pulse to be short enough that I will miss it, I was just wondering if anybody knew what would happen if I did.

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

that seems to be a semi-ouch, eh? To get a feel for the whole context does that apply to just "pin change" or other "external interrupts"--dunno.

If you only need a few then they could be sorted out. A glance at the alternate functions chart indicates pin 2 is RXD and an OC pin on each port so you end up with alternate-function juggling.

[thanks for bringing it up to keep in the back of my mind when I do start working with Xmega--for the same instruction set there sure is a lot of learning to undo]

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

theusch wrote:
--for the same instruction set there sure is a lot of learning to undo

Tell me about it.

I believe this only applies to pin change interrupts and that most other types (except asych. ones like the TWI)run off the peripheral clock, which I am shutting down for my sleep state anyway.

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

jgiers wrote:
If an XMEGA is woken up from sleep but misses the interrupt that caused it, does it go back to sleep or continue executing code?

Are there any answers to this question in meantime?
We got Issue that XMega is not waking up at all (Debugger tells it's still in sleep mode).

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

I had a similar problem, I placed the XMEGA in sleep during an interrupt. For the XMEGA to wake up, another interrupt with higher priority had to occur.

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

ganzziani wrote:
I had a similar problem, I placed the XMEGA in sleep during an interrupt. For the XMEGA to wake up, another interrupt with higher priority had to occur.

Current level interrupt executing flags are marked as read-only in PMIC.STATUS. It is written in XMEGA A manual that only RETI instruction clears the flags. However try to clear the current level flag by software before executing SLEEP instruction and maybe it works.

Ozhan KD
Knowledge is POWER

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

and if the sleep mode is not activated within an ISR!?

WakeUp would be enough, there's no need to have Interrupt. We use different PIN than 2, but from manual point of view it should be ok:

Quote:
A low level can always be detected by all pins, regardless of a peripheral clock being present or
not. If a pin is configured for low level sensing, the interrupt will trigger as long as the pin is held
low. In active mode the low level must be kept until the completion of the currently executing
instructions for an interrupt to be generated. In all sleep modes the low level must be kept until
the end of the device start-up time for an interrupt to be generated. If the low level disappears
before the end of the start-up time, the device will still wake up, but no interrupt will be
generated.

But actually it's not waking up :(