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

[misyachniy]

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

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

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

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

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

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

[kan35]

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

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

Сообщение отредактировал kan35 - Jun 15 2014, 16:29