Опять изобретать велосипед?, Bootloader STM32F103 IAR EEPROM. Опции

[misyachniy]

Есть уже готовый проект. Теперь к нему нужно прикрутить возможность обновления ПО в приложении.

Предполагается 2(4) метода получения ПО в EEPROM
1) По USB в штатном/аварийном режиме.
2) По FTP через GPRS в штатном/аварийном режиме.

В найденых мною примерах bootloader пишется и компилируется отдельно. Программа пишется отдельно и компилируется по разному, для отладки и для загрузки через бутлоадер.

Прием данных в EEPROM возможен как при обновлени так при при отказе соновной прошивки, следовательно нецелесообразно в бутлоадере и а основной программе дублировать функции для работы USB, GPRS, EEPROM.

Bootloader и основную пограмму можно положиь в разных секциях flash и компилировать один проект.
Затем с двоичного файла отрезать нужный кусок.

В сети не нашел подобных вариантов. Очевидно что есть скрытые (или очевидные :-) недостатки такого метода.
Какие именно недостатки?

[Golikov A.]

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

Достаточно сделать режим загрузки бутлоадера.
1. по флагу в памяти или горячей перезагрузки с флагом в РАМе
2. по специальной команде в начале загрузки (зажатая кнопка, или команда по порту и т.д.)
3. по отсутствию валидной прошивки (контрольная сумма, код безопасности и так далее.

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

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