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.

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

 

[vitalinea]

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

[zombi]

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

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

[aaarrr]

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

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

[Guest_@Ark_*]

Питание 3.3v на мегу подаётся через диод шоттки (BAT54C) падение порядка 0.3v...
З.Ы. Если закоротить диод шоттки то питание тоже нормальное 3.3V.

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

[V_G]

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

[zombi]

Тогда вопрос, куда подключен второй диод из состава BAT54C

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

нет ли в схеме иных источников напряжения более 3.3V.

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

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

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

[Guest_@Ark_*]

Как же с этим бороться?

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

[ArtemKAD]

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

[zombi]

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

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

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

[Guest_@Ark_*]

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

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

[ArtemKAD]

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

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

[zombi]

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

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

[Guest_@Ark_*]

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


Сообщение отредактировал @Ark - Oct 10 2011, 20:06

[ILYAUL]

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

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

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

[zombi]

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

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

[zombi]

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

[Guest_@Ark_*]

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

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

[zombi]

Просыпаться - непосредственно по сигналу появления внешнего питания.

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

[Guest_@Ark_*]

А где такой сигнал взять?

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

[zombi]

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

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

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

34. Pending asynchronous RTC-interrupts will not wake up device
Asynchronous Interrupts from the Real-Time-Counter that is pending when the sleep
instruction is executed, will be ignored until the device is woken from another source or the
source triggers again.
Problem fix/Workaround
None.

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

[ArtemKAD]

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

[Guest_@Ark_*]

....

Сообщение отредактировал @Ark - Oct 12 2011, 14:10

[zombi]

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

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

[_Артём_]

А хочется понять о чём речь?

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

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

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

[ILYAUL]

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

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

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

[zombi]

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

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

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

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

[_Артём_]

Может после Idle нужна запятая а не точка?

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

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

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

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

[ArtemKAD]

Вообще-то

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

и это:

если произойдёт прерывание RTC в момент исполнения команды sleep

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

[zombi]

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

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

[ArtemKAD]

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

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

[_Артём_]

Вообще-то

и это:

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

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

, will be ignored until the device is woken from another source or the
source triggers again.

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

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

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

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

[ILYAUL]

или
источник сработал снова(запрос прерывания от 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.

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

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

[ILYAUL]

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

[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

[Guest_@Ark_*]

ИСХОДНИК

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

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

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

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

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

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

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

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


Сообщение отредактировал @Ark - Oct 17 2011, 17:23