[batisto4ka 0]

1. неизменяемой части (загрузчика) в первом секторе флеш, который прошивается изначально на заводе и при удалённой прошивке не может быть перешит;

2. собственно рабочего ПО (во флеш после загрузчика).

Ну где-то так я себе это и предсатвляю. У меня еще вот вопросы:

1. Как можно определить программно размер записанной программы в МК.

2. Как программно перегрузить МК?

[Danis 0]

Неправда :)

 

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

 

[lead_seller 0]

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

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

 

По программной перезагрузке:

функция NVIC_SystemReset(); в StdPeriph Lib от STM.

Изменено 19 апреля, 2012 пользователем lead_seller

[Danis 0]

Ну где-то так я себе это и предсатвляю. У меня еще вот вопросы:

1. Как можно определить программно размер записанной программы в МК.

2. Как программно перегрузить МК?

 

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

тыц

 

[jcxz 243]

1. Как можно определить программно размер записанной программы в МК.

В общем случае - никак.

Если вам нужно определять размер, то можно зафиксировать его постоянным (равным макс. доступной памяти программ).

Возможно в каких-то конкретных компоновщиках есть возможность определить максимальный адрес размещения прошивки и

поместить его в заранее определенное место памяти - тогда можно воспользоваться этим.

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

2. Как программно перегрузить МК?

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

[Marto 0]

....с огромной вероятностью разрывов на линии. При этом вероятность того, что устройство продолжит функционировать после неудачной перепрошивки, должна стремится к 100%.

 

позвольте встрять в вашу беседу.

с СТМ я пока еще только теоретик, и у меня возник вопрос:

если имеются во флеш firmware1 и firmware2.

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

[jcxz 243]

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

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

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

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

[lead_seller 0]

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

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

 

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

Изменено 19 апреля, 2012 пользователем lead_seller

[jcxz 243]

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

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

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

[lead_seller 0]

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

[jcxz 243]

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

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

У нас по этой причине запрещены даунгрейды ПО.

[lead_seller 0]

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

 

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

Изменено 19 апреля, 2012 пользователем lead_seller

[EugenyAM 0]

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

 

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. Этот механизм можно использовать

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

 

 

[batisto4ka 0]

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

void (*FuncPtr)(void);

FuncPtr=(void(*)(void))0x08010000;   //адресс куда переходим
FuncPtr();

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

[scifi 1]

Но при выполнении последней строчки (вызов функции) FuncPtr() стшка вылетает в хард фолт.

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

((void(*)(void))0x08010001)();