Имеется ввиду область страницы в которую производится запись, или вся область ниже бутблока?

По поводу перепрошивки... сперва заливаем новую прошивку во внешнюю еепром, затем надо сделать ребут контроллера, бутлоадер I2C перехватывает управление и шьет контроллер, при этом USB работать не будет и и на прерывание int0 ему будет плевать, после завершения прошивки контроллера, снова ребутим его и управление передается новой прошивке, которая восстанавливает соединение по USB, а для переключения на бутлоадер и обратно можно использовать какой то признак, например во внутреннем еепром выделить байт под это. Но это просто идея представленная мною на всеобщее обозрение. Ж

Это понятно, я иронизировал)

для решения проблемы с неверной прошивкой можно еще сделать бэкап текущей прошивки в ту же еепром, просто надо будет использовать еепром не на 8к, а на 16к и выбор загружаемой прошивки сделать тоже по кикому-нибудь признаку, тот же байт в еепром или джампер

А на хосте в это время революция, и драйвер CDC слетает так, что без нажатия на волшебную кнопку устройство больше не видится...

Имеется в виду, что при записи вся NRWW область блокируется на запись и чтение. То есть, какую бы страницу памяти приложения мы не писали, вся область RWW блокируется на чтение, и исполнять в ней код нельзя. После операций записи обязательно нужно выполнить разблокировку этой области посредством RWWSRE: Read-While-Write Section Read Enable.

Дополнительная особенность в том, что границы области boot и RWW/NRWW секций в общем случае не совпадают (похоже, границы совпадают при выборе максимального размера бут-блока).

Мдя...Об этом я читал в даташитах, но была надежда, что я непонял чуждый мне язык, оказывается понял...

Это - решение проблемы средствами, куда более серьезными, чем сама проблема. Если речь идет об устройстве, где это столько важно - начиная с меги32 все решается прозрачно - там размера бут-блока хватает вполне.



А я еще и практически проверил, когда после записи блока верификация у меня не считалась правильно CRC. Ибо, с той области читается не то, что там есть на самом деле (что - не выяснял).

Я кстати никак не пойму из доки на Mega48/88/168 как дела обстоят с собственно 48. RWW у нее по доке нет, т.е. получается что мы можем писать любую страницу, продолжая дальше выполнять код ?
Хотя в другом месте пишется что MCU Halted.

2 osnwt

Олег, вопрос про АES. А его нельзя вынести из бут блока ? Мы же шьем страницами ? Почему тогда нельзя получит криптованую страницу, раскриптовать ее в память и потом шить. ? После раскриптовки движок дешифрования же уже нам не нужен ?

Так в том и дело, что нет RWW. Есть NRWW - она же и бут. То есть, в ней запись возможна исключительно с остановкой CPU на время операции записи. Области RWW (из которой можно читать во время записи - то есть, исполнять программу или читать вектор прерывания) как раз и не хватает. Так что в доке всё правильно - и малоприемлемо для нас.


Можно без проблем. А смысл? Как я уже писал, по моему мнению, boot блок должен быть способен после любого затирания application area обеспечить возможность ее зашивки. То есть, не должно быть никаких кусков кода в application area, на которые мы полагаемся при перешивке. Всякие методы записи того же самого блока, или просто незатрагивания куска application, где что-то находится, не годятся, так как рано или поздно ошибка случится, и этот кусок погибнет -> программатор потребуется. Если речь о серийном изделии - это неприемлемо. Если о штучном для внутреннего потребления - приемлемо, но проще тогда просто сделать бут, работающий по serial, и к нему UART-to-USB шнурок, один на все свои игрушки. И им пользоваться.

Был бы смысл, если бы можно было загрузчиком загрузить нечто в RAM, откуда и исполнять. Тогда да - можно было бы вынести код декриптора в RAM (сохранив ключи во FLASH). Но в контроллере гарвардской архитектуры это не сработает, в отличие от того же MSP430. И, кроме того, AES - это один килобайт, а кроме него - все равно еще 3. Даже в моем буте можно определить количество ключей в 0 и получить загрузчик без шифрования. Но все равно при сложном протоколе загрузки в 2 кило оно не влезет. А если не пугаться драйвера libusb и собственного загрузчика на PC - так такой бут уже есть, и он влезает в мегу8.

Да...За загрузчиком не получается - факт. Однако, для программатора это не слишком страшно, если контроллер в DIP корпусе))) Это ж программатор!!! Правда, есть необходимость иметь под рукой запасного игрока в виде Меги8) Выход не совсем удачный за то практичный.)))

Сдесь могу поспорить - не сработает ТОЛЬКО в AVR, потому как, во первых, память программ и память данных (SRAM) разной разрядности, и , во вторых, нет возможности подвесить внешнюю память программ, в следствии первой причины. От этого недостатка свободны контроллеры mcs51, у которых есть возможность расширять память программ путем навески внешней микросхемы ROM. Никто же не мешает вместо ROM подцепить RAM, и путем некоторой манипуляции с линиями управления исполнить код в этой самой RAM. Но это так, теоретически, хотя практически я так еще в универе делал, а подсмотрел все это на стенде с ADuCххх.



Кстати, хочу попробовать ввести CRC для приема данных от хоста - все таки не нравится мне, что целостность данных не контролируется. Проверить CRC можно и после приема, когда драйвер передаст управление прикладному ПО МК, но ведь он уже послал ACK! Я посмотрел, как формируется CRC для пакетов к хосту - довольно медленный классический алгоритм. А что, если проверять CRC входящих пакетов табличным методом? Это на порядок, ИМХО, быстрее бы проходило. 2 osnwt возможно ли это?

Скорее, перед оным...


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


С заключительным выводом (о причине незвоможности) не согласен, но в целом - да. Правда, разговор был об AVR, потому это неявно предполагалось. Просто в фон-неймановской архитектуре память программ и данных едина, а потому при реализации интерфейса к внешней RAM (что так или иначе есть во многих контроллерах) поддержка загружаемого туда кода решается сама собой.


У адуков есть есть одна интересная фича: в режиме отладки софта есть аппаратная подмена содержимого адреса памяти команд на команду остановки. В результате не приходится переписывать flash для пошаговой отладки, как в AVR и debugWire. Ну чего там стоило сделать то же самое - нет, проще сказать, что "не используйте кристаллы после отладки в серийной продукции" :-) Но это так, к слову...


Таблица довольно большая, видимо, потому это и не было сделано. Хотя я не помню уже, где именно, но я читал, что с времянками есть проблемы, и там достаточно мало тактов на своевременный ответ хосту. То ли на сайте, то ли в личной переписке с автором. Так что не уверен, что можно - уже бы сделали.

Да, что то было про CRC, по моему, даже на этом форуме. Буду пробовать, таблица не такая уж и большая, 256 килослов всего...Флэша еще море) . Кстати, не подскажете, как таблицу сгенерить?

Не подскажу, но автору драйвера вопрос задал :-) Будет ответ - поделюсь.

Неплохое руководство по CRC. Описана реализация как прямого так и табличного алгоритма wasm.ru/docs/5/crc.zip.