Доброго дня всем...
Камень mega32. Загрузка ПО через бутлоадер. Все нормально работает. Но... если создавать помехи быстрым включением и выключением изделия может слетать флэш. Это выглядет примерно так-- изделие либо полностью не рабочее , либо не работает подсветка или индикатор или любая другая часть функций. При этом если прочитать флэш через програматор, то часть оказывается не такой как исходный файл. Причем в разных случаях разная степень подпорченности.
Питание -- стабилизатор 5 В с обвязкой.
Сектор бутлоадера 512 слов. Бут закрыт от записи чтения. Программный сектор не закрыт.
Никто не сталкивался с подобным явлением?

Включите BOD. Это раз. Во вторых - было бы правильно проверить в бутлоадере CRC основной программы, а не запускать наобум.

Портится если в процессе программирования питание дергать или просто при работе?

В работе.


BOD ставил 2.7В и 4В -- никак не повлияло.
CRC загрузчик проверяет. Еще - если после загрузки через Bootloader прочитать программный сектор, то совпадает с исходником полностью.

Попробуйте залить основной код программатором. При этом вместо бутлоадера пусть будут 0xFF. Затем попробуйте пощелкать питание. По результатам будем думать дальше.

Тогда ищите источник помехи, который может вам флешь сбивать. Тут была ветка автором которой был некий Дон Амброзио, вот он поднимал подобный вопрос. И там даже следи множества буков, вроде , были какие то рецепты.

Дело в том , что я это уже делал. Действительно я не добился выхода из строя при прошивке через SPI. Но системы никакой не отслеживается. Флэш слетает не всегда. Может слететь , а может и нет. Изначально все изделия прошивались на параллельном программаторе. Примрно 20 % из них вышли из строя. После перешивки через bootloader они опять работали... Но могли через некоторое время слететь.

И что, если обычным программатором запрограммировть, при аналогичных экспериментах флэш не портится?
Вы на одном процессоре ставили опыты или перебрали несколько?

у меня такое тоже было, но питание нарастало медленно, убрал электролиты вроде работает, тьфу-тьфу

Понятно. Схему с номиналами в студию. И разводку.



Если BOD включен, то должно быть пофиг. Автору топика: проверьте еще раз, точно ли включен BOD у Вас.

Схема питается от импульсного источника питания?

там все же больше насчет магического кода который сам способен отдетектить свою правильность

Причина слетов здесь - отсутствие или неправильная работа супервизора.
Не верится, что BOD у автора включен.


Причина - кривая разводка, отстутствие блокировочных емкостей по питанию, кривой DC/DC, кривой супервизор питания. Других причин здесь нет.

Workaround - поставить delay несколько десятков/сотен ms перед выполнением команды SPM (это по крайней мере вдвое снизит вероятность появления проблемы. При сбое на отключении питания SPM просто не успеет выполниться).

1) Какая у вас частота процессора.
2) Какое напряжение.
3) Что подводится на ножки SPI (Програмирования)

Сделай задержку в 0.5 секунды при старте программы и лоадера.

На 4-х с камнями из разных серий...


Я не могу электролиты убрать помехи слишком большие будут...


Нет. Обычный 7805


4МГц
5В
PB5,6,7 -- транзисторы подсветки.
Загрузчик начинает работать на запись только когда связался с компом и получил верные данные для записи страницы... То есть , загрузчик посылает байт запроса, получает три байта в ответ. Если они совпали , то загрузчик посылает подтверждение компу. Дальше команда адрес и сразу 128 байт в буфер с проверкой CRC.

Вместо 7805 предлагаю для эксперимента нашу 1156ЕН1 или похожую буржуйку LM2925

Возможно и так(я еще раз проверю). Но непонятно как влияет уровень напряжения на записанную флэш? У меня в самой программе SPM не выполняется нигде, а в загрузчике очень много условий для входа в саму загрузку.
Записывается-то нормально, без сбоев.
Разводка действительно очень плотная. И опять вопрос-- каким образом это влияет на целостность флэш? Предположим что где-то жуткие помехи -- изделие просто не будет работать или будет сбоить сама программа. Но тут получается , что прога работает прекрасно пока флэш не побита. Глюки все давно исправлены, да и программа несложная без изысков особых...

конденсатор КМ-5 0,01 - 0,1 мкФ на ножки питания меги

Сотрите всю флеш - и бут и программу или чистый контроллер возьмите. Подергайте питание и считайте флеш. Если и в этом случае будут ошибки в флеше, значит бут не причем, просто кристаллы левые.

Когда уровень напряжения питания падает ниже критической отметки указанной в ДШ, не секрет что МК начинает глючить, первым искажается содержимое RAM. МК надо бы сбросить и держать сброшенным до того как это произойдет. В противном случае, процессор может выполнять блоки вашей программы в совершенно случайном порядке. С достаточно низкой вероятностью (но ее хватает чтобы испортить флеш) процессор выполняет опасную команду SPM с параметром Page Erase. После чего питание падает настолько что процессор отключается, либо наоборот возрастает до нормального уровня и процессор начинает выполнять все правильно с той точки где находится, но одной страницы уже нет.

Кстати, можете убедиться в том, что слетает всегда только одна случайная страница флеш. Для этого прочитайте содержимое флеш после того как программа начнет работать неправильно и сравните с бинарником программы.


Стоит еще добавить "железную" защиту от записи - перемычку, проверяемую непосредственно перед SPM. Я использую перемычку между MISO/MOSI, т.к. всегда есть разъем программирования. Правда без супервизора питания она все одно не поможет, но вероятность слета хоть как-то снизит.

Вот тут вы заблуждаетесь. Это как у Дон Амброзио "процессор завис" или "сбоит".

Память сама по себе не слетает. Не имеет такой привычки. Это значит, что при каких-то обстоятельствах процессор начинает выполнять некоректные действия и, портит ваш флэш.
Ваша задача разобраться почему и при каких обстоятельствах CPU занимается ерундой.

Причин может быть несколько.
Например - ошибка в программе.
Именно поэтому вам говорят про нарастание питания и BOD. То есть при низком питании, если выключен BOD и CPU при этом работает на высокой частоте (U=1.6 FCLK = 4) могут происходить такие финики.

Для проверки работоспособности вашего BOD подайте питание 2.5V и посмотрите порты.

Главное, вы должны понимать, что хомут где то у вас и вы можете и должны его найти.

BOD был отключен при параллельном программировании. Сейчас установил 4 В BODEN 0. В этом ли дело не уверен, но при испытаниях 10 изделий в рабочих условиях (быстрое включение и выключение питания) ни одно изделие не вышло из строя.
Спасибо всем.

Дело именно в этом. И за этим надо строго следить, чтобы не напрошивали фигни на производстве.

После 7805 - УБЕРИ!!! Лучше добавь перед стабилизатором. После стабилизатора только керамика обеспечивающая устойчивую работу 7805 (см. ее доку).

столкнулись с такой проблеммой на меге16, перепробовали все, не помогало, перешли на внешнюю еепром - не помогло стали смотреть код и нашли ошибку, исправили - и все стало нормально. на все эти поиски потратили недели две.

В особо параноидальных случаях - вплоть до того, что на старте программы проверять значение fuses и в случае чего стопорить работу с какой-то явной индикацией неработоспособности.

Это как? Что-то не припомню что фузы программно доступны....

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

А при чем здесь EEPROM?

а кто будет контролировать "автономный программатор"? ИМХО, это ещё одна деталь снижающая надёжность.
Всё же интересно, что же имел ввиду ReAl?

Поиск по форуму

В иаре для меги так

Спасибо. Не знал.

Именно так. Только не по форуму, а по родной документации от атмел :-)
Кажется, у всех, у кого есть SPM - при помощи LPM можно прочесть fuses.
У тини13 точно можно :-)

Всё правильно. Я привёл вырезку из стандартной документации от Атмел на ATtiny13 стр.100 ДШ doc2535.pdf. Автор Xorval для даной тиньки читал содержимое фусов таким образом: