Здравствуйте, ребята!

Написал бутлоадер, написал пользовательскую программу. Оба в WinAVR. Есть в результате два .elf (ну или просто два сишника с main), теперь надо их соединить, да ещё так, чтоб бутлоадер попадал в "Boot Loader Flash Section".
Направьте меня, в какую сторону копать. Есть ли что-то в MakeFile's, что должно быть подправлено?

Ещё есть несколько конкретных впросов:

В даташите на мегу уделено много внимания "Read-While-Write Section" и "No Read-While-Write Section", я не очень с ними разобрался, вообще это важно?

Я сомниваюсь при выборе алгоритма обновления прошивки, сейчас в голове такая картина:
1. Пользовательская программа, решив обновиться, произносит заклинание asm{ jmp $3F00 }, где - $3F00 - Boot Loader Flash Section. (хоть это я правильно понял? Начнёт работать бутлоадер?)
2. Бутлоадер обновляет флэш и делает asm{ jmp $02A }, запуская тем самым пользовательскую программу (или она не там?)
Но почему-то хочется сделать всё через перезагрузку, вроде:
1. пользовательская программа ставит в EEPROM флаг "обновиться" и перезагружает МК
2. бутлоадер видит флаг, обновляет, снимает флаг, перезагружает МК
3. бутлоадер видит - флага нет, и запускает пользовательскую программу.
Но есть ли в этом смысл, и будет ли разница между была перезагрузка - не было?

Помогите, пожалуйста, у меня очень большое желание сделать красиво :)

Спасибо!

Не совсем. Ставите фьюз перехода на бут после сброса и контроллер будет туда переходить по сбросу. Соответственно приложение должно сбрасывать контроллер.
Все остальное тоже не до конца продумано. Обычно бутлоадер должен быть автономным от приложения, т.к. если во время перезаписи флэш выключится питание, вся система может рухнуть.

Спасибо большое, значит поставлю фьюз, чтоб первым всегда был автономный бутлоадер

Делайте загрузчик отдельным приложением. При линковке задайте параметр -Wl,-section-start=.text=адрес, где адрес - начало области загрузчика (в байтах!)Вектор сброса находится по адресу 0. Вот туда и передавайте управление. Не забывайте перед этим вернуть периферию в исходное состояние, а в приложении явно проинициализировать всю использованную периферию.Я использую одну из ножек, при нормальной работе настроенную на вывод. Если загрузчик видит ее настроенной на ввод - было включение питания, работа штатная. Если при этом нога притянута снаружи не туда, куда ее тянет внешняя подтяжка - это сигнал принудительной перепрошивки. Если нога притянута куда надо - проверка приложения и если все хорошо - его запуск. Если нога настроена на вывод - значит приложение передало управление загрузчику и надо сразу идти на перепрошивку.

Ух, как сложно и ненадежно. Переход в приложение должен быть выполнен практически сразу после входа в загрузчик (после сброса), тогда голова об инициализации болеть не будет. А сброс, конечно же, выполняется по собаке.

Запускать битый аппликейшн сразу, это похоже ваш стиль... И он должно быть "чертовски" надежен...

Я предпочитаю так:

Я этого не говорил, речь идет про недопустимую инициализацию железа в загрузчике между ресетом и переходом в приложение.


Вот-вот, именно так и не надо.

Спасибо за советы, я скопирую сюда уже тысячу раз сказанное "Bootloader - как сделать?" - прочитать апноут atmel 109, даташит на МК, WinAVR/doc/avr-libc/avr-libc-user-manual/boot_8h.html все вопросы отпадают.

AT91SAM7 стартует от RC на 32КГц. Приложение может быть до 512К (минус загрузчик). Вы представляете, сколько времени займет подсчет целостности этого приложения при 32КГц тактовой? Разрешите хоть PLL включить, а? У MSP430 после включения питания запущена собака. Если ее не отключить, через 32768 тактов она сбросит процессор. Разрешите отключить ее на время проверки целостности? defunct выводит диагностические сообщения в консоль. Разрешите ему UART настроить, а то не видно ничего? Нужные порты разрешите настроить на вывод, что б не болтались?

Если принимать высказывание Огурцова как напоминание, что приложение не должно рассчитывать, что что-то сконфигурировано загрузчиком, то можно придти к консенсусу

Так вроде ни кто не советует проверять перед каждым запуском

Я советую проверять перед каждым запуском. Мало ли какая ситуация случится, например - бутлоадер что-то шил и пропало питание.

И я советую. Куда торопиться? Наоборот, желательно иметь возможность обратиться именно к загрузчику после сброса до старта приложения. Конечно, от прибора зависит, но у меня 3 секунды загрузчик ждет.

Мы про AVR ?


Пока используется один программер, один камень и одно приложение, можно делать что попало. Как только чего-то становиться два и более, желательно забыть о допущениях, типа что приложение что-то там знает о загрузчике или загрузчик правильно деинициализируется на всех камнях.


Так AVR и сбрасывается собакой. Все остальное от лукавого. И собаку в загрузчике сбрасывать никто не запрещает.


Я не отключаю и не советую.


Это режим отладки ? Делайте что попало. Если штатный, то это уже допущение, которое требуется учитывать _всеми_.


А у Вас что-то болтается ? Не верю (с) По крайней мере у меня ничего никогда не болтается. В общем, опять мимо. Есть еще какие-то дургие причины инициализировать железо до контроля валидности флеша ?



Я советую. Так же как и загрузчик. Так же как и область данных. Так же как и фьюзы.

Вопрос на мой взгяд тупой, ровно настолько, насколько будет тупым вопрос - "есть какие-то причины позавтракать после того как почистили зубы?"

Давайте его перефразируем, чтобы вложить в него смысл:
- Есть еще какие-то другие причины инициализировать железо перед запуском приложения?

Есть конечно же.
Первая и наиболее серьезная причина - влетели в бут нештатным образом (врезультате ошибки основного приложения).

Вторая причина - допустим Bootloader проверил целостность, и с апп - все Ок. Как теперь ему узнать надо обновлять прошивку или не надо?
Без инициализации периферии - никак (аргумент "аппликейшн сообщает" - не катит, т.к. такой подход добавляет зависимость между бутлоадером и приложением).
Итого хоть какую-то периферию проиниализировать надо чтобы принять решение, что буту делать дальше:
1. обновить прошивку;
2. запустить приложение;
3. сделать что-то еще (например провести диагностику железа, отгрузить дамп/статисткику последнего запуска и т.п.).

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


В приведенном выше коде консоль используется в штатном режиме. (полезно вообще, и вдвойне полезно когда возникают какие-то проблемы).
учитывать _всеми_ - кеми? Основное приложение у меня и не знает о существовании бутлоадера. Работает как с ним так и без.

Выключить периферию так, чтобы от железного сброса было не отличить - дело нехитрое. Насколько это сложно - сами видите, достаточно просто записать 0 в соотв. регистры периферии.

Резетить контроллер из бутлоадера по WDT после проверки целостности прошивки чтобы запустить app, одним словом называется - дебилизм. Причину назову если спросите. (конечно же вы так не делаете, поэтому это к вам не относится. Только тут у меня возникает вопрос - а как вы запускаете приложение после обновления прошивки, ведь в процессе обновления прошивки вы периферию инициализируете, не так ли?).


По поводу сбрасывания WDT - тут строго говоря, всегда надо исходить из того, что по законам Мерфи WDT включен и обязательно с минимально возможным интервалом.
А это значит, что в некоторых случаях (низкая тактовая + обновление NRWW) может понадобиться хотя бы изменить его интервал, иначе МК может сброситься при выполнении SPM.

Назовите, если не сложно (я не с целью подлить масла в огонь, просто хочется знать). Вопрос как быть если в уарте, например, "недопереданный байт" остался. Хотя в принципе это тоже можно проверить и дождаться окончания передачи.

Резонно, т.к. там была редакция, которая куда-то исчезла. Звучало примерно: "между ресетом и запуском приложения". Где-то между этим, конечно, проверка.


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


Очень даже как. Так же, как у атмела. По холодному старту ждем апдейт, если он не произошел, по таймауту собаки сваливаемся опять в загрузчик, проверяем как в него попали, проверяем флешь и если все нормально уходим в приложение.


А зачем этим всем заниматься загрузчику ? Вообще, какое назначение у загрузчика ? И самое интересное, как запихать все хотелки в тыщу слов ?


В этом нет никакой необходимости.


Программерами, схемотехниками, камнями, приложениями...


Только для одного камня. Иначе хитрое.


Вы явно не представляете по каким граблям прыгаете ATmega128.UCSRnC Initial Value 0 0 0 0 0 1 1 0
И, главное, закладываете эти грабли на будущее. Или есть какие-то гарантии, что оно еще и не изменится в новой ревизии ?


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


Я же уже сказал - после ресета.


Конечно надо. В чем, собственно, проблема ?

Ничего не понял, сорри, как у Atmel'a? Если можно, объясните более подробно - как по холодному старту ждать апдейт без проинициализированной периферии?


Ну в m128 и подобных с 4K слов бутом есть где разгуляться. Все хотелки есть где разместить.


Обоснуйте.


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


То плачетесь что 1000 слов мало, то хотите чтобы программа из 1000 слов учитывала особенности всех камней. Понятное дело, бутлоадер затачивается напильником под конкретный камень, а иногда (чаще) под конкретный девайс. И тщательно следит за тем чтобы прошивки от других девайсов часом не залили в этот, т.к. чужая прошивка может попросту спалить железо.


Зачем UCSRxC вообще трогать?! Он за вкл/откл уарта не отвечает.


А вы что привязываетесь к default настройкам? или приложение таки настраивает то, что ему нужно?


Т.е. обновили прошивку, проверили app CRC, и сбросились по WDT, для того чтобы опять проверить CRC. Чем же это не тот же самый дебилизм?!


Причина - глобальное зацикливание
После сброса мы опять попадаем в bootloader, и опять проверяем app CRC и опять резетимся, и опять попадаем в бутлоадер ......

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

И это единственно правильно. Ну до тех пор, конечно, пока не начинаете что-то инициализировать.


Это вы вынуждены учитывать, т.к. что-то инициализируете. А правильно не учитывать особенности, а не зависеть от них. И это гораздо проще и жрет меньше флеша.


Да какая разница UCSRxC или какой другой. Просто пример, что не все инициализируется нулями. А вы хреначите во все регистры нули...


А что не нужно - не настраивает. А вы это "ненужное" в загрузчике под себя настроили. И забыли...


Посмотрите апнот от атмела. Потом пишите про дибилизм. Если все еще будет не понятно.

Непроинициализируете - не обновите прошивку.


Специально для тех кто в танке - еще раз - как ваш бутлоадер получает прошивку которую надо зашить во флеш? И как ваш бутлоадер проверяет подходит ли прошивка к конкретному устройству.


Код то смотрели? Где там "во все"?


С чего вы взяли, что мы о чем-то забыли? Вы экстрасенсорно определили?
Ничего мы не забыли.

Какой аппноут. Своими словами вам религия не позволяет объяснить суть?

Самое главное, Вы бутлоадер-то для кого обычно пишете (если пишите его вообще) - для себя или для пользователя вашего устройства?

PS: Если не затруднит - напишите ответ на самый первый вопрос предыдущего моего комента:
Без ответа на этот вопрос дальнейшие рассуждения бессмыслены, т.к. отстается только полагать, что Вы просто не владеете темой.

Согласен. Или я писал обратное, то при обновлении нельзя инициализировать ?


Как и у атмела - сигнатура. На тип девайса. В т.ч. прошивка может подходить к разным девайсам, но не конфликтующим по железу.


Смотрел. Код (наверно) правильный. Подход неправильный.


Сегодня не забыли, завтра забыли. Опыт, блин, и практика.


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


Не то и не другое. Загрузчик - для устройства.


Разберитесь с атмеловским примером. Если он непонятен, то таки да, все зря.

AVR109 озвученный здесь я читал. Думал может быть Вы ссылаетесь на какой-то другой документ.
А так получается (уж насколько не печально выглядит), что Вы таки не владеете темой.
appnote AVR109. Figure 7. Самый первый пункт алгоритма - инициализация периферии.

Отрывок кода main из AVR109:




Затем, что вы несете пургу преподносите нам полуправду (которая хуже чем откровенная ложь).

О да, вынужден признать, что это не тот документ про который я говорил. Дабы не рыться в поисках, откуда оно было украдено, вот общий принцип:




Вот интересно, а слабо будет извиниться ?

Да не вопрос, извинюсь когда Вы дадите себе труд найти оффициальный документ описывающий этот принцип. Так как Вы дважды посылали меня рыться в аппнотах от Atmel, то желательно чтобы этот документ был от Атмел. Но я пойду Вам навстречу, приму документ от любого производителя МК...


Несмотря на проявленное неуважение к моему времени, скажу очень мягко:
По коду принцип к сожалению не очень понятен. Понятно только - что из пользовательской программы никак нельзя заставить бутлоадер обновить прошивку. А это IMHO минус, сами себя лишили возможности удаленного (автоматизированного) обновления прошивки.
И еще одно - даже в Вашем принципе без настройки периферии - никак.

Аха, а вы еще обвините меня в том, что я сам это придумал


Никто не мешает передать управление на точку Bus_init() или подобно.


Опять мимо. Это частный случай реализации и не идеальный. Первые две строки логично перенести перед Bus_init(), на работу загрузчика это не повлияет, хоть и менее изящно. В общем-то я так наверно и сделаю.

Вы сами это сказали. Подтверждения обратного пока нет.


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


Всё-то у вас частно, и не идеально. А где же тот самый идеальный вариант, который Вы всем советуете делать? Как же другие его будут реализовывать если сам автор идеи его реализовать не может!

Да и не мимо тут, а как раз в точку (хотя бы потому, что без настройки периферии, сброс по WDT сделать нельзя)..
Код сами привели никто за уши не тянул.

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


Хех, так я ж сказал, как сделать правильно, без какой бы то ни было инициализации периферии. Недостаточно ? Или вы мне м.б. сейчас про указатель стека напомните ? Да, тут таки сложно наверно будет возразить.

С этим флеймом пора заканчивать... "правильно", "неправильно", детсад какой-то. Пока получается, что все делают неправильно, только Вы один знаете как надо делать правильно, и тем не менее приводите неправильный код.

Или приводите документ с описанием принципа из comment #23 и мы проникаемся правильностью идеи...
Или честно скажите - "придумал сам, насколько это правильно или неправильно - не знаю".

И вам спасибо (с)