Ну где-то так я себе это и предсатвляю. У меня еще вот вопросы:
1. Как можно определить программно размер записанной программы в МК.
2. Как программно перегрузить МК?

Критика – это хорошо, разъясните еще как это сделать для ТС, будет вообще здорово .

Делаю примерно так же, но помимо текущей версии ПО, храню в памяти программ и дефолтную заводскую прошивку, чтобы можно было одной простой командой откатить версию прошивки на гарантировано рабочую. Просто специфика в том, что прошивку подгоняют под нужды заказчиков прямо на объекте, а при проблемах с новыми версиями необходимо максимально быстро восстановить работоспособность устройства.
Вот для возможности запуска обоих прошивок и переношу таблицу прерываний в область нужной мне прошивки.

По программной перезагрузке:
функция NVIC_SystemReset(); в StdPeriph Lib от STM.

Сообщение отредактировал lead_seller - Apr 19 2012, 07:31

Вот для Вас полезная ссылочка будет
тыц

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

Например - с помощью внутреннего сторожевика.

позвольте встрять в вашу беседу.
с СТМ я пока еще только теоретик, и у меня возник вопрос:
если имеются во флеш firmware1 и firmware2.
допустим firmware1 - битый, тогда как стартанут с firmware2 без использования ассэмблерной комманды по переходу на точку входа firmware2?

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

При каждом старте бутлоадер проверяет целостность прошивки по CRC. Если CRC совпало то стартуем custom прошивку, если прошивка битая - проверяем целостность default прошивки и стартуем ее, если и default окажется битым, то бутлоадер будет ждать процесса прошивки.
А запуск прошивки реализуется переносом таблицы векторов и банальным переходом по стартовым адресам прошивок (они жестко заданы).

По данным - области константных данных в Flash контроллера для каждой из прошивок свои, данные во внешней SPI flash (там хранятся настройки и архив) при подгрузке их любой прошивкой проверяются (тем же CRC) и если они не подходят для работающей прошивки изменяются на настройки по умолчанию. Так что никаких проблем с несовместимостью данных не возникает

Сообщение отредактировал lead_seller - Apr 19 2012, 07:47

По моему алгоритму у вас НЕ МОЖЕТ оказаться случая, что обе прошивки битые (при условии что начальная прошивку на заводе прошла нормально).

Не спорю. Вообще и при моем алгоритме тоже. Но лучше перестраховаться, чем телепать в шахту, и в полузатопленном штреке, при свете коногонки, перепрошивать устройство по JTAG). У меня задача, обеспечить максимальную вероятность того, что устройство запустится с хоть какой-то прошивкой, и 100% вероятность того, что при работающей связи и питании, его можно будет прошить удаленно.

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

У нас проблемы с настройками связи не возникают. По всей сети одна, жестко заданная скорость CAN. Максимум что может случится - изменится идентификатор устройства (номер) на линии, на номер по умолчанию. При этом он все равно останется уникальным (при монтаже номер по умолчанию не используется), а потом его поменяют командой сверху. Все остальные данные генерятся непосредственно прошивкой на этапе самотестирования.

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

Сообщение отредактировал lead_seller - Apr 19 2012, 12:38

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

1. Перед переходом на приложение запретите прерывания.
2. Если разрешен Watchdog, задайте его период "с запасом" и перед переходом на приложение
вызовите IWDG_ReloadCounter();
3. Если бутлоадер использует USB, не забудьте выполнить USB_Cable_Config(DISABLE);
4. Отключите устройства, которые не используются приложением, если такие есть.

5. В приложении первым действием задайте новый адрес таблицы векторов, затем проинициализируйте WatchDog и только потом разрешайте прерывания. После Reset, инициированного Watchdog'ом или после прошивки по JTAG, STM32 стартует с текущей таблицей векторов, т.е с начала приложения. Поэтому приложение в общем случае не должно знать о существовании бутлоадера и о том, какая периферия уже была включена и настроена. В приложении лучше сделать все заново.

6. STM32 XL-Density имеют два банка Flash по 512К, расположенные с одного и того же адреса.
Какой банк будет подключен после Reset, задается в Option Byte. Этот механизм можно использовать
для хранения двух версий прошивки, скомпилированных с одного начального адреса. При этом, бутлоадер нужно продублировать в каждом банке.

Подскажите, как сделать безусловный переход по адресу. Бутлоадер записал прогу например по адресу 0х08010000. Находила примеры типа

Но при выполнении последней строчки (вызов функции) FuncPtr() стшка вылетает в хард фолт. В чем может быть проблемма и как организовать прыжек из бутлоадера в основную программу? Может, можно сделать ассемблерную ставку типа goto или jump?

Нужно к адресу прибавить единицу. Это особенность режима Thumb. На досуге почитайте систему команд кортексов, посмотрите листинг дизассемблера.