обращаюсь к уважаемому сообществу со своей проблемой, голову уже сломал.

делаю девайс на atmega8, который в одном из режимов уходит в POWER_DOWN с пробуждением по INT1. обработчик прерывания - пустышка, только чтоб проснуться. как только девайс просыпается, он берет из RTC DS1337 дату и время и сохраняет это в EEPROM, после чего снова уходит в отключку.

для работы с и2ц использую библиотеку TWI от Peter Fleury <pfleury @ gmx.ch> http://jump.to/fleury .в общем, в нормальных режимах она не подводит, правда програмный и2ц почему-то не работает, но это к проблеме отношения не имеет. так вот, проблема в том, что после пробуждения МК начинает считывать время из часов и где-то там зависает, т.е. снова в спячку уже не уходит. я это точно вычислил, т.к. при заремаривании обращения к часам все отлично. причем в нормальном режиме (без спячки) работа с RTC осуществляется без проблем, проблема исключительно в момент обращения после пробуждения. отладку веду исключиельно по току потребления МК, т.к. выводить какую-то диагностику некуда и нечем - память на пределе и ноги заняты

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

надеюсь на вашу помощь

Резисторы подтягивающие SDA и SCL у вас внешние или внутренние? Выводы МК в момент входа/выхода в режим сна как-нибудь реконфигурируете?
Неплохо осциллографом посмотреть на линиях SCL и SDA, как идёт обмен и на каком этапе обмена происходит сбой.

резисторы внешние. при входе в сон состояние портов не изменяю, соответственно, каким оно было после последнего обмена по и2ц, тем и остается. осциллографом буду пользоваться лишь сегодня к вечеру, раньше не было возможности. но пока не представляю, чем это мне поможет главное-то: без сна все работает! в чем разница между обычным состоянием и состоянием после пробуждения?!

Из слипа выходил так:


Почему? Не помню. Пять лет назад было.

спасибо, вечером попробую. задержка 100 - это в каких единицах? если в миллисекундах - это для меня может быть полный крах, т.к. питание от литиевой батарейки, а потребление в активном режиме около 17 мА... боюсь, быстро разрядится...

DS проснуться не успевает как следует? Более режимы ничем не отличаются.

Сообщение отредактировал IgorKossak - Nov 29 2011, 07:53

DS и не спит - он и без сна ноноамперы потребляет... что-то с AVR TWI не то...

Для пробуждения МК уровень на INT1 откуда приходит? Как долго держится? Запрещаются ли прерывания по INT1 после пробуждения МК?

прерывания на INT1 в настоящее время поступают от проводка с общего провода, которым я касаюсь ножки сигнал держится недолго - всего один "тыц" прерывания от INT1 не запрещаются никогда, обработчик прерывания состоит из RETI.

P.S. да, пробовал из сна выходить не по INT1, а по WDT - выходит и все нормально работает, что заставляет меня думать о том, что периферия TWI все-таки как-то портится либо во сне, либо по выходу из сна и аппаратный сброс ее лечит. МК у меня старый, ему, наверное, года 3 - может, какая-то старая ревизия кристалла с errata ? в даташите последнем errata начинается с ревизии D - может у меня А или В? есть у кого-нибудь древняя errata для справки?

В DS на m8 Rev.2486M-AVR-12/03 Erratas тоже с D начинаются. Неужели у Вас более "древний" МК?

PS. На местном FTP лежит DS Rev.H - если уж очень хочется проверить.

ну, если 0536 в маркировке обозначает 2005 год 36 неделя - то у меня еще не очень древний... тогда, блин, какого ему надо?!

ПРОБЛЕМА РЕШЕНА, тему можно закрывать.
то ли из-за кривизны упомянутой мною библиотеки, то ли из-за неописанного бага самого TWI, но модуль и2ц после пробуждения оказывался в каком-то состоянии, препятствующем началу нормального обмена - а в либе, как и приведено в примерах из даташита, сплошные бесконечные циклы ожидания нужного состояния...
в общем, решил проблему тупым TWCR = 0; сразу после пробуждения - если кто будет использовать эту либу, имейте ввиду.

Ну так надо организовать им штатную рабочую ситуацию.
ЦПУ сбрасывать , а таймер переводить с батарейного питания на основное.
Начать со сброса цпу.

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