Xmega и sleep, Что с питанием во время сна? Опции

[zombi]

Начинаю "мучать" ATxmega64A1.
Экспериментирую со sleep режимом power-save.
CPU тактируется int. RC2MHz, RTC ext. 1024Hz.
Питание 3.3v на мегу подаётся через диод шоттки (BAT54C) падение порядка 0.3v.
По старту инициализируем портА,RTC и сразу засыпаем (pover-save).
Просыпаемся по переполнению RTC.
В преравании небольшой код и смена состояния ноги портаA.0 на противоположное.

на осцлограмме:
CH2 - пин портаA
CH3 - VCC.
Видно что после засыпания питание на процессоре и на пине (если он в 1-це) плавно поднимается почти до 4-х вольт !
Откуда берутся эти лишние 0.7v? опасно ли это для процессора при максимально допустимом питании 3.6v ?
Если в sleep не уходить то питание на проце стабильно и не превышает 3.0v.
З.Ы. Если закоротить диод шоттки то питание тоже нормальное 3.3V.

Эскизы прикрепленных изображений

 

[ILYAUL]

У меня есть некоторые разъяснения относительно исправления 34. Есть несколько причин
почему прерывание может быть отложена.
1) прерывание происходит в то время как глобальный флаг прерывания в SREG не установлен
2) Если другое прерывание обрабатывается в то время как IRQ срабатывает

После прерывания, XMEGA всегда возвращается и выполняет одну команду кода, даже если есть другое
прерывание на рассмотрении. Это сделано во избежание блокировки процессор из-за высокой
частота прерывания.
Таким образом, надо смотреть на ошибки, связанные с асинхронными RTC-прерывание.

Если другое прерывание обрабатывается, когда происходит асинхронное RTC-
IRQ , то RTC-IRQ еще не принято.

Не переводимый полёт мысли:

If the one instruction which gets processed after the previous interrupt is the sleep instruction, the async
RTC-irq will only be processed after something else wakes up the processor.

Я понял так
Если обрабатывается комманда , после предыдущего режима сна , RTC - будут обрабатываться , только после того как проц "придёт в себя" (похмелиться значить)

Тип установленного режима сна не является актуальным.

И вообще пофиг в каком режиме будет пропуск RTC - на одну комманду см. пункт 2

Асинхронный-RTC IRQ разбудит процессор, если это происходит в то время как процессор
спит. Так что только очень редко, что вышесказанное будет вызывать проблемы.

Этот исправленый (№ 34) очень тесно связан с ошибками 23: Pending full
asynchronous pin change interrupts will not wake the device.

С наилучшими пожеланиями,
Глен Нильсен
Atmel технической поддержки команды

ИСХОДНИК
I have got some clarification on errata 34. There are a couple of reasons
why an interrupt could be pending.
1) Interrupt happens while global flag IRQ enable in Sreg is not set
2) If another interrupt is being processed while the IRQ is triggered

After an interrupt service routine, the XMEGA always jumps back to where it was in the code and executes one instruction, even if there is another
interrupt pending. This is to avoid locking up the processor with high
frequency interrupts.
So to look at the errata relating to the asynchronous RTC-interrupt.

If another interrupt routine is being processed when the asynchronous RTC-
irq occurs, then the RTC-irq is pending. If the one instruction which gets
processed after the previous interrupt is the sleep instruction, the async
RTC-irq will only be processed after something else wakes up the processor.

The type of sleep mode set is not relevant.

An async-RTC irq will wake the processor if this occurs while the processor
is asleep. So there is only a very rare that the above condition will cause
problems.

This errata (no 34) is very closely linked to errata 23: Pending full
asynchronous pin change interrupts will not wake the device.


Best Regards,
Glen Nilsen
Atmel Technical Support Team