Есть ли в новых «PB» вариантах ATmega ошибка в детекторе затухания?

9

Мы успешно используем микроконтроллеры 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 МГц, но такие же проблемы случаются.

ВСЗ
источник
Вы связались с Atmel или изучили их ошибки? В наши дни ошибки проектирования микросхем довольно распространены.
Эдгар Браун
Я просмотрел информацию об ошибках (ничего не нашел в этом направлении), и мы рассматриваем возможность связаться с Atmel, но не раньше, чем провести еще несколько тестов и немного осмотреться.
VSZ
3
По моему опыту не тратьте время, прежде чем связаться с производителем или использовать их форумы. Вы сделали более чем достаточно для отладки, чтобы представить очень веские аргументы. С гораздо меньшим, чем это, TI отправил мне свои внутренние (неопубликованные) опечатки для одного из их IC, которые документировали нашу проблему.
Эдгар Браун
Мои два цента стоят: я видел проблемы с другими процессорами, если мощность повышается слишком быстро. Некоторые производители указывают максимальное время нарастания, но чаще это не упоминается.
Oldfart

Ответы:

3

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

Как вы сами сказали, порог сброса при включении питания 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 В.

Просто я
источник
Я предположил, что БПК не использует сам процессор, но это выделенное оборудование. Может быть, они изменили его для варианта PB? Я был бы удивлен, если бы они больше не поддерживали BOD для 20 МГц. Наивысший уровень тела составляет 4,3 В, поэтому для 20 МГц потребуется внешнее БПК? Тем не менее, я сомневаюсь, что это одна причина. Я сделал тест с частотой 20 МГц, 2,7 В, установил VCC на 3 В, он работал нормально. Когда я уменьшил напряжение вручную до чуть ниже 2,7, выход прекратился, когда я увеличил его до 2,7, выход возобновился, всегда, он никогда не выходил из строя, ни разу. Кажется, только запуск от 1.1 В отключает BOD.
VSZ
Скорее всего, это выделенное оборудование, но во время пониженного напряжения до того, как сработает BOD, можете ли вы быть уверены, что правильные данные извлекаются из флэш-памяти для выполнения ЦП, и ЦП выполняет их правильно? Это может или просто записать случайные данные в зарезервированные регистры, которые делают неопределенные вещи. Спецификации изменились для варианта PB, и они не поддерживали BOD для 20 МГц ни на старом чипе. Вариант PB имеет как кривые BOD, так и POR, которые действительно различаются, и включаются позже при более низких напряжениях.
Justme
Пожалуйста, посмотрите на мою вторую фотографию. BOD, похоже, был задействован правильно и сбросил чип. Не удается инициализировать только при следующем запуске. Кроме того, я управлял этим чипом при 3 В, и он работал правильно, ни разу не подвел.
VSZ
На мой взгляд, чип не должен работать за пределами безопасной рабочей зоны, но давайте продолжим. BOD не будет сбрасывать детектор сбоя часов, поэтому только сброс при включении питания и внешний сброс будут отключаться от внутренних часов. Поэтому дважды проверьте настройки предохранителей CFD. Вы используете внешний кристалл или внешние часы? Предохранитель CFD, возможно, ранее был предохранителем Full Swing. А поскольку нет плавкого плавкого предохранителя, максимальная частота для кристалла составляет 16 МГц, а для 20 МГц требуется тактовый сигнал внешнего логического уровня. Так же может быть проблема с запуском кристаллов, так что поставьте область также на кристаллы.
Justme
Я использую кристалл. Хорошая идея, я посмотрю на это. Обратите внимание, что то же самое поведение, которое я изобразил с изображениями, происходило независимо от того, был ли включен или выключен CFD.
VSZ