Начинаю "мучать" 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.

Возможно регулятору напряжения в вашем устройстве для нормальной работы необходим хоть какой-то минимальный потребитель тока. XMEGA в спящем режиме потребляет очень мало (микроамперы). Проверьте по даташиту есть ли требование минимального выходного тока для работы регулятора.

В том то и дело что на выходе регулятора напряжение 3.3V !

Тогда вопрос, куда подключен второй диод из состава BAT54C, и нет ли в схеме иных источников напряжения более 3.3V.

Вероятно, виноват все-таки регулятор. Возможно, на его выходе присутствуют очень короткие выбросы напряжения, которые вы не видите.
При нормальном токе потребления они погоды не делают, а при микропотреблении - поднимают напряжение после диода.
Попробуйте поставить керамический конденсатор до диода.

Плюс еще очень многие LDO-регуляторы плохо работают при малой нагрузке (конкретно - повышают напряжение). Вы проверяли свой источник на нулевых токах?

Второй диод на батарейке CR2032 3v.
При работе от неё превышения напряжения не наблюдается.

Конечно есть, из 5-ти вольт получаю 3.3v на TS1084.

Конечно присутствуют и я их вижу. В схеме несколько потребителей основного 3.3v и пульсации довольно большие.
Т.е. происходит накопление напряжения (суммирование положительных пульсаций) на конденсаторах стоящих по питанию проца после диода?
Как же с этим бороться?

Как обычно. Фильтровать питание.

Очень похоже на подъем питания через защитные диоды проца с одной из его ног.

Все порты (кроме Q и R) настроил на вывод с подтяжкой к GND и вывел в них ноль.
Кроме того на портах A-F еще и отключил входные буферы.

А как это может быть "подъем питания через защитные диоды проца с одной из его ног" можно подробней?

Так совершенно аналогичный механизм. У каждой ноги, где имеются внутренние (встроенные) защитные диоды к питанию и/или к земле
возможен такой же эффект. Кстати, подъем напряжения питания будет при выбросах напряжения на ноге как выше питания, так и ниже земли. Если есть
оба диода. А как правило - есть.

На каждой ноге на входе два диода - на питание и на массу.
Если к ноге подключена через резистор цепь с большим напряжением, то через эти диоды начинает течь ток. Пока потребление по цепи питания высокое, то эта паразитная запитка не заметна - просто стабилизатор слегка призакрывается. Но когда потребление падает до микроампер - вот тут этот ток сперва закрывает стабилизатор, а затем начинает поднимать напряжение питания.
Методы борьбы - или стабилитрон по питанию или увеличивать резистор.

ОК спасибо с защитными диодами прнятно.

Вот что выяснил:
На XLAT1 поступает внешняя частота от плис (у меня 16MHz с EPM3128).
Питание растет только если хмега в слипе и частота на XLAT1 присутствует.
Если XLAT1 в воздухе то питание в норме.
И поскольку внешняя частота всётаки необходима склоняюсь к стабилитрону, но как то не нравится мне это решение.
Может чё другое придумать?

Интересно, а зачем Вам слип-режим, если от внешнего источника питания работаете? Электричество в розетке экономите?
Мне кажется более логичным подход, что если МК спит, то все остальное вообще должно быть отключено. Разбудили МК, он запустил всю остальную
периферию в работу. Отработал ситуацию, отключил все и снова спать... Впадение в спячку имеет смысл только в таком случае, и только когда
работаем от батареи... Иначе смысла большого нет в этом режиме...

Уходите в анабиоз - переключайтесь на внутреннюю 32 и баиньки.

Электричество в розетке меня меньше всего беспокоит.
Дело в том что проц засыпает по спадающему фронту сигнала внешнего супервизора питания.
А просыпается раз в секудну и анализирует состояние супервизора : если LOW то спим дальше , если HIGH то начинаем работу причем от внешнего CLK.
При включении внешнего питания получается что внешняя частота на пине уже есть а внешний супервизор пока что еще в нуле (~250-300ms). В этот момент питание на проце и растёт.
Когда проц активизируется то питание падает до 3V.
А если не дождавшись активизации выключить питание то получается что питание подросло а проц так и не запустился, на следующей секунде повторяем процедуру.
И поднимаем питание почти до 4-х вольт! прям LADDER какой-то получается

Получается что кроме стабилитрона дугих вариантов нет?

По моему, выход из слип-режима нужно переделать. Просыпаться - непосредственно по сигналу появления внешнего питания.
Тогда лишние проблемы сами отпадут...

А где такой сигнал взять?
Завести внешнее питание на асинхронный пин и просыпаться по переднему фронту?

Почему бы не взять с выхода того же регулятора до диода?

ОК буду пробывать.

И еще вопрос: наткнулся вот на такой "Errata 35.1 ATxmega128A1 rev. H"

Знание аглицкого подводит и гугловский переводчик не помогает.
А хочется понять о чём речь?

Асинхронное прерывание RTC самостоятельно из sleep-а камень не выдергивает.

....

Опять ни чё не понял

Речь о том, что если произойдёт прерывание RTC в момент исполнения команды sleep, то пробуждения не произойдёт, те прерывание будет потеряно. Пробуждение произойдёт при следующем срабатывании RTC или другого источника, способного вызвать wake-up.



Выводит из режимов Idle. Power save и Extended Standby. Из остальных не выводит.

Пока , кто нить , его не разбудит или что-то переключится снова (... or the
source triggers again. - китайцы , что ли это писали)
Проблема извесна / Решения - нет

Агаааа, теперь всё понятно! Спасибо!



Может после Idle нужна запятая а не точка?
Но причём здесь это? я вроде не спрашивал

Да, нужна запятая...



Эта в ответ на пост ArtemKAD:

Вообще-то

и это:

взаимосвязано т.к. в режимах Idle, Power save и Extended Standby МК находится исключительно в момент исполнения команды sleep...
Т.е. если там так, как написано в эррате, то из Idle, Power save и Extended Standby не выводит.

Шото запутали Вы меня окончательно.
Если верить DS то время выполнения команды sleep = 1 такту CLK CPU.

Ну если не настроен спящий режим, то таки 1 такт. Если настроен - до тех пор пока не появится прерывание или сброс выдергивающий МК из этой команды в обработчик, и дальше.

Если считать, что команда sleep выполняется не один такт, а всё время нахождения в режиме пониженного потребления, то получается что RTC не выведет в рабочий режим. Допустим.
Но как тогда понимать продолжение фразы:

Перевод: будет проигнорирован[запрос прерывания от RTC], пока устройство не разбужено из другого источника или
источник сработал снова(запрос прерывания от RTC).

То есть по Вашей логике получается:
1. RTC не выводит из sleep на свой вектор
2. Выход из sleep произойдёт от другого источника wake-up или повторного срабатывания RTC.
Пункты 1 и 2 противоречивы.

Получается, что sleep в любом режиме выполняется 1 такт:
1) Sleep не разрешён: аналогично nop
2) Sleep разрешён: один такт на команду sleep, затем остановка выполнения любых команд до wake-up или reset.

Но проверить надо ...

Вот - и я не понял о каком источнике , который или сработал или переключился , снова - они хотели сказать.


Может это sleep в режиме ADC noise , тогда хоть какая то логика есть. Пока он цифрует , его ничто оттуда не вышибет.

Речь по-моему о том, что прерывание от RTC, возникшее в момент исполнения команды sleep будет потеряно и мега проснётся либо при следующем прерывании от RTC, либо после какого-либо другого источника wake-up.



Речь о всех режимах пониженного потребления, отдельно про ADC noise ничего не говорилось.

Запросил support - пусть разбираются , что они имели ввиду когда ее писали.

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

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

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


ИСХОДНИК
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

Очень вольный, смысловой перевод основной части:

... Есть несколько причин, по которым прерывание может быть отложено:

1) прерывание происходит в то время, когда глобальный флаг разрешения прерываний в SREG не установлен ;

2) если обрабатывается другое прерывание, в то время как IRQ срабатывает (приходит сигнал прерывания) ;

После обработки текущего прерывания, XMEGA всегда возвращается в то место программы (кода), откуда произошло прерывание и всегда выполняет хотя бы одну команду, даже если в этот момент необходимо сразу выполнить обработку следующего прерывания. Это сделано во избежание полной блокировки работы (фоновой) программы, при слишком большом количестве прерываний.

С этих позиций нужно смотреть на ошибки, связанные с асинхронными RTC-прерываниями.

Когда асинхронное RTC-прерывание происходит в процессе обработки другого прерывания - его обработка будет отложена. Если команда, на которую выполняется возврат из текущего прерывания, является командой sleep - команда будет выполнена, и произойдет переход в слип-режим. Обработка же отложенного RTC-прерывания произойдет только после того, как процессор будет выведен из спящего режима другим прерыванием или следующим RTC-прерыванием. Тип установленного слип-режима не имеет значения.

Асинхронное-RTC прерывание выводит процессор из слип режима, если это происходит непосредственно в режиме сна, но не в процессе возврата из другого прерывания на команду sleep. Предполагается, что попадание RTC-прерывания в такую ситуацию является очень редким и не должно доставлять проблем...