8-900-374-94-44
В микроконтроллерах STM32 существуют три интерфейса для заливки прошивки:
Как вы уже догадались, в этой статье пойдет речь о последнем способе. Я считаю его не самым лучшим вариантом для постоянного использования, однако в некоторых случаях он очень даже хорош. Вот допустим устройство уже готово и работает у пользователя, и вдруг ВНЕЗАПНО возникает потребность в перепрошивке. Конечно, можно разобрать девайс и подпаяться к отладочному интерфейсу, но это относительно сложно + нужен отладчик. А что если устройство уже соединено с компом через UART ? В этом случае гораздо проще использовать этот интерфейс для загрузки прошивки. Вот тут-то загрузчик будет очень кстати. Пользователю достаточно нажать одну кнопку и девайс входит в режим прошивки. Пару нажатий мышки и прошивка обновлена. Теперь попробуем разобраться более детально как все это работает. Для начала нам нужно подключить наш контроллер к компьютеру через интерфейс USART1.
Для управления загрузкой контроллера существуют два вывода BOOT1 и BOOT0. В зависимости комбинаций логических уровней на них, контроллер при включении питания начнет выполнять код из разных областей памяти. Это видно из таблицы ниже:
| BOOT1 | BOOT0 | Что запускается |
| Х | 0 | Программа прошитая во FLASH |
| 0 | 1 | Загрузчик |
| 1 | 1 | Программа из SRAM |
Как вы помните из недавней статьи, загрузчик сидит в области памяти под названием Sytem Memory. Каким либо образом изменить его нельзя. Это делает контроллер не убиваемым в плане софта, даже если перепрошивку неожиданно прервут — девайсу ничего не грозит. Всегда можно будет начать прошивку заново. С другими пунктами таблицы все просто: первая комбинация означает, что контроллер будет запускать прошивку которую в него прошили, а последняя комбинация — означает, что контроллер будет выполнять код из ОЗУ который еще как-то туда надо поместить. Пока не совсем понимаю для чего это нужно, разве что программа выполняется быстрей (если верить интернетам). Вернемся к загрузчику. Чтоб ввести наш контроллер в режим прошивки, удерживаем кнопку BOOT и жмем RESET. После этого кнопку можно отпустить. Для прошивки используется специальный софт который называется Flash Loader Demonstrator. Вы можете скачать его на сайте ST или у меня. Процедура прошивки проста до безобразия: Достаточно лишь следовать указаниям мастера. На первом шаге нас попросят выбрать номер ком порта к которому подключен контроллер и указать настройки соединения. Что примечательно у загрузчика есть автодетект скорости. Это значит что можно свободно выбрать любую скорость из списка и оно заработает. Лишь бы ваш адаптер RS232 — UART (или USB-UART) её поддерживал. Мой преобразователь на CP2102 о котором я вкратце уже рассказывал, отлично работает на всех скоростях. Однако, нужно иметь в виду, что загрузчик настраивает контроллер на тактирование от внутреннего генератора. А его частота сильно плавает в зависимости от напряжения питания и температуры. Следовательно если у вас проблемы со стабильностью этих двух параметров, то лучше выбирать маленькую скорость.
Если соединение с контроллером установлено, то программа нарисует нам окно в котором покажет сколько памяти у программирования контроллера и включена ли защита памяти от чтения. Если контроллер защищен от считывания прошивки, то вы можете снять защиту, но при этом содержимое флеш памяти будет уничтожено. Это делается кнопкой «Remove protection» которая у меня не доступна т.к. защита памяти не включена.
Следующий шаг мастера показывает какие страницы flash памяти защищены от записи/чтения. Нужно не забыть выбрать объем памяти которым обладает программируемый контроллер. Кажется там есть автодетект который сам сделает правильный выбор, но я не уверен. У моего контроллера есть 128 кБайт памяти, что я и выбрал:
Самый интересный шаг мастера. На нем мы можем выбрать то, что хотим сделать с контроллером. Можем очистить память контроллера. Как всю, так и некоторые страницы. Само собой можно прошить контроллер. Программировать и очищать память можно только если это не было запрещено. Есть возможность проверить содержимое памяти после прошивки. Или можно сразу начать выполнение прошитой программы. Чтение памяти возможно опять таки если это не запрещено. Снять или установить защиту от записи/чтения можно в этом же окне. Еще можно редактировать «Option bytes». Что это такое я пока особо не разбирался, поэтому ничего вразумительного сказать не могу.
После нажатия кнопки Next выполняется выбранное действие. Результат выполнения отображается на последнем шаге мастера. Если всё хорошо, то вы увидите сообщение похожее на это:
Когда работа с загрузчиком завершена нужно перезагрузить контроллер нажатием на RESET. Если кто-то хочет подробнее узнать о протоколе который используется загрузчиком, то можно почитать аппноут AN3315. Возможно, окажется полезным и аппноут AN2606. Если остались вопросы касаемо загрузчика — спрашивайте, попробую ответить.
easystm32.ru
Отмазки
Статья про небольшое схемотехническое решение, сделанное по принципу «собрать из того что уже есть». Так что строго прошу не судить. Ну к сути.
Суть
Как уже указал выше, сделать надо было всё максимально дёшево, и и того что можно достать в ближайших радиодеталях. И тогда родилась вот эта схема:
Немножко о том, как это работает:
Контроллер после подачи питания (после нажатия RESET) первым делом смотрит на ножки BOOT, для того что бы понять, откуда ему грузится. Делает он это довольно быстро, и уже после того как решение о том, откуда грузится принято — состояние ножек BOOT может быть абсолютно любое. Значит из этого и будем исходить.
Достоинством схемы является то, что теперь мелкие партии девайсов можно отдать прошивать любому человеку, который умеет кликать мышкой. Ибо запустив перед ним DfuSeDemo, и сказав «подключи USB к девайсу, нажми на нём кнопку, нажми кнопку „прошить“ в программе DfuSeDemo» можно оставить его работать без присмотра. Никаких теряющихся джамперов и так далее. А так же можно удалённо помочь заказчику, в том случае если настал «магический пипец» и ничего не работает, попросив его только подключить девайс к компьютеру и нажать на кнопку. Дальше прошивку можно сделать по удалённому доступу.
Явным недостатком является то, что выходить из bootloader’а эта кнопка не позволяет. Так что после прошивки надо выключить и включить девайс (вынуть и вставить USB кабель). Но с этим мы решили смирится.
Ещё отмазки
Есть варианты решений, что бы кнопка работала и как выход из bootloader’а, например добавив логический элемент, или как подсказал уважаемый SiberK , поставить резюк после диода, тогда время нажатия кнопки будет влиять на то, просто ли ребутнётся МК или перепрыгнет в загрузчик. Но нам это было не надо.
we.easyelectronics.ru
Загрузчик сидит в области памяти под названием Sytem Memory. Каким либо образом изменить его нельзя. Это делает контроллер не убиваемым в плане софта, даже если процесс обращения к устройству неожиданно прервут — микроконтроллеру ничего не грозит. Всегда можно будет начать прошивку заново. Чтобы ввести наш контроллер в режим прошивки, удерживаем кнопку PROG и жмем RESET. После этого кнопку можно отпустить. Для прошивки используется специальный софт который называется Flash Loader Demonstrator .Вы можете скачать его на сайте ST. Запускаем эту программу, после устанавливаем номер используемого порта, который должен быть в пределах от 1 до 99, остальные настройки не трогаем. Затем нажимаем обе кнопки, указанные на рисунке, после этого отпускаем RESET и сразу же жмем на NEXT в окне программы («cразу же» это тот период времени который указан в окошке Timeout ) и входим в следующее меню программы.
golf2109.blogspot.com
Готовую программу надо каким-либо образом запихать в контроллер. Для этого существует множество способов.
JTAG/SWD адаптер
Так как часто для отладки под ARM используется JTAG, то этот метод получается наверное самым популярным. Для этой цели используется какой-либо адаптер. Например я использую CoLinkEX так что показывать буду на его примере. Там все просто — подключаешь адаптер к контроллеру стандартным SWD или JTAG шлейфом. Через линии NRST/TDI/TDO/TCK/TMS для JTAG или через SWO/SWOCLK/SWDIO/NRST для SWD режима. На адаптере моей верси CoLinkEX оба эти разьема выведены на одну колодку, так что получается как бы сразу и JTAG и SWD соединение. А там какое надо такое и выбираешь. Особой разницы в отладке/прошивке между ними нет.
 |
И прошиваешь либо из среды Keil.
 |
Либо используя утилитку CoFlash oт CooCox.com
 |
Выбираем тип контроллера, размер памяти.
А дальше надо только указать бинарный или Hex файл и нажать прошивку.
Чтобы Keil сгенерировал hex файл нужно выставить галочку в опциях проекта.
 |
А чтобы получить bin файл прогнать выходной axf файл через специальную утилитку fromelf входящую в состав Keil. Проще всего вписать это сразу в постобработку:
 |
Формат там такой:
fromelf --bin --output .\имя_будущего_файла.bin .\имя_создаваемого_файла.axf |
fromelf —bin —output .\имя_будущего_файла.bin .\имя_создаваемого_файла.axf
Ну или, если выходные файлы создаются в какой-либо подпапке, то путь будет включать и эту подпапку
Первичный Bootloader
Если нет JTAG/SWD адаптера, то не беда. Достаточно иметь переходник USB-UART или COM-UART так как почти все ARM контроллеры содержат в памяти аппаратно встроенный бутлоадер, позволяющий накатить прошивку. Главное следить за тем, чтобы напряжение на выходе с адаптера совпадало с напряжением питания контроллера, а то можно пожечь входы (FTDI можно запитать от 3.3 вольт. А для работы с RS232 использвоать не MAX232, а MAX3232 — то же самое, но на 3.3 вольта). Я в качестве USB-UART использую свою демоплату Pinboard с джампером питания выставленным на 3.3 вольта. Питание беру с той же платы.
Вход Boot_0 выставыляю в 1, вход Boot_1 выставляю в 0. Набрасываю на RX1 и TX1 контроллера STM32F103C8 проводочки от RX-TX микрохсемы FTDI
Готово — можно шить. Для прошивки в STM32 используется программка Flash Loader Demonstrator v2.2.0 от STM запускаем ее:
 |
Настраиваем порт, жмем Next
 |
Она сразу показывает, что есть контроллер.
 |
Тут можно посмотреть какие страницы флеша нам доступны на запись. Жмем Next
 |
Выбираем какую операцию будем делать. Для прошивки надо выбрать Download и не забыть галочку Стереть чип.
Жмем Next и пошел процесс прошивки-проверки
 |
Для LPC от NXP используется другая утилитка, зовется она Flash Magic — те же яйца, вид сбоку. Разве что может быть для входа в загрузчик надо другие выводы коротить. Это надо в User Manual на LPC уточнять уже.
Mass Storage USB Bootloader
Кроме того, у LPC1343 (у других LPC не встречал) есть одна прикольня фича. Там встроенный загрузчик может работать и по USB. Для этого надо собрать следующую схему:
 |
Еще нужно вывод PIO001 подтянуть резистором на 10кОм к 3.3 вольтам питания и вывести на джампер, который бы его коротил в землю. Это будет условия входа в бутлоадер. После чего замыкается джампер входа в бут и девайс втыкается в USB. Винда его быстро определяет как сьемный диск объемом в 32Кб, на котором лежит файл firmware.bin если его скопировать — то мы получим юзерскую прошивку, что была там ранее. Это если не включена защита.
 |
В противном случае мы, наверное, считаем мусор. А если удалить файл firmware.bin и на ее место записать файл с бинариком новой прошивки, то он вольется во флеш. Усе, не надо больше ничего! Красота! Правда в линухе оно работает не так как надо, дело в том, что линух пишет туда начиная со второго чтоль сектора и в результате Epic Fail. Впрочем, там же есть замечательная утилитка dd которая может скопировать на эту «флешку» файл в точности как надо, с нулевого адреса.
Вторичный бутлоадер
Поскольку я решил зарыться в STM32, то мне тоже захотелось такую вкусняшку как USB boot в режиме mass storage. Забросил идею Владимиру aka RtxOnAir и в результате он, за пару дней, выдал аналогичное решение для STM32F103.
Для загрузки с USB нужна следующая схема:
 |
Транзистор подтягивает линию D+ к питанию и это означает, что на шине кто то появился, заставляя OС компа произвести определение устройства. Можно сделать и по колхозному. Подтянуть D+ через резистор напрямую. Но в этом случае для входа в бут придется передергивать шнур USB, иначе винда не захочет находить устройство. А так контроллер сам дернет вожжу.
Штука у Владимира получилась классная — автоматом определяет все типы кристаллов серии F103, позволяет выбрать любую ногу для передергивания USB шиной. Для входа во вторичный бутлоадер надо выводы Boot_0 и Boot_1 посадить на землю и нажать RESET ну или воткнуть девайс в USB если шина у нас не коммутируемая. Также можно выбирать работу от внутреннего генератора или от внешнего.
Вообще, инструкция явно говорит, что USB может работать только от внешнего кварцевого резонатора, т.к. частота внутреннего нестабильная и вообще кака. Не будем спорить с создателями камня, но у нас наш бутлоадер отлично завелся на HSI и при комнатной температуре отлично работал. Впрочем, стабильность тут явно не на высоте и надо быть осторожным.
Конфигурация бутлоадера
Для конфигурации нашего бута RtxOnAir написал небольшую утилитку:
 |
Запустив которую можно выбрать нужные опции и нажав «Ок» получить сконфигурированный бутлоадер, который надо залить в МК любым вышеуказанным способом. Переключив джамперы Boot0 и Boot1 в режим нормальной работы Boot0=0 Boot1=1 и нажав сброс мы должны увидеть как в системе появится новый USB Mass Storage диск с емкостью равным размеру флеш памяти нашего кристалла за вычетом размеров бутлоадера.
Конфигурация проект под вторичный Bootloader
Поскольку этот бутлоадер распологается в области откуда обычно идет пользовательская прошивка, то в создаваемых под него проектах надо немного сконфигурировать опции линковки и компиляции, чтобы они начинались с области не занятой бутом. Для этого в Keil надо в опции проекта подправить начальный адрес:
 |
 |
Ну и прописать строку для формирования бинарика из axf файла.
|
После чего файлы прошивки можно банальным копированием загонять в STM32 и никакой программатор или адаптер больше не нужны совсем. Красота же!
Файло
easyelectronics.ru
Приветствую всех на нашем сайте и сегодня мы после небольшого перерыва вернемся к теме микроконтроллеров. А если быть совсем точным, то мы начинаем обсуждать одну очень интересную и важную тему, а именно использование bootloader’а (загрузчика) при программировании контроллеров. Сегодня мы разберем теоретическую часть – зачем bootloader нужен, как он работает и что это вообще такое. Следующая статья будет посвящена целиком и полностью практике. Забегая вперед скажу, что мы напишем свой bootloader для любимых микроконтроллеров STM32 😉
Итак, простыми словами, bootloader – это специальная программа, которая располагается в памяти микроконтроллера и может самостоятельно перепрограммировать его. Давайте для лучшего понимания процесса посмотрим как вообще выполняется программа, прошитая в микроконтроллер, и где она располагается.
Как вы помните из статьи, посвященной Flash-памяти микроконтроллеров STM32, основная пользовательская программа начинается с первой страницы памяти, а точнее с адреса 0х08000000. То есть при подаче питания контроллер сразу же убегает по этому адресу )
При использовании загрузчика все выглядит несколько иначе. Основная программа записывается уже по другим адресам и располагается начиная, например, с адреса 0х0800A000. А область памяти (0х08000000 – 0х0800А000) целиком и полностью отдается bootloader’у. В итоге в flash-памяти контроллера у нас как бы находятся две полноценные программы. При включении устройства управление получает bootloader (поскольку он находится в области, начинающейся со “стартового” адреса 0х08000000), а при дальнейшей работе bootloader, выполнив все свои задачи передает управление нашей основной программе, которая располагается по адресу 0х0800А000 (этот адрес мы взяли для примера). Вот небольшая схемка для демонстрации работы загрузчика:
Вроде бы понятно как устроено, но возникает вопрос – зачем все это надо?
Давайте разбираться…
Первостепенной задачей bootloader’а является программирование микроконтроллера. Он не просто выполняет какие-то действия, а затем передает управление основной программе (переходит на адрес, который соответствует началу основной программы), он, в первую очередь, самостоятельно записывает эту основную программу в flash-память по нужным адресам.
Давайте разберем небольшой пример для лучшего понимания. Пусть мы создали bootloader (bootloader – точно такой же обычный проект, как и любая другая программа для микроконтроллера), который реализует взаимодействие с внешней картой памяти, ищет на карте файл программы и, если находит, записывает программу в нужную область памяти.
Небольшое отступление от основной темы… Поясню, что я тут имею ввиду под “файлом программы”.
Когда мы создаем проект (Keil, IAR – без разницы), то на выходе (после сборки проекта) мы получаем скомпилированный файл для прошивки в микроконтроллер. Чаще всего мы использовали .hex файл программы. Так вот именно этот файл нам и нужен в данном случае. Но именно hex-файл не совсем подходит для наших целей, поскольку помимо кода нашей программы он несет в себе дополнительную служебную информацию. Чтобы ее не обрабатывать и не вытаскивать из hex-файла нужный нам код, который bootloader должен записать во flash, мы в настройках компилятора во вкладке Output попросим его генерировать нам вместо hex-файла bin-файл. Бинарник, в отличие от hex, содержит в себе только последовательный код программы и ничего больше. То есть bootloader’у остается только читать байты из bin-файла и записывать их во flash-память. То есть в нашем примере задачей загрузчика является чтение байт из файла на карте памяти и запись их по адресам, начиная с 0х0800A000. Вот псевдокод для наглядности:
void main()
{
// Инициализируем интерфейс SDIO для общения с картой памяти
SDIO_Init();
while(1)
{
// Ищем файл прошивки
if (f_open(файл.bin) == FR_OK)
{
ProgramFlash();
JumpToMainProgram();
}
}
} |
Конечно, это сильно упрощенная версия загрузчика 😉 Тут мы в вечном цикле пытаемся открыть файл с программой, как только это нам удается (пользователь записал на карту долгожданный файл) bootloader программирует flash-память и перескакивает на адрес записанной им же программы. После этого контроллер начинает выполнять пользовательскую программу. Еще раз повторю
microtechnics.ru
Некий Владимир с ником RtxOnAir написал прекрасное решение USB boot в режиме mass storage для линейки микроконтроллеров STM32F103.
Для загрузки с USB нужна следующая схема:
Транзистор подтягивает линию D+ к питанию и это означает, что на шине кто то появился, заставляя OС компа произвести определение устройства. Можно сделать и по колхозному. Подтянуть D+ через резистор напрямую. Но в этом случае для входа в boot придется передергивать шнур USB, иначе винда не захочет находить устройство. А так контроллер сам дернет вожжу. Лично я сделал напрямую и особо дискомфорта от этого не получил).
Штука у Владимира получилась классная — автоматом определяет все типы кристаллов серии F103, позволяет выбрать любую ногу для передергивания USB шиной. Для входа во вторичный бутлоадер надо выводы Boot_0 и Boot_1 посадить на землю и нажать RESET ну или воткнуть девайс в USB если шина у нас не коммутируемая. Также можно выбирать работу от внутреннего генератора или от внешнего.
Вообще, инструкция явно говорит, что USB может работать только от внешнего кварцевого резонатора, т.к. частота внутреннего нестабильная и вообще кака. Не будем спорить с создателями камня, но у нас наш бутлоадер отлично завелся на HSI и при комнатной температуре отлично работал. Впрочем, стабильность тут явно не на высоте и надо быть осторожным.
Конфигурация bootloader
Для конфигурации нашего bootloader Владимир написал небольшую утилиту:
Запустив которую можно выбрать нужные опции и нажав «Ок» получить сконфигурированный bootloader, который надо залить в МК . Переключив джамперы Boot0 и Boot1 в режим нормальной работы Boot0=0 Boot1=0 и подключив USB шнурок мы должны увидеть как в системе появится новый USB Mass Storage диск с емкостью равным размеру флеш памяти нашего кристалла за вычетом размеров бутлоадера который равен 8Kb.
Конфигурация проект под вторичный Bootloader в Chibi Studio
Поскольку этот бутлоадер распологается в области откуда обычно идет пользовательская прошивка, то в создаваемых под него проектах надо немного сконфигурировать опции линковки и компиляции, чтобы они начинались с области не занятой бутом. Для этого в Chibi Studio надо подправить начальный адрес в паре файлов:
1) первый STM32F103xB.ld расположен:
C:\ChibiStudio\chibios\os\ports\GCC\ARMCMx\STM32F1xx\ld
и почти в самом начале файла меняем flash : org = 0x08000000, len = 128k на flash : org = 0x08002000, len = 128k
2) второй chcore_v7m.h расположен:
C:\ChibiStudio\chibios\os\ports\GCC\ARMCMx
нам нужно найти #define CORTEX_VTOR_INIT 0x00000000
и заменить на #define CORTEX_VTOR_INIT 0x00002000
И теперь скомпилированные файлы прошивки мы можем заливать обычным копированием в наш mass storage.
Для нормальной работы нашей залитой прошивки джамперы Boot0=0 Boot1=1 нужно установить соответственно и нажать сброс микроконтроллера.
Лично мною было проверен данный бутлоадер на этих двух платках, все прекрасно заработало :).
Скачать утилиту
литература: easyelectronics.ru
blog.myelectronics.com.ua
Вам не нужно ограничивать ОЗУ — вы можете использовать все это, потому что, когда вы переключаетесь на приложение, будет создана новая среда выполнения, и ОЗУ будет повторно использоваться.
Вспышка, которую вы резервируете для загрузчика, должна быть целым числом флэш-страниц, начиная с адреса сброса. STM32L0 имеет очень маленькие флеш-страницы, поэтому минимальные потери должны быть минимальными, но вы не хотите менять его, если ваш загрузчик растет, потому что тогда вам придется перестроить свой код приложения для нового стартового адреса, а старые изображения приложений больше не будут загружаться. Поэтому подумайте о том, чтобы немного отдохнуть.
Загрузочный загрузчик может быть построен так же, как и любой другой проект STM32L0xx; конфигурация ПЗУ кода приложения должна начинаться с адреса выше загрузчика. Например, скажем, у вас есть 1-килобайтный загрузчик:
Boot ROM Start: 0x0800 0000
Boot ROM End: 0x0800 03FF
Application Start: 0x0800 0400
Application End: Part size dependent.
Сам загрузчик должен иметь возможность определить, что обновление доступно, если доступно обновление, он должен затем прочитать данные приложения и записать его в флэш-память приложения, он должен затем отключить любые прерывания, которые могут быть включены, это может также необходимо деинициализировать любые используемые периферийные устройства (если они остаются активными при переходе к приложению, это может вызвать проблемы), то выполняется переход на код приложения.
Возможно, если загрузчик и приложение работают от одной и той же конфигурации часов, чтобы минимизировать конфигурацию в приложении и полагаться на загрузчик. Это небольшая экономия пространства, но менее гибкая. Если, например, вы запускаете загрузчик с использованием внутреннего RC-генератора, он будет переноситься по нескольким аппаратным схемам, которые могут иметь различную скорость приложения и требования к синхронизации и различные частоты внешнего генератора
Переключение на приложение довольно простое на Cortex-M, просто требуется, чтобы векторная таблица была переключена на таблицу векторов приложений, затем загружался программный счетчик — последний требует небольшого кода сборки. Ниже для Cortex-M3 может потребоваться адаптация для M0+, но, возможно, нет:
Учитывая следующую встроенную функцию сборки:
__asm void boot_jump( uint32_t address )
{
LDR SP, [R0] ;Load new stack pointer address
LDR PC, [R0, #4] ;Load new program counter address
}
Загрузочный загрузчик переключился на изображение приложения таким образом:
// Switch off core clock before switching vector table
SysTick->CTRL = 0 ;
// Switch off any other enabled interrupts too
...
// Switch vector table
SCB->VTOR = APPLICATION_START_ADDR ;
//Jump to start address
boot_jump( APPLICATION_START_ADDR ) ;
Где APPLICATION_START_ADDR — базовый адрес области приложения; этот адрес является началом таблицы векторов приложений, которая начинается с указателя начального стека и вектора сброса, boot_jump() загружает их в регистры SP и ПК, чтобы запустить приложение, как если бы оно было запущено при сбросе. Вектор сброса приложения содержит начальный адрес выполнения приложения.
Ваши потребности могут отличаться, но по моему опыту последовательный загрузчик (используя UART) с использованием XMODEM и декодирование изображения в формате Intel Hex занимает около 4 Кбайт Flash. На STM32L0 вы можете использовать что-то более простое — 1Kb, вероятно, возможно, если вы просто передаете необработанные двоичные данные и используете аппаратное управление потоком (вам нужно управлять потоком данных, потому что стирание и программирование вспышки требует времени, а также останавливает запуск ЦП потому что вы не можете записывать флэш-память STM32, одновременно получая инструкции от нее).
См. Также: Как прыгать между программами в Стелларисе
qaru.site