Да нет там вашего кристалла. Я пробовал воспроизвести глюк на версии 700 - ничего не получается, отрабатывает нормально и с блоком 100 слов и 1000. Пробовал только на одном блоке. Кстати, посмотрите версию вашего кристалла при открытом проекте - Help->About->Version. У меня - AT90CAN128 170.

Странно, у меня студия 4.18 Build 692, а проц AT90CAN128 почему-то доступен.

Для AVRSIMULATOR - доступен. А для AVRSIMULATOR2 - нет.

У меня так:


А в доступных для АВРСИМУЛЯТОР 2 кристаллах не вижу ни одного с 128 кбайт флеша и чтобы у него RAMPZ0 был bit0 по адресу 0x3B.

А м.б. 1000 слов мало для сбоя? Вот у меня на 2-м блоке сбивается: 0x7E...0x1CB6 - это 0x1C38 = 7224 слов 14448 байт.

Предлагаю уважаемым модераторам вычленить из этой темы разговоры
о целостности прошивки в отдельную тему например "Как и когда стоит защищать программу"

Простите, а каков размер вашего бинарника?
А что такое "seed буфер"?
Автомобили - моя страсть. Сам на Subaru зажигаю... И вообще, иногда я очень сообразителен:-)

Это вы о внешнем еепром толкуете? То это несколько другая тема и решаться ИМХО она может иначе. Я предпочитаю при разработке устройства заранее об этом подумать, чтобы потом не заморачиваться с изысками, а сосредоточится лишь на сути...

И у меня складывается впечатление, что Вы не читаете того, что я уже написал:
Что есть сказать на сей счёт? А разговоры о MD5 - это уже вторично...

Не только внешний eeprom, я о тех случаях, когда программа пишется для уже имеющегося устройства, причём чужой разработки.

Не знаю, как вы считаете шансы, м.б. объясните, но у меня получается более 50%.
1. Запорчен код исполняемой команды, которая выполнилась не правильно -> ватчдог, зацикливание на подсчёте CRC.
2. Запорчен код исполняемой команды, которая не выполнилась -> зацикливание на подсчёте CRC.
3. Запорчены данные в таблице -> зацикливание на подсчёте CRC.

В моём случае это была защита от продолжительной работы с испорченными данными в таблице. Вот это самое страшное, что может случится. Цикл подсчёта CRC32, которая считается по байту за раз, для всего флеша составляет 1..2 секунды. Ну вот и получается, что через 2 секунды такая ситуация будет отловлена. А за 2 секунды ничего страшного в принципе случится не может.

Ну а самый главный аргумент, это то, что такая защита делается очень просто. Побитное вычисление CRC32 по слову за раз, с вызовами, таблицами и т.д. - у меня это 88 строчек на асме, и 6 байт ОЗУ. И кочует из проекта в проект. Не понимаю, о чём тут спорить?

Пусть даже вы считаете CRC по нескольку байт за раз посещения фоновой программы, а результат валидности флеша получаете лишь когда прошлись по нему целиком.
Пример с потолка: 32К флеша проверяем по 8 байт за проход: 32K/8 = 4K.
Грубо вероятность выполнения битой программы равна (100 - 100/4К) = 99,975%

Единственное что может иногда утешить:

Памяти у меня 128 КБ, забито под 100 КБ, но MD5 алгоритм тестирует всю память.
Seed buffer это двойное слово (64 бита), которое вгрубе пристыковывается к началу тестируемой памяти и т.о. влияет на выходной context. Алгоритм работает в фоне, непрерывно вычисляя MD5, а посев никто не знает, я его получаю по кану от FIA, которая имеет весь мой код и может самостоятельно посчитать MD5.

Жёстко там у Вас...

Не понял, вы считаете, что между проверками выполняется ВСЯ программа?

Да собственно, и не так важно однократное выполнение битой команды. На 80% это приведёт к срабатыванию ватчдога. Так же может сработать контроль стека, основных регистров и т.д. Но важно, чтобы работа при наличии ошибки не продолжалась.
Кстати, у меня всё в лог пишется. Так я ещё ни одного запуска процессора по срабатыванию ватчдога там не видел, тем более ошибки CRC. Но это не значит, что ватчдог не нужен.

У меня в той программе пришлось несколько таблиц во второй половине FLASH отдать пользователю, соответственно CRC32 там не считается. CRC32 я считаю по самодельному производящему многочлену, чтобы зная многочлен не изменили область памяти так, что общая CRC32 останется такой же.


Странно, а что почитать из кана никто не может? Пусть там даже и зашифровано всё. Поставить фильтр не некоторые ID, и подменять их...

Те ещё зверюги..сколько крови у меня попили. К примеру, ещё потребовали цифровую фильтрацию Баттерворта устроить для аналогового выхода, пришлось поставить 3 биквада и использовать 64-битные коэффициенты.

Иногда вся, иногда (чаще) нет поэтому я и не настаиваю на сотых долях процента, а говорю о величине порядка процента.
Это оценить сложно, всё от логики программы сильно зависит и от размера стека...

А толку? Ну прочитал кто-то посев, дальше-то что делать? У меня MD5 для 128 КБ считается за 0.3 сек в фоне, и хотя флеш-память неизменна, но выдавать запомненный digest нет смысла, т.к. посев его изменяет. Как и с помощью чего изменить память так, чтобы MD5 был одинаковым? А ещё надо полезную работу делать, у меня основной цикл 300 мкс.

Попробую 2-3 блока. Сначала данных было маловато. Я уж подумал - 1000 слов - куда уж больше