Atmel->Microchip Опции

[hw_engineer]

Всем доброго.

Сложилась неприятная ситуация с линейкой ATmega8A, ATmega32A и (предположительно) ATmega64L, все выпуска конца 16 года и новее.
Симптомы такие:
1. при питании 3.3В:
- заливка EEPROM с программатора идёт только при принудительной установке паузы после каждого байта минимум 10мс (9 - уже появляются ошибки верификации), причём при изменении одного байта и повторной заливке могут "посыпаться" несколько других, казалось бы даже и рядом не стоявших, а питание при этом стабильное,
- EEPROM крайне легко повреждается даже при чтении, если при этом активно дрыгать питанием,
- запись байта "изнутри" может вызвать повреждение его содержимого даже после ребута (это я вообще не понимаю как получается, можно с натяжкой списать на предыдущий пункт, но почему предпочитает ломаться именно последний записанный байт - загадка),
- особый смак: если (это случайно получилось) отключено питание AVCC, то активное дрыгание основным питанием приводило к повреждению EEPROM даже в случае свехсложной программы int main(void){while(1);} честно-честно,
2. при питании 5В работает как и раньше (по крайней мере с программатора шьётся на ура с первого же раза, насчёт повреждения пока не проверял).

Напоминаю на всяк случай: нижняя граница питания по спеку 2.7В, а частота при этом может быть 8МГц максимум, т.е. спек не нарушен. Тактируется проц от внутреннего RC 8МГц.
Обращение к EEPROM "изнутри" шло как в примере из спека, при обнаружении проблем были учтены дополнительные проверки битов и запреты прерываний (каюсь, не ставил cli-sei, работало годами), результат не стопроцентный, хотя вроде стало получше.

Это НЕ относится (почему-то) к чипам выпуска 14 года, например.

Вроде бы вырулил введением дополнительных пауз ПЕРЕД записью (типа медленно подошёл, огляделся, быстро спёр и слинял), аккуратным стартом проца и т.п., но осадок остался.

Что изменилось в чипах после поглощения атмела микрочипом? Или у меня уже попросту бред?

Сообщение отредактировал hw_engineer - May 12 2018, 02:16

[zombi]

- заливка EEPROM с программатора идёт только при принудительной установке паузы после каждого байта минимум 10мс

Какой программатор? Он позволяет произвольные паузы добавлять?
В DS на мс указано время необходимое для записи одного байта в EEPROM?

Без БОД (случайно на плате не оказался ферритик) - ЕЕПРОМ летела даже от косого взгляда, кажется :D

Какое отношение ферритик (или его отсутствие) имеет к BOD?
Вы уверены что правильно понимаете что такое Brown-out Detector?

[hw_engineer]

Какой программатор? Он позволяет произвольные паузы добавлять?
В DS на мс указано время необходимое для записи одного байта в EEPROM?


Какое отношение ферритик (или его отсутствие) имеет к BOD?
Вы уверены что правильно понимаете что такое Brown-out Detector?

Позволяет, да, я писал выше.
Разница именно в этом: раньше ни о каких паузах не задумывался даже, теперь приходится выставлять 10мс.
Если выставить 9мс, что больше спековских 8.5, то ошибки вероятны, но не часты (эти 6% наверное можно списать на неточности генераторов).

Ферритик к BOD, по-моему, имеет отношение такое, что BOD аналоговый и питается от AVCC. Или использует Vref, который получается от AVCC, извиняюсь, точно не помню.
А вот какое отношение он имеет к EEPROM - действительно загадка.



Видимо нужно предельно конкретизировать что я имею ввиду.

1. Зависимость параметров EEPROM от напряжения питания при одном и том же годе выпуска.
Новый проц (вторая половина 2016г и 2017г): питание 5В - всё ок, 3.3В - не очень.
Старый проц (конкретно 2014г): любое питание - всё ок.

2. Зависимость скорости EEPROM от года выпуска при условно-пониженном питании.
Питание 3.3В, старые процы шьются программатором без пауз, новые - только с паузами.

Сообщение отредактировал hw_engineer - May 13 2018, 05:42

[zombi]

Ферритик к BOD, по-моему, имеет отношение такое, что BOD аналоговый и питается от AVCC. Или использует Vref, который получается от AVCC, извиняюсь, точно не помню.
А вот какое отношение он имеет к EEPROM - действительно загадка.

Не важно от чего и как питается BOD.
Я просто хотел обратить Ваше внимание на то что, если после старта записи EEPROM сброс произойдёт ранее чем через 8.5 мс, то результат записи непредсказуем.
Вы писали:

- запись байта "изнутри" может вызвать повреждение его содержимого даже после ребута (это я вообще не понимаю как получается, можно с натяжкой списать на предыдущий пункт, но почему предпочитает ломаться именно последний записанный байт - загадка),

спековских

Это жаргон какой-то? просто интересно

Это НЕ относится (почему-то) к чипам выпуска 14 года, например.

А какое количество изделий с чипами выпуска 14 года работают? Если не секрет?

[hw_engineer]

Это жаргон какой-то? просто интересно

Извиняюсь. Имеется ввиду - "указанных в спецификации". "Спек" - жаргон, да.

Не важно от чего и как питается BOD.
Я просто хотел обратить Ваше внимание на то что, если после старта записи EEPROM сброс произойдёт ранее чем через 8.5 мс, то результат записи непредсказуем.

Упс... Ошибка. Ломается ПРЕДпоследний записанный байт, виноват.
Т.е. я пишу в ЕЕПРОМ двухбайтовый адрес, сначала старший байт, потом младший, ломается старший и всегда почему-то в 0xFF.

А какое количество изделий с чипами выпуска 14 года работают? Если не секрет?

Статистика пока обратная: все чипы, на которые есть подозрение - "новые".