Приветствую всех. Ребята, нужна помощь в любом виде.
На днях понадобилось мне (вдруг) прикрутить к мк ATmega328p (тот, что в Arduino Nano стоит) хорошо известный «китайский» загрузчик AVRUBD. Благо, раньше (но очень давно) с ним (и не только) уже работал, даже под ATmega8 какой-то корявый свой даже написал.
Вроде как все вспомнил, сконфигурировал его, учел все последние рекомендации, которые опубликованы в сети. В AVRStudio 4 версии его скомпилировал, без ошибок, чуть больше 1.3 Кб размер. Залил в микроконтроллер, проверил, что загрузчик в прошивке начинается с адреса 0х7800. Подготовил тестовый файл прошивки, подал питание на мк и наблюдаю следующую картину: загрузчик запускается (светодиод мигает), программа AVRUBD коннектится (синхронизируется) с ним (Connect Success), начало загрузки файла прошивки и получаю сообщение «Too many retry» , т.е. ошибка загрузки прошивки.
Все проверил, скорости портов (мк и USB-COM, совпадают, 19200), тактовая частота мк 16 МГц. Проверил еще раз все адреса: в прошивке загрузчик начинается с адреса 0х7800 (соответственно выставлены Fuse-биты и Lock-биты), в студии настроена секция Flash-памяти .text=0x3c00, в файле конфигурации загрузчика установлен параметр «#define BootStart 2*0x3C00UL». Скорость обмена, параметры загрузчика, пробовал менять – ничего не меняется. Ошибка - «слишком много повторов/Too many retry».
Сконфигурировал загрузчик без сторожевого таймера и без проверки данных – процесс пошел, результат – «успешно», но по факту – во Flash-памяти пусто, только загрузчик…
Начал смотреть исходник загрузчика и понимаю, что ошибка эта появляется и накапливается (до 3) на этапе сравнения принятого буфера и считанной после записи страницы (128 Байт) Flash, т.е. получается что мк ничего не может записать, загрузка буфера повторяется 3 раза, а потом прекращается.
Кто-то сталкивался с такой проблемой? В mega328p есть какие-то отличия в механизме загрузчика и «самопрограммирования»?

Раз помощь в любом виде, то вот аналогичная проблема на avrfreaks. Там несколько вариантов решения предлагалось - проверить, нет ли запрета на запись в соответствующий раздел flash, проверить адреса, и еще варианты. Но это, вроде бы, уже сделано. Более ничем помочь не могу, с AVRUBD не работал.

Спасибо. Это видел, постарался проверить все что там описано. Не помогло.
Кроме того, учитывая древность загрузчика, пробовал прогу загрузчика на стареньком ноуте с XP, также использовал HyperTerminal - результат один и тот же, начало загрузки и ошибка "слишком много повторов".
Сейчас нашел исходники ардуиновского загрузчика Optiboot, говорят он неплох. Попробую проанализировать его и сравнить с AVRUBD в плане алгоритма записи Flash.

Терминалка ? Прошивка передается по XMODEM'у ? Тогда фраза про повторы может означать повторные попытки передачи пакетов этого самого XMODEM'а. Т.е., пакеты попросту бьются. Почему ? А вы точно уверены, что кварц завелся на частоте в 16 МГц, и вообще в том, что МК тактируется от кварца ? И еще, на стороне машины должно быть правильно настроено управление потоком ...

Еще вариант - ваш загрузчик путает спец. символы протокола XMODEM (например, заглавную и строчную "C"):

http://microsin.net/adminstuff/other...-overview.html

Цитата:

Сообщение от kovigor

Терминалка ? Прошивка передается по XMODEM'у ? Тогда фраза про повторы может означать повторные попытки передачи пакетов этого самого XMODEM'а. Т.е., пакеты попросту бьются. Почему ? А вы точно уверены, что кварц завелся на частоте в 16 МГц, и вообще в том, что МК тактируется от кварца ? И еще, на стороне машины должно быть правильно настроено управление потоком ...

Да, терминалка, да он самый XModem. По началу я тоже был уверен в том, что имеет место несовпадение скоростей портов мк и компа.. Я очень внимательно проверил все Fuse-биты (да вроде как и с пониманием их не замечал у себя проблем), мк настраивал и на внутренний осциллятор (при этом попутно увидел, что мой программатор некорректно работал с Fuse-битами данного мк и устранил этот глюк, думал что все.. в этом беда была, ан нет...).
Проверю еще раз настройки порта касаемо управления потоком...

Цитата:

Сообщение от kovigor

Еще вариант - ваш загрузчик путает спец. символы протокола XMODEM (например, заглавную и строчную "C"):

http://microsin.net/adminstuff/other...-overview.html

Не думаю, проверял в терминалке - когда запускается загрузчик в мк он ожидает пароль (символ "d"), я отправляю с терминалки, загрузчик отвечает приглашением символ "C", после этого я выбираю файл на отправку (прошивка, *.bin), указываю протокол и "Send". И насколько понимаю, первые 128 байт уходят в мк, мк пытается их записать во Flash - не получается (т.к. считанные с Flash данные не совпадают с данными в буфере), запрос на повторную отправку и так три раза.

Но, все же я проверю и этот момент...
Завтра хочу попробовать мониторинг COM-порта сделать...

Цитата:

Сообщение от Vadzz

запрос на повторную отправку и так три раза.

Так вот не факт, что дело вообще в памяти. Возможно, просто бьются пакеты с данными -> не совпадает CRC -> данные признаются сбойными и никуда не пишутся.
А еще можно перепутать русское и английское "C".
И еще. Ничто не мешает в загрузчике отмечать целые пакеты зеленой лампочкой, а битые - красной. Сразу все и поймете ...

Цитата:

Сообщение от Vadzz

Начал смотреть исходник загрузчика и понимаю, что ошибка эта появляется и накапливается (до 3) на этапе сравнения принятого буфера и считанной после записи страницы (128 Байт) Flash

Цитата:

Сообщение от kovigor

Так вот не факт, что дело вообще в памяти. Возможно, просто бьются пакеты с данными -> не совпадает CRC -> данные признаются сбойными и никуда не пишутся.

Вряд ли бьются пакеты. Но если так, Vadzz, посмотрите вот тут пару багов самого загрузчика AVRUB v4.5, исправление от 2012 года. На sourceforge актуальная версия загрузчика 5.2

1. In file bootldr.c, add below in line 475 and 499:
bufptr -= BUFFERSIZE;
It will cause download fail when CRC error. 
2. In file bootldr.c, replace lines
(*((void(*)(void))(BootStart)))();
to
(*((void(*)(void))(BootStart/2)))();

Цитата:

Сообщение от antonydublin

Вряд ли бьются пакеты. Но если так, Vadzz, посмотрите вот тут пару багов самого загрузчика AVRUB v4.5, исправление от 2012 года. На sourceforge актуальная версия загрузчика 5.2

1. In file bootldr.c, add below in line 475 and 499:
bufptr -= BUFFERSIZE;
It will cause download fail when CRC error. 
2. In file bootldr.c, replace lines
(*((void(*)(void))(BootStart)))();
to
(*((void(*)(void))(BootStart/2)))();

Правки от 2012 года вносил - результат тот же.
А вот версию 5.2 не находил. Сегодня проверил... Сразу глянул исходники и вижу, что алгоритм записи страницы в память Flash переработан и очень похож на тот, что в ардуиновском загрузчике (ардуина, Optiboot). Тем не менее -результат такой же (не беру во внимание некоторые глюки с конфигурированием загрузчика), что заставило меня усомниться в правильности настройки микроконтроллера и загрузчика, в частности адресов областей Flash-памяти программы и загрузчика. Но я всё перепроверил, вроде все правильно.... Но судя по исходнику этот алгоритм применяется ко всем микроконтроллерам (в исходнике нет директив условной компиляции в зависимости от того какой контроллер выбран), что мне кажется некорректным...

Копаю дальше, уже с версией avrubd 5.2...

В ходе экспериментов (с использованием монитора COM-порта) обнaружил, что в версии avrubd 4.5 протокол XModem реализован некорректно, не берусь пока утверждать это на 100%, но если пакет данных принят с ошибками и приемник сигнализирует ответом NAK, то передатчик должен повторить отправку этого пакета с соответствующим номером пакета. А avrubd, когда приемник отвечает NAK возможно и повторяет отправку пакета, но номер пакета при каждой повторной отправке увеличивается на 1... Этот момент я еще проверю...