Глюк симулятора в AVR Studio v4.16 build 628, А вот в v3.56 всё было нормально Опции

[galjoen]

Вот пришлось вернуться к своему старому проекту на AVR (на асме написанному). Когда его ваял - пользовался AVR Studio v3.56. А сейчас использовал v4.16. Слегка изменил перетранслировал - всё нормально.
Там у меня кое какие вычисления делаются. Такая же программа и для компа есть. Но куда то я задевал её. Но на AVR то тоже самое считается. Ну и решил в симуляторе запустить. Запускаю - через некоторое время вылетает. Думал я что то попортил. Отлаживал и так и сяк - всё равно вылетает. Такое ощущение, что WD срабатывает. Сброс его поставил - всё равно вылетает. Кучу времени на это убил...
Потом от безъисходности решил AVR Studio v3.56 попробовать. Запускаю в симуляторе - всё нормально считается! Сравниваю hex-файлы той и другой студией сделанные - одинаковые. Т.е. явно в симуляторе ошибка...
Как у более новых студий не знаю. Давно с AVR дела не имел...

[ut1wpr]

Вот пришлось вернуться к своему старому проекту на AVR (на асме написанному). Когда его ваял - пользовался AVR Studio v3.56. А сейчас использовал v4.16. Слегка изменил перетранслировал - всё нормально.
Там у меня кое какие вычисления делаются. Такая же программа и для компа есть. Но куда то я задевал её. Но на AVR то тоже самое считается. Ну и решил в симуляторе запустить. Запускаю - через некоторое время вылетает. Думал я что то попортил. Отлаживал и так и сяк - всё равно вылетает. Такое ощущение, что WD срабатывает. Сброс его поставил - всё равно вылетает. Кучу времени на это убил...
Потом от безъисходности решил AVR Studio v3.56 попробовать. Запускаю в симуляторе - всё нормально считается! Сравниваю hex-файлы той и другой студией сделанные - одинаковые. Т.е. явно в симуляторе ошибка...
Как у более новых студий не знаю. Давно с AVR дела не имел...

Интересный и захватывающий рассказ. Однако, либо я пропустил, либо... Ни одного знака вопроса в тексте!

[galjoen]

Интересный и захватывающий рассказ. Однако, либо я пропустил, либо... Ни одного знака вопроса в тексте!

Новые темы создаются не только с вопросами. Но и с новостями и т.д. Прочитайте правила...

[alag57]

Новые темы создаются не только с вопросами. Но и с новостями и т.д. Прочитайте правила...

Ну так это действительно просто рассказ.

через некоторое время вылетает

Кто вылетает? Студия? Отладчик виснет? Винда синий экран кажет?
Как-то бы поподробней
У меня при живой программе все работает нормально. Может код для опробования выложить?
Интерес в том, чтобы разобраться, в чем проблема. Может быть это все-таки не новость?

[galjoen]

Кто вылетает? Студия? Отладчик виснет? Винда синий экран кажет?
Как-то бы поподробней

Вылетает на адрес сброса. Если там установлен 0, то с 0 начинает команды выбирать. Если установить 0xF000, то пишет, что оттуда неверный опкод прочитан (это приложение, у меня загрузчик в другом проекте)

У меня при живой программе все работает нормально. Может код для опробования выложить?
Интерес в том, чтобы разобраться, в чем проблема. Может быть это все-таки не новость?

Сейчас ещё поэкспериментировал. Оказывается вылетает на подсчёте CRC16 FLASH.

Код

.DEF RBN0=R12
.DEF RBN1=R13
FlAC:; готовимся к подсчёту CRC-16 FLASH Приложения
    eor    RBN0,RBN0; обнуление CRC
    eor    RBN1,RBN1; аккумулятора
    ldi    ZL,low(TbFlAd<<1); Z - ук-ль на таблицу блоков
    ldi    ZH,high(TbFlAd<<1); с подсчётом CRC во FLASH
    movw    R1:R0,ZH:ZL; сохраним адрес в R0, R1
FlAC1:    movw    ZH:ZL,R1:R0; ук-ль на таблицу адресов
    lpm    YL,Z+    ; адрес начала
    lpm    YH,Z+    ; очередного блока
    add    YL,YL    ; перейдём от
    rol    YH    ; слов к байтам
; при увеличении кода сверх FFFF так работать не будет
    brcs    FlAC3    ; C=b15=1 -> посчитано, на сравнение
    lpm    XL,Z+    ; адрес конца
    lpm    XH,Z+    ; очередного блока
    add    XL,XL    ; перейдём от
    rol    XH    ; слов к байтам
    movw    R1:R0,ZH:ZL; сохраним адрес таблицы в R0, R1
    sub    XL,YL    ; X = конец - начало (в байтах)
    sbc    XH,YH    ; = кол-во байт в блоке (сч-к)
FlAC2:; цикл вычисления CRC байта из FLASH
    wdr        ; сбросим Watchdog (попытка справится с отладчиком)
    movw    ZH:ZL,YH:YL; адрес во FLASH (байтовый)
    adiw    YH:YL,1    ; inc адреса счётных байт
    lpm    ZL,Z    ; очередной байт из FLASH (токо до FFFF!)
    eor    ZL,RBN1    ; проксорим данные с.б. старого CRC
    ldi    ZH,Hi1021; там с.б. таблицы 2110
    elpm    RBN1,Z    ; это с.б. т.к. таблица переставлена
    eor    RBN1,RBN0; получили с.б. нового CRC
    ldi    ZH,Lo1021; там м.б. таблицы 2110
    elpm    RBN0,Z    ; м.б. CRC просто из таблицы
; вычислено CRC очередного байта
    sbiw    XH:XL,1    ; уменьшим счётчик
    brne    FlAC2    ; циклимся (подсчёт CRC-16 блока)
    rjmp    FlAC1    ; циклимся (переход к след. блоку)
FlAC3:; CRC-16 подсчитано - сравним с тем, что д.б.
.....
TbFlAd:; таблица адресов подсчёта CRC у Flash
.dw CRC_B1, CRC_E1; начало (включительно) и конец (исключительно)
.dw CRC_B2, CRC_E2
.dw CRC_B3, CRC_E3
.dw CRC_B4, CRC_E4
.dw CRC_B5, CRC_E5
.dw 0xFFFF; признак конца этой таблицы

RAMPZ0=1, поэтому lpm обращается к 1-й половине FLASH, а elpm ко 2-й.
Во второй половине по адресу Hi1021 лежит выровненная (мл. байт адреса =0) таблица ст. байтов CRC 1021. Lo1021 - соответственно младшие байты. Но это, скорее всего, не сыграет.
Всё остальное в 1-й половине FLASH.
Когда подсчитывается небольшой блок, то всё нормально. Но при большом отладчик вылетает на адрес запуска. Кстати, а не при подсчёте ли того блока, в котором находится эта самая программа? Надо будет проверить.
Прерывания запрещены, введение сброса WD в цикл не повлияло...
Ах да, процессор AT90CAN128.

Последними билдами AVR Studio не пользовался т.к. вообще давно AVR не занимался. Но судя по тому, что глюк с невозможностью программирования загрузчика из hex-файла с помощью AVRISPMK2 кочует из версии в версию, думаю, что и этот глюк присутствует в поздних версиях...

[alag57]

Приведи еще определения CRC_B1, CRC_E1, CRC_B2, CRC_E2, CRC_B3, CRC_E3, CRC_B4, CRC_E4, CRC_B5, CRC_E5.
И пару-тройку строк начиная с FlAC3. И адрес FlAC.

А пока замечу про оригинальность подсчета CRC с использованием полинома.
Я делал подсчет CRC области апликейшена из секции загрузчика, там все нормально считается и отлаживается.

глюк с невозможностью программирования загрузчика из hex-файла с помощью AVRISPMK2 кочует из версии в версию

Не понял. Поясни, что значит невозможность программирования загрузчика.

Сообщение отредактировал alag57 - May 20 2010, 06:05

[galjoen]

Приведи еще определения CRC_B1, CRC_E1, CRC_B2, CRC_E2, CRC_B3, CRC_E3, CRC_B4, CRC_E4, CRC_B5, CRC_E5.
И пару-тройку строк начиная с FlAC3. И адрес FlAC.

Вот таблица с CRC_Bx и CRC_Ex. Это обычные метки, стоящие в начале и конце блока, в котором считается CRC

Код

                 TbFlAd:; таблица адресов подсчёта CRC у Flash
001cab 0000
001cac 004a       .dw CRC_B1, CRC_E1; начало (включительно) и конец (исключительно)
001cad 007e
001cae 1cb6       .dw CRC_B2, CRC_E2
001caf 1cb9
001cb0 2859       .dw CRC_B3, CRC_E3
001cb1 2880
001cb2 5e53       .dw CRC_B4, CRC_E4
001cb3 5e80
001cb4 64b2       .dw CRC_B5, CRC_E5
001cb5 ffff       .dw 0xFFFF; признак конца этой таблицы

Вот таблица правильной CRC и пример установки меток CRC_Xx:

Код

CRC_E4:; конец 4-го блока во FLASH, где надо считать CRC
TbCRC16: .db 0x2C, 0xA8; CRC-16 Flash (для контроля), тут CRC не считаем
CRC_B5:; начало 5-го блока во FLASH, где надо считать CRC

Вот адрес FLAC и несколько строк после FLAC3:

Код

                 FlAC:; готовимся к подсчёту CRC-16 FLASH Приложения
001a45 24cc          eor    RBN0,RBN0; обнуление CRC
..........
                 FlAC3:; CRC-16 подсчитано - сравним с тем, что д.б.
001a70 e7e0          ldi    ZL,low(TbCRC16<<1); Z = адрес
001a71 e3f9          ldi    ZH,high(TbCRC16<<1); правильного CRC-16
001a72 91a5          lpm    XL,Z+    ; м.б. того, что д.б.
001a73 91b4          lpm    XH,Z    ; с.б. того, что д.б.
001a74 25ac          eor    XL,RBN0    ; порксорим тем,
001a75 25bd          eor    XH,RBN1    ; что получилось
001a76 2bab          or    XL,XH    ; =0 -> совпало
001a77 f479          brne    ChBd16    ; Z=0 - CRC не совпало

А пока замечу про оригинальность подсчета CRC с использованием полинома.
Я делал подсчет CRC области апликейшена из секции загрузчика, там все нормально считается и отлаживается.

И что же там такого оригинального? На мой взгляд совершенно тривиальный подсчёт CRC16.
Приложение считает свою CRC. А дырки в нём возникают потому, что стоят .org для выравнивания адреса или, как в примере, само значение CRC для контроля.
Маленькие куски действительно считаются и отлаживаются нормально. А большие - нет. Причём независимо от попадания адреса на сам считающий CRC код.

Не понял. Поясни, что значит невозможность программирования загрузчика.

http://electronix.ru/forum/index.php?showt...&hl=galjoen

ЗЫ А вообще, здесь принято обращаться на вы.

[demiurg_spb]

И что же там такого оригинального? На мой взгляд совершенно тривиальный подсчёт CRC16.
Приложение считает свою CRC.

Это ИМХО идеологически неправильно. Это обязанность бута.

[galjoen]

И заодно еще один вопрос - адрес таблицы CRC. Хочу наиболее точно воспроизвести ситуацию.

Код

          .SET BgLd=LARGEBOOTSTART-0x1000; начало таблицы CRC16 1021 (2110)
          .SET Lo1021=high(BgLd<<1); ук-ль на 256 младших байт
          .SET Hi1021=high((BgLd<<1)+0x100); ук-ль на 256 старших байт
.....
          .org BgLd
          .db 0x00, 0x21, 0x42, 0x63, 0x84, 0xA5, 0xC6, 0xE7; т.е. это Lo1021
00e000 2100
00e001 6342
00e002 a584
00e003 e7c6
....
          .db 0x00, 0x10, 0x20, 0x30, 0x40, 0x50, 0x60, 0x70; т.е. это Hi1021
00e080 1000
00e081 3020
00e082 5040
00e083 7060

Это ИМХО идеологически неправильно. Это обязанность бута.

Бут тоже считает CRC приложения. Но это приложение работает не выключаясь месяцами (т.е. в бут не заходит), хотя 80% времени спит, просыпаясь по часам раз в секунду на пару милисекунд. Проверяет не нужно ли поработать, и в 99.9% случаев снова засыпает. Но если решит, что нужно поработать, то перед работой посчитает свою CRC, а также CRC ОЗУ.
Там есть ещё множество подобных фич, но они к теме не относятся...
И вообще, предлагаю не отклонятся от обсуждения глюка в отладчике.

[demiurg_spb]

Бут тоже считает CRC приложения. Но это приложение работает не выключаясь месяцами (т.е. в бут не заходит), хотя 80% времени спит, просыпаясь по часам раз в секунду на пару милисекунд. Проверяет не нужно ли поработать, и в 99.9% случаев снова засыпает. Но если решит, что нужно поработать, то перед работой посчитает свою CRC, а также CRC ОЗУ.
Там есть ещё множество подобных фич, но они к теме не относятся...

Ок. Последнее. А это действительно имеет смысл? Для атомной станции девайс?

[galjoen]

В АВРСИМУЛЯТОРЕ - регулярные сбросы!
В АВРСИМУЛЯТОРЕ 2 - все пучком.
Вы чем симулите? Может тот же случай?

Честно сказать - не знаю. А где выбирается симулятор? М.б. у меня и нет АВРСИМУЛЯТОРА 2? Версия AVR Studio то старая, а не обновлял т.к. давно АВРом не занимался. Да ещё боюсь, что в новых версиях новые глюки...
Вон в ассемблере Version 1 - если в .dw неописанную метку поставить, он не ругнётся, а просто 0 туда подставит.
А какой глюк в Version 2 я уже не помню. Какой то сложный, что то с арифметическими вычислениями, с деленим на 0 что ли? Но главное, что у них глюки разные. Т.е. если обоими оттранслировать, и там и там чисто, то и в действительности всё нормально.

А это действительно имеет смысл? Для атомной станции девайс?

А руки с мылом перед едой имеет смысл мыть?
Девайс не для атомной, а для дизельной станции.

[aleksey_g]

Честно сказать - не знаю. А где выбирается симулятор? М.б. у меня и нет АВРСИМУЛЯТОРА 2?

В верхнем меню студии:
Debug/Select Platform and Device... - в левом окошке выбираем, каким симулятором будем пользоваться.

[galjoen]

На запись и в некоторых устройствах на чтение. Но как, и, главное, зачем запрещать выполнение команды JMP/RJMP на область загрузчика?

Эти запреты с целью защиты от копирования сделаны. Там, даже прерывания разрешаются только если таблица прерываний в загрузчике. Т.е. это защита от восстановления кода команды по произведённым ею изменениям.
А я о том, что программа должна с любым загрузчиком работать. И при отсутствии загрузчика вообще. Переносимость. Да и запустить программирование FLASH, при работе с несоответствующим загрузчиком есть вероятность. В т.ч. поэтому вызовов быть не должно.
А считать собственное CRC приложение просто обязано - не только контроль FLASH, но без этого защита от копирования крайне малоэффективной становится...

В верхнем меню студии:
Debug/Select Platform and Device... - в левом окошке выбираем, каким симулятором будем пользоваться.

Спасибо, нашёл.
Там у меня AT90CAN128 в списке нет. Сейчас посмотрю у кого, из тех, что есть, 128 FLASH и RAMPZ0 на том же месте. Нет, сначала новую версию скачаю. М.б. там есть?

[demiurg_spb]

А считать собственное CRC приложение просто обязано - не только контроль FLASH, но без этого защита от копирования крайне малоэффективной становится...

Типа это повышает защиту... Ну-ну...

Переносимость.

Точнее независимость от загрузчика - вот единственный соящий аргумент.

[galjoen]

Типа это повышает защиту... Ну-ну...

Да, повышает, и ирония тут не уместна. Если по 1-му байту за раз потихоньку CRC считать. И запускать подсчёт по нечастому событию, только не по таймеру. И по несовпадению флаг выставлять (через указатель), а реагировать на него в других местах...
При размере прошивки в несколько десятков килобайт такую защиту найти нереально. И, соответственно, в такой прошивке изменить что-либо нереально.

Ах да. Ещё нужно какой-нибудь малоизвестный производящий многочлен использовать. Можно даже самодельный. Иначе изменят так, что CRC совпадёт...

[demiurg_spb]

При размере прошивки в несколько десятков килобайт такую защиту найти нереально.
И, соответственно, в такой прошивке изменить что-либо нереально.

Просто тот кто для начала сломает аппаратную защиту (Lock-битную) наверняка с любой программной справится на раз.
И я всё в голову не возьму для чего защищать от изменения?
От копирования понятно, от чтения на предмет реверс-инженеринга тоже.

Ах да. Ещё нужно какой-нибудь малоизвестный производящий многочлен использовать. Можно даже самодельный. Иначе изменят так, что CRC совпадёт...

Мёртвому припарки и паранойя ИМХО.

galjoen, CRC на десятке килобайт может споткнуться, может сразу MD5 считать? Сильная вещь, если кто понимает,

CRC32 вполне хватает.

использовал её всего один раз для страшной организации по названию FIA.

Для Формулы-1? :-)

[=GM=]

CRC32 вполне хватает

Не скажите, уже и в MD5 нашли дырки, так что у меня еще и seed буфер стоит и динамически меняется этой самой федерацией автомотоспорта на ходу.

Для Формулы-1? :-)

Ну вообще-то да, но как вы догадались?

[demiurg_spb]

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

Не скажите, уже и в MD5 нашли дырки,

Простите, а каков размер вашего бинарника?

так что у меня еще и seed буфер стоит и динамически меняется этой самой федерацией автомотоспорта на ходу.

А что такое "seed буфер"?

Ну вообще-то да, но как вы догадались?

Автомобили - моя страсть. Сам на Subaru зажигаю... И вообще, иногда я очень сообразителен:-)

Раз уж зашла речь по автомобили, то там как раз это нужно. Допустим кто-то написал прошивку для ЭБУ, откатал на машине, и не хочет чтобы другие таблицы его настроек меняли (тюнинговали). А прошивку эту зашифровать в принципе невозможно - ну нет в загрузчике у стандартного ЭБУ никакого шифрования. И таблицы скрыть/зашифровать тоже невозможно, т.к. прошивка на 70% из них состоит. Да на расшифровывание и времени нет. Вот тут как раз проверка приложением собственной целостности и нужна.

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

И у меня складывается впечатление, что Вы не читаете того, что я уже написал:

На мой взгляд - никакого практического смысла нет. И пусть даже оно работает месяцами без перезагрузки - шансы успеть отловить такую бяку на лету очень малы (по моим оценкам сильно меньше 1%).

Что есть сказать на сей счёт? А разговоры о MD5 - это уже вторично...

[galjoen]

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

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

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

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

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

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

[demiurg_spb]

Не знаю, как вы считаете шансы, м.б. объясните, но у меня получается более 50%.

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

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

А за 2 секунды ничего страшного в принципе случится не может.

[galjoen]

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

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

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

Памяти у меня 128 КБ, забито под 100 КБ, но MD5 алгоритм тестирует всю память.

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

посев никто не знает, я его получаю по кану

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