Мы успешно используем микроконтроллеры ATmega48 / 88/168/328 на протяжении многих лет во многих наших продуктах. Теперь мы решили перейти от вариантов A и PA к новому варианту PB (потому что нам понадобятся дополнительные выводы, таймеры и UART в новых продуктах, потому что он стал дешевле, и, как кажется, старые варианты будут сняты с производства), поэтому мы отключили ATmega328A с ATmega328PB. Похоже, что после перебоев в питании очень часто выходят из строя . Таких проблем никогда не возникало со старыми вариантами.

Регулярные перебои в питании являются нормой для использования наших продуктов. Мы используем импульсный источник питания (такой как этот ), настроенный на 5 В, и имеем конденсаторы в диапазоне 220 мкФ на VCC ATmega, чтобы поддерживать работу SRAM для прерываний питания в диапазоне нескольких минут, для хранения внутренних состояний, которые не являются предназначением критический, но значительно улучшающий пользовательский опыт, будучи мгновенно доступным после перезапуска (эти состояния изменяются достаточно часто, чтобы сделать EEPROM неподходящим). Это всегда работало.

Тем не менее, с новым ATmega328PB, после прерывания питания, чип сбрасывается без условия сброса, найденного в MCUSR, и часы, кажется, теряют скорость.

• детектор затухания установлен на предохранитель. Мы перепробовали все доступные уровни, ошибка возникает на всех из них.
• мы используем внешние 20 МГц, также правильно настроенные для каждого предохранителя.
• Мы испробовали 3 разных чипа, чтобы не было ни одной пайки или другого аппаратного сбоя.

После того, как произошла ошибка, тактовая частота часто устанавливается в 2,5 раза медленнее, что указывает на то, что mcu синхронизируется внутренним генератором 8 МГц. Тем не менее, иногда замедление составляет около 6х. Это означает, что это не может быть программная ошибка, изменяющая делитель часов, так как я не могу установить предохранители из программного обеспечения, а делитель часов не может разделить часы на 2,5 или на 6.

Итак, моим первым подозреваемым был новый предохранитель Clock Failure Detection. Однако независимо от того, включен он или выключен, поведение остается неизменным.

Чтобы исключить особенности программного обеспечения, я написал простую тестовую программу с нуля, которая не делает ничего другого, кроме как переключает выход с частотой 100 Гц от прерывания по таймеру и указывает светодиодными индикаторами после каждого перезапуска, какие условия сброса были активированы (как считано из MCUSR). Остальная часть аппаратного обеспечения также была удалена, присутствуют только микроконтроллер и регулятор (и светодиодные индикаторы с последовательными резисторами).

Результаты

Примерно в 2/3 случаев ничего интересного не происходит. После прерывания питания mcu возобновляет работу, и загораются индикаторы сброса и сброса при включении питания.

(на изображении красный - это переключаемый контакт, а синий - VCC. На этом изображении четко виден бронзовый выход 2,7 В. Я провел те же тесты с другими настройками отключения, результаты точно такие же, поэтому я опущу эти картинки)

Примерно в 1/3 времени возникает вышеупомянутая ошибка, и когда питание снова возвращается, ни один из индикаторов сброса и сброса при включении питания не светится! Вывод другой, как будто тик тикал со странными часами. Это не хаотично, но тикает с той же частотой.

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

Во время этих тестов я использовал 16K CK / 14CK + 4,1 мс для задержки запуска (но задержка в 65 мс не помогает избежать проблем).

Вот увеличенное изображение, где вы можете ясно видеть, что VCC достигает стабильного состояния при 5 В менее чем за 2 мс:

На картинке выше mcu запускается правильно.

Интересно, что когда этого не происходит, напряжение питания даже раньше стабилизируется до 5 В (кажется, что многие части блока mcu не включаются, поэтому при запуске он потребляет меньше тока)

Ниже приведено изображение неудачного старта:

Обратите внимание, что программное обеспечение запускается через 85 мс после стабилизации напряжения питания, вместо 10,5 мс, требуемых в противном случае. Предохранители для задержки запуска остаются такими же, 16K CK / 14CK + 4,1 мс.

Интересно также отметить, что после отключения питания напряжение VCC стабилизируется на уровне 1,1–1,2 В (старый вариант ATmega328A снизился до уровня 0,6–0,7 В). Это держит это в течение нескольких минут. Если я буду ждать достаточно долго (порядка получаса или более), mcu всегда запускается правильно! Таким образом, кажется, что проблема в том, что есть 1,1 Вольт вокруг, что, согласно данным таблицы, не гарантируется, что будет достаточно для сброса при включении питания. Но этого должно быть достаточно для сброса!

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

Я что-то упустил очевидное, или ATmega328PB имеет серьезную ошибку в детекторе отключения?

РЕДАКТИРОВАТЬ:

Интересно, что вышеуказанные проблемы возникают только тогда, когда я прерываю подачу перед регулятором. Если я прерву его после регулятора (или использую лабораторный источник питания), проблем никогда не будет. Как будто форма повышения напряжения вызвала проблемы. Однако, как вы можете видеть из последнего изображения, повышение напряжения довольно хорошее и быстро стабилизируется.

РЕДАКТИРОВАТЬ 2

Я попробовал это с 16 МГц вместо 20 МГц, но такие же проблемы случаются.

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

Как вы сами сказали, порог сброса при включении питания 1,1 В не достигается, если питание только на короткое время отключено и подключено, поэтому POR не будет.

Выключатель детектора здесь тоже не может помочь. Вы используете AVR на частоте 20 МГц, и для этого требуется, чтобы напряжение питания было 4,5 В или выше, или вы нарушаете спецификации. И BOD не гарантирует, что он сработает при напряжении 4,5 В, обычно это меньше, чем, скажем, 4,3 В. Таким образом, даже до того, как сработает BOD, нет гарантии, в каком состоянии находится AVR, но BOD должен сработать, за исключением того, что он может не работает из-за ваших часов 20 МГц. Когда напряжение снова начинает расти, БПК отключается, прежде чем напряжение питания снова достигнет безопасного уровня 4,5 В. Если это было запущено правильно. Время задержки запуска должно быть установлено на достаточно высокое, чтобы напряжение изменилось, чтобы подняться с уровня деактивации BOD до 4,5 В, прежде чем будет выполнен внутренний сброс.

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