Кто пользовал AES булоадер от Атымела. Мега 128. Обновляемый код стал превышать 6 100 байт. В результате обновление кода происходит загрузчиком нормально, но встроенная проверка крк выдает постоянно ошибку и перегружает его(как в принципе и задумано при ошибке). Пробовал разные прошивки, много раз и 4 платы. Везде одно и то же. Прошлые прошивки чуть меньше этой цифры идут без проблем.

Напиши свой бутлодырь и не парься. Работы-то дня на 2. Я всегда только свои пишу, потому что гораздо приятней разбираться в собственных глюках, чем в чужих.

Довольно мрачная штука - ну очень криво писанная. Обработка ошибок вооще неработоспособна. Разбирался в свое время, когда делал совместимый по спецификации порт на ARM. Думал просто портануть . Через полчаса на все, кроме собственно AES плюнул и написал с чистого листа. AES писанный в лоб, тоже потом рихтовал.

нашел отличие в 14 байт длинной начиная с 0x1700. Что за х-ня с бутлодером?

Я жъ тебе и говорю: кончай ерундой заниматься мучаясь с чужими глюками. Напиши свою бутлодырь. Быстрей получиться. А так ты тут ещё неделями вопить: помогите

Для начала разберитесь, кто виноват - загрузка или подсчет crc. Считайте программатором кристалл после прошивки закгрузчиком, прошейте ту же программу программатором, тоже считайте, сравните.


Доктор, ну и сколько ты еще будешь ерундой заниматься, сколько ТЫ будешь мучаться с чужими глюками? Ты супернадежный компилятор обещал еще 3 года назад. Где он?

Уже написал выше, что нашел в программе отличие от записанной программатором в 14 байт. Шью программатором- все работает. В конце области апликайшн находятся 2 байта крк. именно с ними и не совпадает посчитанная крк. Т.е. бутлодырь шьет поврежденный файл. В одном и том же месте. за этими 14 идут еще байты- но там все ок.

14 байт - меньше размера страницы. Может копать в эту сторону? В ReadAndProcessFrame() в switch() после первого case нет break. Его там и не должно быть. Вы случайно его туда не дописали?
Поскольку дальше все прописывается тоже правильно - декодирование работает, ChainedBlock принимает нужные значения, и надо смотреть именно обработку раскодированных пакетов.

Я ничего не менял кроме скорости USART, и условия входа в загрузчик. Долгое время писал программу и все было нормально. Но теперь размер кода стал немного больше- и вот.... Предыдущие 5 килобайт были записаны же нормально

Порыл гугль по вопросу- народ также возмущен. Есть косяки где-то в коде загрузчика или генератора шифрованного кода. Увеличил объем прошивки- пока работает. Процесс случаен. Надо копать.

У меня такое тоже было на 128 меге. При размере кода примерно в районе 0x2219 была ошибка контрольной суммы. Когда размер кода увеличился, всё стало нормально. А потом пошла партия процов в которой бутлодырь на частоте 14 Мгц не работал, пришлось переходить на 7

Мистика.
Партия процов небось с буквой L, которые выше 8-ми mhz не работают?

работоспособность бутлоадера от кварца никак не зависит. Времянок частотнозависимых у SPM нет. Запись selftimed. см даташит.

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

Не может зависеть, а если кажется - креститься надо.
Операции page erase/page write асинхронные, длятся ровно столько времени сколько требуется.
Цитаты из даташита:



btw, я не понимаю как можно вот так вот просто взять и зарезать чип в два раза по производительности, из-за того что на какой-то партии что-то не заработало. При этом даже не попытаться разобраться в чем же собственно обстоит дело. Как можно жить с бутлоадером в котором есть ошибка, и даже не попытаться ее исправить?!
LMD.

Если резерв по производительности есть почему же не зарезать, жрать меньше будет заодно.

Был у меня такой вопрос