[batisto4ka 0]

Помогите, пожалуйста, поставить точки над i. Насколько мне понятно, в stm32 bootloader может быть использован вместо программатора. Для того, чтоб залить прошивку в контроллер, необходимо подсоединить плату с МК к компу через ком порт( по USART1 МК), подать на вход бут0 1, на бут 1 -0, загрузить бинарник, используя специальную утилиту Flash Loader Demonstrator.Это весь алгоритм?

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

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

[lead_seller 0]

Бутлоадер (термин "загрузчик" имеет несколько значений, например, есть еще загрузчик ОС) - это код который позволяет прошить МК не используя стандартные средства МК (для STM32 таким средством является JTAG). Контроллеры STM32 уже с завода имеют такой бутлоадер, работающий по USART (это как раз то, что Вы описали - с управлением ножками BOOT0 и BOOT1).

В общем же случае, "написать бутлоадер" означает написать такой код, который будет менять прошивку контроллера без применения JTAG по какому-либо протоколу (например, на плате есть возможность установки SD-карты, пользователь кидает на карту hex-файл, и Ваше устройство обнаружим такой файл заливает его содержимое в память программ МК).

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

[KnightIgor 2]

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

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

1. Со встроенным загрузчиком (USART0, Flash Loader) все верно.

2. Написать свой загрузчик означает использовать для обновления программы микроконтроллера иные способы коммуникации нежели те, что уже в данном микроконтроллере встроены. Например, через USB, или I2C, или Ethernet или чтение с SD-карты. В этом случае необходимо написать часть кода основной программы (которая ИЗНАЧАЛЬНО попадает в микроконтроллер исключительно либо через JTAG, либо как Ваш первый вопрос) так, чтобы он обеспечил обновление программы. Это весьма нетривиальная задача.

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

[batisto4ka 0]

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

[nicks80 0]

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

Сейчас имею проект с W5100 и stm32 + SD с fatfs.

Надо написать обновление прошивки по Ethernet.

Код с рабочим изернетом занимает 12килобайт + 30байт рам.

Как думаю делать.

Загрузчик (1 подпрограмма) при команде обновления по изернету принимает прошивку и шьет ее допустим с адресса на 20 кило больше чем основная программа.

При перезагрузке(1 подпрограмма) проверяет crc осноновной прошивки и если совпадает то запускает программу по адресу на 20 кило больше.

Еще как вариант. написать 1 функцию прошивальщика и все переменные для работы с изернетом будут в стэке этой функции. Загрузит ее в рам. и запустить.

а потом как в 1м варианте.

 

вот еще

http://we.easyelectronics.ru/STM32/stm32-i...h-programm.html

[batisto4ka 0]

И еще хотелось бы уточнить, есть отладочная плата sk-mstmf107. В нее залита некая программа. Отключаю питание, ставлю пеермычку на J5. Запускаю Flash Loader Demonstrator. Выбираю порт, бодрэйт 9600 (пробовала и все остальные варианты скоростей), паритет -четный, эхо-дизэйблт, ттаймаут 5. Включаю плату, пытаюсь соединиться, вылазит "No response from target, the Boot loader cannot be started. Please, verify the boot mode configuration and the flash protection status, Reset tour device then try again".

Что не так? Я что-то пропустила? Если с "verify the boot mode configuration" понятно (boot 0 =1, boot 1 =0), то что имеется в виду под "flash protection status"? Может в этом причина? Еще в документе AN2606 Application note STM32™ microcontroller system memory boot mode нашла следующее: Connectivity line

USART1 / USART2 (remapped) / CAN2 (remapped) / DFU (USB Device). А на самой отладочной плате сам ком-порт запаян на USART2. Может в этом причина?

И все же, еще раз хотелось бы уточнить.

1. Если, допустим, есть доступ к USART1 (соединение по ком-порту между USART1 МК и ПК), можно залить прошивку, используя утилиту Flash Loader Demonstrator, предварительно посадив ногу бут0 на 1, а бут 1 на 0?

2. Если, например, нет возможности подсоединиться к USART1, нужно писать свой загрузчик. При этом переход в ситем бут лоадер осуществляется ИСКЛЮЧИТЕЛЬНО ПРОГРАММНО? Никаких махинаций с ногами бут 1 и бут 0 проводить не нужно?

3. Что будет с МК при включении, если сконфигурировать boot0=1, boot1=0? Будет спокойно выполняться старая прошивка пока по юсарту не прийдет комбинация спец символов для перехода в систем бут лоадер? Или МК просто повиснет пока не снять сигнал с бут0 и не перегрузить МК?

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

[lead_seller 0]

Собственно ответы:

1. да

 

2. нет. Заводской бутлоадер активируется только подачей соответствующих сигналов на соответствующие ноги. Если Вы хотите написать собственный бутлоадер, то должны будете полностью реализовать всю логику прошивки контроллера - получение прошивки с ПК (или иного носителя прошивки), временное хранение в контроллере, верификацию этой прошивки (проверки правильности полученных кодов), запись полученной прошивки в Flash-память контроллера, передачи управления залитой прошивке. По поводу логики работы бутлоадеров можете почитать апнот от STMй AN2557 (http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/APPLICATION_NOTE/CD00161640.pdf). В нем описывается логика работы бутлоадера с передачей прошивки по USART (не путать с заводским).

 

3. МК будет ожидать прошивку, пользовательская программа выполнятся не будет. Ноги BOOT0 и BOOT1 определяют из какой области памяти будет грузится контроллер. Подробнее об этих ногах расписано в AN2606 (http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/APPLICATION_NOTE/CD00167594.pdf)

 

А от себя добавлю (строго мое мнение, без намерения кого-либо оскорбить), написание бутлоадеров не самая тривиальная задача, которая требует достаточно хорошего знания периферии микроконтроллера, ядра Cortex-M3, и особенностей работы компиляторов.

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

[scifi 1]

А от себя добавлю (строго мое мнение, без намерения кого-либо оскорбить), написание бутлоадеров не самая тривиальная задача, которая требует достаточно хорошего знания периферии микроконтроллера, ядра Cortex-M3, и особенностей работы компиляторов.

+1.

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

[Danis 0]

+1.

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

 

+1. Таблицу векторов прерываний тоже переносить надо.

 

 

От себя добавлю, я имел опыт написания своего загрузчика на PIC18, PIC24, там куда сложнее чем на STM32, поэтому после ознакомления с последним, написание загрузчика составило не больше 1-й недели. Тут, по сути, Вам надо разобраться, как с flash работать, как работать с контроллером прерываний, как работать с желаемым коммуникационным интерфейсом, уметь писать для ПК простые ”утилитки”, на уровне работы с COM портом. По поводу верификации поищите по форуму, я как то создавал тему по модулю CRC на STM32, вещь ‘железная’ и простая, там и ”исходники” выложил. Вообще свои загрузчик нужен там, где его нет заводского, либо там где нет пригодного коммуникационного интерфейса в заводском загрузчике, но есть на борту МК, либо нужно защититься от плагиата, т.е. использовать шифрованный загрузчик. Среди STM32 я писал шифрованный USB загрузчик для STM32F1 и для STM32F2 семейства, там разница не так уж большая, разве, что размер секторов в семействе F2/F4 немного удручает.

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

[batisto4ka 0]

А от себя добавлю (строго мое мнение, без намерения кого-либо оскорбить), написание бутлоадеров не самая тривиальная задача, которая требует достаточно хорошего знания периферии микроконтроллера, ядра Cortex-M3, и особенностей работы компиляторов.

 

 

Всем спасибо за советы и ответы. Мне приходилось как-то писать свой компилятор и интерпретатор на базе pic24, писать/читать флеш-память вроде как умеем, мелкие улититки по передачи через ком порт для ПК писать приходилось. В проекте, дя которого нужно написать свой бутлоадер, как раз такая ситуация " либо там где нет пригодного коммуникационного интерфейса в заводском загрузчике", то есть сам юсарт1 занят под другие нужды (в проекте используется камень stm32f103vet).

 

То есть вроде как все махинации с флешкой понятны, но, поскольку еще не начинала "колупать" остаются вопросы:

1. Не понятно, зачем пеерносить таблицу векторов прерываний.

2. Сейчас пок а вголове созрела идея такая: первую страницу ПЗУ использовать для хранения своего загрузчика. Ее защитить от записи. В эту область будет попадать программный счетчик либо при старте системы, либо когда нужно будет перепрошивать МК. Условие попадание будет проверяться по какому-то флагу. Если это обычный режим работы, то бутлоадер отправляет программный счетчик на начало программы. А программа сама будет записываться со второй страницы. Таким образом, сам загрузчик может быть стерт только при перепрошивке с помощью программатора, либо иным способом, предусморенным программой загрузчика. И тогда, если теоретически, так сделать можно, то остается вопрос, как с помощью стандартной улититы (стмовского флэш лоадер демонсттратор) зашить бинарник, как понять сигналы утилиты и т.д. Это думаю найти в AN2557, который посоветовал load_seller.

 

 

[lead_seller 0]

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

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

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

[batisto4ka 0]

Правильно ли я понимаю, что под переносом таблицы векторов понимается копирование . То есть старая таблица векторов прерываний рапсоложенная по адресу 0x0000_0000 согласно RM0008 Table 63. Vector table for other STM32F10xxx devices остается на том же месте, и еще дополнительно копируется для своего бутлоадера? Как тогда контроллер при срабатывании прерываний будет понимать,какая обработчик ему нужно вызвать? и как описываютсся обработчики прерываний, перенесеннной таблицы веткоров прерываний?

[Danis 0]

1. Не понятно, зачем пеерносить таблицу векторов прерываний.

 

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

У меня два проекта отдельных:

Первый – загрузчик, начинается с начала flash микроконтроллера (0x08000000), таблица векторов с адреса 0х08000004, соответственно свои обработчики прерываний, которые к загружаемой прошивке не имеют никакого отношения.

Второй – прошивка (firmware), готовиться и отлаживается отдельно от загрузчика (так же начиная с адреса 0x08000000), после ее разработки и отладки, переносите таблицу векторов (ну соответственно и адрес начала программы во flash) на несколько килобайт вперед (в зависимости от размере загрузчика и размера страницы памяти микроконтроллера), компилируйте с выходом простого «бинарника».

Так Вы гарантируете /перенос таблицы и начало программы/ отсутствие наложения проектов при их объединении в один «кусок». Объединение в один проект очень просто, зашиваете загрузчик, зашиваете прошивку, по средствам своего загрузчика, считываете всю память.

Так сделано у меня, и я не выдаю это за лучший вариант организации.

 

 

 

Правильно ли я понимаю, что под переносом таблицы векторов понимается копирование . То есть старая таблица векторов прерываний рапсоложенная по адресу 0x0000_0000 согласно RM0008 Table 63. Vector table for other STM32F10xxx devices остается на том же месте, и еще дополнительно копируется для своего бутлоадера? Как тогда контроллер при срабатывании прерываний будет понимать,какая обработчик ему нужно вызвать? и как описываютсся обработчики прерываний, перенесеннной таблицы веткоров прерываний?

 

Нет.

NVIC - Контроллер вложенных векторизированных прерываний STM32, позволяет гибко располагать таблицу во флэш или ОЗУ.

Как раз при его конфигурации и указывается адрес начала этой таблицы.

 

и как описываютсся обработчики прерываний, перенесеннной таблицы веткоров прерываний?

прерываний?

Обработчики прерываний описываютсся одинаково везде.

[KRS 1]

таблица векторов с адреса 0х08000004

у cortex-m3 таблица векторов не может с такого адреса начинаться!

зачем куда то копировать/перносить таблицу? У cortex-m3 в контроллере прерываний есть регистр который указывает где таблица находится!

 

в IAR например можно так стартовать программу

                VTOR = (unsigned) адрес приложения (в начале таблица прерываний)
                asm ("ldm r1, {r0,r1}\n"
                     "mov r13, r0\n"
                     "mov r15, r1");
                while(1);

 

[jcxz 220]

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

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

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

У нас работают тысячи устройств имеющих загрузчик (правда на LPC). Обновление прошивки - по любому интерфейсу по рабочему протоколу, при внезапной перезагрузке ничего не слетит 100%, загрузка нового ПО может быть продолжена с точки разрыва. Сбой питания возможен в любой момент хоть при загрузке прошивки хоть при обновлении её во флеш. Никакие таблицы векторов переносить не надо - на время работы загрузчика прерывания запрещены, рабочее ПО при старте само настраивает таблицу прерываний.

ПО состоит из:

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

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

Вся флеш (за исключением первого сектора) делится на две половины: первая - область исполняемого рабочего ПО; вторая - область хранения нового ПО, которое надо прошить.

Рабочее ПО по любому интерфейсу (или по всем включая CAN и беспроводные) принимает прошивку по рабочему протоколу устройства среди прочего обмена данными не мешая основной работе устройства.

Приём идёт в ОЗУ (так как если шить сразу во вторую половину флеши контроллера, то надо запрещать прерывания надолго, а это помешает работе основной программы).

По завершении приёма и проверки валидности прошивки, новая прошивка переписывается во вторую половину флеш контроллера и во флеш выставляется флаг требования обновления прошивки,

после чего делается RESET процу.

Стартует загрузчик, который обнаружив флаг и проверив CRC прошивки во второй половине, перешивает прошивку из второй половины флеш в первую, далее - удаляет флаг и стартует рабочее ПО из первой

половины флеш. Если загрузчик флаг не обнаруживает - значит не надо обновлять прошивку и просто передаёт управление рабочему ПО в первую половину прошивки.

 

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

обновления ПО.

Если в устройстве есть внешняя энергонезависимая память (SPI-флеш к примеру), то можно обойтись без хранения принимаемой прошивки во второй половине флеш контроллера и хранить её в этой памяти.

 

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

Расположите с помощью компоновщика команду перехода на _c_int00 (точку входа в С-программу) с самого начала образа прошивки и передавайте управление на первый адрес прошивки.

 

 

Обработчики прерываний описываютсся одинаково везде.

Неправда :)