Mega48PA vs PB. Задачка на разминку мозгов

[Someone]

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

Погугли словосочетание "тиристорный эффект". И наиболее частые причины возникновения.

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

А ведь всего-то и надо было уменьшить ёмкость конденсаторов на VCC. Микрофарад 47...100 оставить, не более. И фьюзы времени запуска установить на "65 мс".

Если используется IIC для подключения, например 24схх, причем не программный, а встроенный в контроллер, то низкий уровень на SCL переводит контроллер в вечное ожидание готовности шины,

Звучит бредово. Если модуль и2ц виснет при каждом низком уровне клока, что случается от 100 000 до 1 000 000 раз в секунду ("стандартные" частоты работы и2ц) это означает полную неработоспособность модуля. Что неизбежно нашло бы отражение в еррате, за более чем 10 лет существования и миллионы человеко-часов использования за эти годы. Да и форумы были бы полны жалоб на такую работу.

[alex_t2]

Звучит бредово.

Если глянуть спецификацию шины, то низкий уровень, удерживаемый ведомым на SCL, является флагом "не готов", ведущий должен ждать. Это штатно.
Допускаю, что у меня в коде есть неточность реализации IIC на встроенном автомате (надо будет глянуть повнимательнее), но факт остается фактом - если ножку SCL микросхемы памяти замкнуть на землю, то модуль останавливается, вачдог при этом ждет отпускания SCL.
В принципе, может это и разумно. Хотя мне и не нравится.
Вся логика работы модуля выполнена по схеме "автомата состояний", т.е. в основном цикле проверяется код состояния, перезапускается вачдог, и управление передается обработчику состояния, который должен вернуть управление за время цикла вачдога.
Работу проверял, задавая в обработчике бесконечный цикл. Все отрабатывает, перезапуская программу. Но если замкнуть SCL, то ничего не происходит. Модуль перестает реагировать на клавиатуру и не перезапускается. Отпускаешь SCL, дальше поехало.
Вообще, судя по всему, чаше используется программная реализация IIC, там, естественно, проблем нет. Я, для ускорения работы (поиск ключа в памяти - домофон), чтобы распараллелить проверку кода и чтение памяти, сделал на встроенном автомате. Все 5500 ключей обрабатываются в итоге в районе секунды, почти неощутимо.

P.S. А, нет, косяк, конечно у меня, скорее всего Сейчас попробовал, заткнул SCL на стендовом модуле, ровно через 2 секунды ожидания (цикл вачдога) явно ушел в ресет, но там после ресета опять чтение установок из памяти, поэтому выглядит как стоп, хотя все живо. Надо будет поправить, чтобы уходило в индицируемую ошибку памяти, а не в ожидание. В принципе, не смертельно, т.к. аварийные цепи все равно работают, да и жалоб за 5 лет не было на зависание.

[pambaru]

Погугли словосочетание "тиристорный эффект".

Спасибо за совет! Но поздновато - уже погуглил 17 лет назад, когда этим вопросом занимался.

А ведь всего-то и надо было уменьшить ёмкость конденсаторов на VCC. Микрофарад 47...100 оставить, не более.

Было изначально микрофарад 20. В процессе экспериментов пробовались разные варианты. Но, имхо, если такой эффект случается, а с заменой кондеров он, допустим, уменьшается, то в любом случае, вероятность возникновения оного к нулю не сведется никогда.

И фьюзы времени запуска установить на "65 мс".

До фьюзов при таком эффекте дело даже не доходит. МК в висяке полном, ничего не стартует, на ресет не реагирует, греется, как печка.

[Yuri222]

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

Значит - где-то в другом месте по железу не учтенный косяк.
Нет ограничения вливаемого тока (откуда-то извне) в ноги микросхемы при подаче питания.

[Someone]

Если глянуть спецификацию шины, то низкий уровень, удерживаемый ведомым на SCL, является флагом "не готов", ведущий должен ждать. Это штатно

Именно. Т.е. мастер формирует запрос, дёргая клок при передаче каждого бита. А если, как было написано, при каждом низком уровне клока зависает...

вачдог при этом ждет отпускания SCL.

Хм... поработаю телепатом... Говоря "зависает" понимается зависает программа, а не аппаратный модуль, как можно подумать читая исходный пост? Типа нет связи по и2ц, прога виснет, срабатывает вачдог?

если ножку SCL микросхемы памяти замкнуть на землю, то модуль останавливается,

Ну дык. Ещё бы он как-то продолжал работу, ежели клок отсутствует. Мастер-то не может перетянуть "землю". Соответственно до слэйва запрос не доходит, и он в ответ никаких признаков жизни естественно не подаёт. А в проге видимо крутится цикл, ожидающий флага успешного завершения. И прога "виснет", пока вачдог не срабатывает. Вообще это плохой подход, ждать завершения операции, которая может не завершиться. И не только к и2ц, но и уарт и т.п. И вачдог не панацея ни капли. Допустим после подачи питания проц пытается связаться с памятью и крутит цикл ожидания. Не дожидается, вачдог срабатывает, проц сбрасывается, программа начинает выполняться сначала, т.е. пытается связаться с памятью... И снова вачдог, снова ожидание... Впрочем, и сам уже разобрался.

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

Одна из самых частых причин возникновения - медленное нарастание питания. Нарастать питание медленно будет если большие ёмкости на линии питания - они медленно заряжаются, напряжение на них растёт медленно и плавно. Впрочем, сейчас вспоминать дела 17 летней давности - бесполезно. Потому что "емкость по питанию 20 микрофарад" звучит не менее фантастически. Ну разве что это ёмкость "прям вот у контроллера". Да ещё по 20 мкф у каждой остальной микросхемы - т.е. надо смотреть СУММАРНУЮ ёмкость всей линии питания.

До фьюзов при таком эффекте дело даже не доходит. МК в висяке полном, ничего не стартует, на ресет не реагирует, греется, как печка.

Вообще-то "словли ресет" 65 мс это заводская установка, как и "внутренний РЦ генератор". И прошивать контроллер можно и без подачи основного питания (при внутрисхемном ИСП-программировании) - либо беря питание от программатора, либо вообще, используя паразитное питание.

[alex_t2]

И вачдог не панацея ни капли. Допустим после подачи питания проц пытается связаться с памятью и крутит цикл ожидания. Не дожидается, вачдог срабатывает, проц сбрасывается, программа начинает выполняться сначала, т.е. пытается связаться с памятью... И снова вачдог, снова ожидание... Впрочем, и сам уже разобрался.

Да, именно так.
Поскольку в случае с микросхемой памяти, удержание ею низкого уровня на SCL - ситуация в нормальном режиме невозможная, т.к. у 24схх серии порт SCL однонаправленный - только вход, за 8 лет выпуска это не проявлялось ни разу.
Только при тестировании готовых изделий, если микросхему по ошибке не той стороной в панельку вставляли.
Снаружи выглядело как ожидание готовности без срабатывания сторожа.
Более пристальный взгляд показал, что я не прав. Сторож исправно перезапускает, просто стартовая заставка на дисплей выводится посте чтения параметров из памяти, соответственно до неё не доходит, хотя таймерное прерывание динамической индикации уже запущено в этот момент, и десятичная точка светится, как обычно.
Циклов ожидания у меня по минимуму. Как раз и цель использования аппаратного IIC заключалась в ускорении работы. Получили байт, сразу ставим запрос на чтение следующего, пока аппаратная логика его считывает, программа продолжает работу с уже полученным. Заметно шустрее получилось.