Нужно объяснение, как прошивать HEX-файлы на ATmega32u4 по протоколу AVR109.

Я не эксперт по электронике, поэтому простите меня, если я неправильно использую термины в своем вопросе или если мой вопрос содержит неточности и / или неправильное толкование того, как работает доска Леонардо. Поправки конечно приветствуются.

Я пытаюсь написать очень простую программу для перепрошивки чипов, которая с помощью HEX-файла сможет прошивать ее на плате Leonardo через ее загрузчик. Я понимаю, что Arduino Leonardo использует ATmega32u4 и что загрузчик использует протокол AVR109 .

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

Мой код примерно выглядит так:

  1. Разберите HEX-файл (intel) на представление того, как память должна выглядеть на чипе (т. е. для каждой записи я извлекаю адрес памяти для записи и данные в записи).
  2. Для каждой пары байтов в этом представлении я выдаю инструкцию set memory address, за которой следует write low byte, а затем write high byte.
  3. Через каждые 256 байт, прошитых таким образом, я выдаю write pageинструкцию.

Мне трудно найти, что я делаю неправильно, потому что я не уверен ни в одном из этих шагов. Шаг № 1 создает данные, которые выглядят нормально (поскольку здесь и там можно увидеть знакомые строки):

введите описание изображения здесь

... однако, если я сравню свои данные с тем же HEX-файлом, прошитым AVRdude и снова загруженным из чипа, они сильно различаются .

Шаг №2 работает (загрузчик отвечает байтом 0xD на каждую команду, но я не знаю, правильно ли я поступаю, прошивая младший байт перед старшим .

Шаг № 3 также работает нормально, но я не уверен, действительно ли страницы памяти имеют размер 256 байт (я получил эту цифру из таблицы данных чипа, таблица 28-11).

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

Просто чтобы уточнить, образ является дампом памяти ATmega после того, как вы написали своей программой? Вы говорите, что данные, загружаемые AVRdude, отличаются. Не могли бы вы также опубликовать изображение того, что загружает AVRdude? Вы смотрели на источник AVRdude и сравнивали его со своим, чтобы увидеть, что делается по-другому?
@embedded.kyle Мне нужно вернуться домой, чтобы опубликовать/протестировать материал... пока спасибо! Я обновлю вопрос через несколько часов. :)
Поскольку AVRdude имеет открытый исходный код, изучение того, что он делает, может помочь решить ваши вопросы.
Когда мне понадобилась загрузка через USB (полагаю, вам также понадобится 32u4 через USB), я попытался запрограммировать AT90USBxxxx через загрузчик AVR109 через USB. Но я обнаружил, что он глючный и ненадежный, поэтому я использовал стандартный Stk500 через USB с последней библиотекой LUFA, и я доволен. Мне не нравится AVR109 (и один почти идентичный протокол для еще более старых устройств).

Ответы (3)

Я успешно использую dfu-programmer в Linux (используя «голый» atmega32u2/atmega32u4) из командной строки. Так что очень легко интегрировать его в Makefile.

Цитата с этого сайта:

dfu-programmer-0.6.2.tar.gz содержит исходное дерево этого проекта. Загрузите его для сборки и установки в системе Linux/Unix/Mac.

Так что вы должны быть в состоянии построить его на Mac. Или вы можете посмотреть исходный код.

Документация AVR109 не очень понятна, но между документацией AVR109 и исходным кодом avrdude я написал простой код Java (используя jssc для последовательного порта) для записи во флэш-память на устройствах AVR. Конкретный код для связи с устройством и чтения .hex-файла (поддерживаются не все возможности .hex-файлов) находится здесь . Я не проверял его тщательно, но он правильно записывал и читал на устройстве (BrainLink), с которым я его использовал.

ps Что касается ваших конкретных моментов, AVR109 всегда сначала нужен старший байт (и для адресов, и для размеров блоков). Кроме того, адрес указывается словами, а не байтами, поэтому байтовый адрес нужно разделить на два. И перед любой записью во флеш нужно стереть флеш.

Пришлось обновить код: я забыл, что сначала нужно стереть флеш.

Если вы делаете прошивальщик микросхем только для программирования, вам следует прекратить работу над ним прямо сейчас. Atmel предоставляет утилиту под названием FLIP. Он записывает шестнадцатеричные файлы на чипы для вас с прямого USB, если чип поддерживает встроенный USB, например, семейство ATmega##U#.

Вы можете написать желаемую программу в Atmel Studio, сохранить шестнадцатеричный код, открыть Atmel FlIP и прошить шестнадцатеричный файл.

ПОДБРОСИТЬ

Ого, это старый вопрос!
В то время как FLIP, кажется, поддерживает Linux, версия для OSX, похоже, не предлагается, поэтому переносимость будет ударом по нему, особенно когда кажется, что на плакате уже работает более портативный AVRdude...
Если кто-то занимается программированием микроконтроллеров (или любым другим, если на то пошло) в OSX, у них почти всегда будет раздел Linux или Windows на том же компьютере. Если нет, то они делают это неправильно.
У меня сложилось впечатление, что iOS можно запрограммировать только из OSX, поэтому я не знаю о «или любом другом»…
Что ж, я уверен, что вы можете писать вещи для iOS на Linux. Я не уверен в окнах. Некоторое время назад я пытался начать, но помню, что столкнулся с проблемой в Windows. Linux — своего рода «рай для программистов» для общего программирования.
@ShannonStrutz - зачем мне запускать виртуальную машину для запуска ограниченного инструмента поставщика, когда есть переносимые и гибкие решения, которые компилируются и работают изначально на всех трех платформах? Виртуальная машина используется только тогда, когда нет более эффективной альтернативы. И ваше решение для разделов гораздо более неудобное, чем даже виртуальная машина, поскольку оно требует перезагрузки и потери всех ваших обычных инструментов.
Хорошо, это начинает раздражать, его решение AVRdude не работает. Он получает два отдельных шестнадцатеричных файла... Он никогда не говорит, что работает на OSX. Вам не нужно беспокоиться о переносимости метода программирования, потому что, если вы прошиваете прошивку и хотите продать ее конечным пользователям, вы продаете не программное обеспечение, а предварительно запрограммированное оборудование. Если вы можете получить его на чипе, он работает.
Смысл в том, что я писал этот флешер, состоял в том, чтобы иметь что-то легкое [по общему признанию: только воплощение предварительно скомпилированного образа], бесплатное (как в свободе) и пригодное для использования в качестве библиотеки (python). Итак, спасибо за ваше предложение, Шеннон, но мой вопрос действительно о написании кода для прошивки , а не о способе прошивки изображений.
Нужно объяснение, как прошивать HEX-файлы на ATmega32u4 по протоколу AVR109.
СпросиСетьПолитика конфиденциальности1y, 3v