8-900-374-94-44
Здравствуйте! Меня зовут Дмитрий Руднев. В этой публикации я поделюсь своим горьким опытом.
В современной разработке широко используются микроконтроллеры STM32. Они обладают неплохим соотношением цена/производительность, вокруг них сложилась развитая «экосистема». Для прошивки этих микроконтроллеров и внутрисхемной отладки обычно используют интерфейс Serial Wire (SWD).
В процессе отладки бывает всякое. Не беда, если STM32 после прошивки ведёт себя неадекватно. Обидно, если при этом к нему не удаётся подключиться.
На этом месте не надо впадать в отчаяние, т.к. «убить насмерть» STM32 в процессе программирования непросто, и его работоспособность можно восстановить штатными средствами.
После аппаратного сброса микроконтроллер первым делом запускает системный загрузчик. Системный загрузчик проверяет состояние входов BOOT0 и BOOT1 и по их состоянию определяет режим дальнейшей загрузки.
Если на входе BOOT0 обнаружен низкий уровень, системный загрузчик передаёт управление пользовательской программе, находящейся в FLASH-памяти. Если при этом к интерфейсу SWD подключен в режиме «Connect Under Reset» внутрисхемный отладчик, ему удаётся управление перехватить.
Рассмотрим, как это сделать с помощью программы STM32 ST-LINK Utility и программатора ST-LINK/V2-1. Программа была получена с официального сайта ST. Программатор пришёл в составе платы NUCLEO-F446ZE.
Запускаем программу, входим в «Settings»:
В окне «Settings» выбираем режим «Connect Under Reset»:
Подключаемся к нашему «кирпичику»:
Производим очистку памяти программ:
Очень часто для прошивки STM32 применяются недорогие китайские клоны ST-LINK/V2.
Без аппаратной переделки режим «Connect Under Reset» они не поддерживают. В этом случае стоит попытаться очистить память программ, подключившись к микроконтроллеру по UART.
Если подать на вход BOOT0 высокий уровень, то можно подключиться к микроконтроллеру через интерфейс UART1 с использованием программы Flash Loader Demonstrator. Программу можно получить с официального сайта ST. Преобразователь USB–UART подойдёт любой.
Запускаем программу. Выбираем COM-порт, к которому подключен преобразователь USB–UART:
На следующем экране программа показывает области памяти микроконтроллера:
На следующем экране мы должны выбрать действие. Выбираем Erase – All:
Очистка памяти программ успешно завершена:
На этом месте надо вернуть на вход BOOT0 низкий уровень.
Любое несчастье, которое происходит с Вами, с кем-то другим уже происходило. Всё, что описано в публикации, происходило со мной и моим оборудованием.
Первая часть публикации повествует о том, как я в самом начале самоизоляции «закирпичил» новенькую оригинальную NUCLEO-F446ZE.
Это не стало для меня ударом, т.к. я уже знал, что делать. Наоборот, в процессе восстановления работоспособности платы я даже получил какое-то удовольствие от работы.
Предыдущий опыт был более трагичным. Я использовал совсем бюджетную плату в связке с очень недорогим клоном ST-LINK/V2. В один прекрасный миг, связь с платой по SWD пропала.
Результаты поиска в сети убедили меня использовать режим «Connect Under Reset». Ничтоже сумняшеся, я подключил вывод NRST микроконтроллера к выводу «Reset» программатора. Не знал я тогда, что этот вывод используется только при работе с STM8.
Сигнал сброса не проходил. Связь по интерфейсу SWD не восстанавливалась. Игры с кнопкой «Reset» на плате результата не давали. В самый раз было начинать читать мануалы.
И метод RTFM сработал! Из раздела «2.3.10 Boot modes» datasheet DS5792 rev13
Буду рад, если мой опыт будет кому-то полезен!
Введение
На Blue Pill STM32F103C8T6 есть Micro USB разъем. Для чего он нужен? Можно ли через него прошивать данный контроллер?
В абсолютно новой BluePill через разъем Micro USB можно только подавать питание. Прошивание чистого микроконтроллера возможно только такими способами:
V1-V2 / JLINK подключаемый к четырехонтактному разъему SWD Interface,Однако, если через SWD-интерфейс или через UART-интерфейс залить в STM32 специальный бутлоадер, то появляется возможность в дальнейшем заливать прошивку через Micro-USB разъем с помощью обычного USB-кабеля. Такой тип соединения называется USB DFU-интерфейсом (Universal Serial Bus Device Firmware Upgrade — обновление микропрограммы устройства по универсальной последовательной шине).
Примечание для неискушенных читателей. Далее по ходу повествования будет встречаться упоминание Arduino, да и сама прошивка будет содержать строки XXXXXduino, однако это не значит, что для работы с STM32 нужна среда Arduino IDE или что-то Adruino-специфическое. Все действия, которые описаны в данной статье, к Arduino не имеют отношения, все используемое ПО входит в состав любого современного дистрибутива, например Debian Linux 11.
Общие сведения о памяти и механизмах прошивки
В плате STM32F103C8T6 имеется 3 вида памяти:
На плате есть две перемычки BOOT0 и BOOT1. В зависимости от их положения, запуск контроллера после сброса или подачи питания будет отличаться. Далее предполагается, что плата расположена так же, как показано на рисунке выше.
Если перемычки стоят так (Boot0=0, Boot1=0):
boot0 [o-o]o
boot1 [o-o]o
— тогда контроллер будет запускать программу из FLASH-памяти.
Если перемычки стоят так (Boot0=1, Boot1=0):
boot0 o[o-o]
boot1 [o-o]o
— тогда будет запускаться системный загрузчик из ROM-памяти (еще его называют системным бутлоадером), который будет ожидать поступления сигналов по UART-интерфейсу для прошивки FLASH-памяти контроллера.
Если перемычки стоят так (Boot0=1, Boot1=1):
boot0 o[o-o]
boot1 o[o-o]
— тогда после сброса будет запускаться программа из ОЗУ. Предполагается, что напряжение питания на контроллер все время подается, в ОЗУ размещен код для выполнения, для перезапуска нажимается кнопка Reset.
Четвертый вариант расположения перемычек, согласно официальному даташиту, не используется.
Прошивка FLASH через SWD-интерфейс возможна в любой момент, и положение boot-перемычек роли не играет. Но обычно для этих целей выставяют «нуливое» положение джамперов Boot0=0, Boot1=0.
Перед тем, как экспериментировать
В процессе работы с платой STM32F103C8T6, например, после заливки на нее DFU-бутлоадера, плата может начать определяться через STLinkV2 по SWD-интерфейсу совершенно по-другому. У нее даже может измениться chipid и другие характеристики.
Например, на новой плате команда st-info —probe показывает:
Found 1 stlink programmers
serial: 132014026315303030303032
openocd: «\x13\x20\x14\x02\x63\x15\x30\x30\x30\x30\x30\x32»
flash: 65536 (pagesize: 1024)
sram: 20480
chipid: 0x0410
descr: F1 Medium-density device
А после прошивки и сброса информация о плате по SWD-интерфейсу уже другая:
Found 1 stlink programmers
serial: 132014026315303030303032
hla-serial: «\x13\x20\x14\x02\x63\x15\x30\x30\x30\x30\x30\x32»
flash: 0 (pagesize: 0)
sram: 0
chipid: 0x0748
И попытка снова прошить устройство через SWD может завершиться ошибкой:
st-flash 1.
6.1
2022-04-09T18:22:35 WARN common.c: unknown chip id! 0x3748
Failed to connect to target
Да, тут еще какая-то дичь происходит с id. Утилита st-flash видит id 0x3748, а утилита st-info видит id 0x0748.
В любом случае, если DFU-загрузчик не нужен, необходимо сбросить устройство — то есть очистить устройство от DFU-загрузчика. Для этого надо установить перемычки boot в положение Boot0=1, Boot1=0:
boot0 o[o-o]
boot1 [o-o]o
После чего нужно нужно выполнить команду:
st-flash erase
И снова поставить перемычки в нуливое положение Boot0=0, Boot1=0.
На некоторых платах, чтобы сработало стирание FLASH, перемычки надо поставить в недокументированное положение Boot0=0, Boot1=1:
boot0 [o-o]o
boot1 o[o-o]
И чтобы chipid сменился на допустимый, надо нажать и удерживать кнопочку Reset, и в таком положении дать команду стирания flash, а потом (все еще не отпуская Reset!), дать команду записи бинарника какой-нибудь программы st-flash —reset write <имя программы>.
Другими словами: если не нажимать кнопку Reset, chipid может быть равен 0x0748, что не соответствует ни одному известному девайсу. Если же нажать и удерживать Reset, и дать команду st-info —probe, то плата покажет нормальный chipid 0x0410, а значит флешер сможет прошить или обнулить FLASH-память платы.
Пример, как делается сброс при смене chipid, обсуждался здесь:
https://electronix.ru/forum/index.php?app=forums&module=forums&controller=topic&id=166052
В общем, необходимо знать, что иногда надо будет делать сброс платы, и что потребуется небольшая пляска с бубном, но в конечном итоге все получится.
Загрузка DFU-загрузчика во FLASH-память
DFU-загрузчик размещается FLASH-памяти, как обычная программа. Заливка DFU-загрузчика происходит либо через SWD-интерфейс (с помощью программатора STLink / JLINK), либо через UART-интерфейс (с перетыканием перемычки boot0 на 1 а после прошивки обратно на 0).
То есть, заливка DFU-загрузчика ничем не отличается от заливки на устройство обычной прошивки (программы) из bin/elf файла.
DFU-загрузчиков существует множество, например можно взять готовый бинарник из репозитария на GitHub:
https://github.com/rogerclarkmelbourne/STM32duino-bootloader/tree/master/bootloader_only_binaries
Для Blue Pill подойдет загрузчик generic_boot20_pc13.bin. Возможно, что можно будет пользоваться загрузчиком generic_boot20_pc13_fastboot.bin, хотя чем они отличаются и что такое fastboot не совсем понятно, в описании проекта это не объясняется. Суффикс _pc13 говорит о том, что подтверждение передачи данных будет дублироваться на светодиод, подключенный к PC13.
Через SWD-интерфейс загрузчик можно прошить командой:
st-flash —reset write generic_boot20_pc13.bin 0x08000000
Через другие флешеры загрузчик так же просто записыватся, начиная со стандартного адреса 0x08000000.
Если процедура заливки проходит с ошибками, возможно что утилита st-flash из пакета программ stlink имеет устаревшую версию и не знает подключенной платы, либо плата является китайской репликой.
Например, пакет программ stlink v.1.5.1 не знает китайских STM32F103C8T6, выпущенных в 2021 году, а версия 1.6.1 уже может их шить.
При удачной заливке DFU-бутлоадера вывод будет примерно таким:
st-flash 1.6.1
2022-04-08T22:10:25 INFO common.c: F1xx Medium-density: 20 KiB SRAM, 64 KiB flash in at least 1 KiB pages.
file generic_boot20_pc13.bin md5 checksum: 333c30605e739ce9bedee5999fdaf81b, stlink checksum: 0x0008e534
2022-04-08T22:10:25 INFO common.c: Attempting to write 7172 (0x1c04) bytes to stm32 address: 134217728 (0x8000000)
2022-04-08T22:10:25 INFO common.c: Flash page at addr: 0x08000000 erased
2022-04-08T22:10:25 INFO common.c: Flash page at addr: 0x08000400 erased
2022-04-08T22:10:25 INFO common.c: Flash page at addr: 0x08000800 erased
…
2022-04-10T00:20:26 INFO common.c: Flash page at addr: 0x08001400 erased
2022-04-10T00:20:26 INFO common.c: Flash page at addr: 0x08001800 erased
2022-04-10T00:20:26 INFO common.
c: Flash page at addr: 0x08001c00 erased
2022-04-08T22:10:25 INFO common.c: Finished erasing 8 pages of 1024 (0x400) bytes
2022-04-08T22:10:25 INFO common.c: Starting Flash write for VL/F0/F3/F1_XL core id
2022-04-08T22:10:25 INFO flash_loader.c: Successfully loaded flash loader in sram
8/8 pages written
2022-04-08T22:10:26 INFO common.c: Starting verification of write complete
2022-04-08T22:10:26 INFO common.c: Flash written and verified! jolly good!
Адрес последней страницы 0x08001c00 из данного лога очень важен. В дальнейшем его нужно будет использовать для расчета стартового адреса прошиваемой программы, ведь теперь программу нельзя будет заливать по стандартному адресу 0x08000000, так как начиная с него теперь находится DFU-загрузчик.
Проверка наличия DFU-протокола
После того, как DFU-загрузчик размещен в FLASH-памяти устройства, SWD-интерфейс или UART-интерфейс можно отключить.
Используемый в данной статье DFU-бутлоадер работает следующим образом:
Обычно это адрес 0x8002000 или 0x8005000 (подробности, какой адрес конктретно — далее). Назовем такой режим режимом старта программы.Таким образом, для работы DFU-загрузчика в режиме прошивания DFU, надо поставить перемычки в недокументированное положение Boot0=0 Boot1=1. Делать это нужно, естественно, при отключенном питании.
Примечание. Подробнее о недокументированном положении джамперов написано в закрытом issue данного проекта:
https://github.com/rogerclarkmelbourne/STM32duino-bootloader/issues/90
If a button pin is high (e. g. button pressed) at startup, the bootloader also waits for an upload indefinitely (even for fastboot). This can be used to force bootloader mode, even when the main application is broken and fastboot is enabled. The «button» pin varies per config (see config.h), but the led-on-PC13 variant that is typically used for the Blue Pill boards ahs the «button» pin configured to PB2, aka BOOT1, which is available on a pin header. The BOOT1 pin is normally used by the hardware to decide between system flash and RAM, but only when BOOT0 is 1. When BOOT0 is 0, it always boots from main flash, ignoring the value of BOOT1, so it can be used by the bootloader.
Однако эта информация почему-то не попала на страницу описания DFU-загрузчика, а документации у такого open source проекта традиционно, не существует.
После правильной установки boot-перемычек, надо вставить в плату micro-USB кабель, а другой конец воткнуть в USB-гнездо компьютера.
Далее обязательно надо нажать кнопку Reset. Некоторые платы требуют перетыкания кабеля в USB-гнезде компьютера, причем делать это надо несколько раз. И Reset тоже, возможно, придется нажимать несколько раз. То есть, включение нестабильно, но если уж включилось, то работает.
Как определить, включился ли режим прошивания DFU? В этом поможет вывод команды dmesg (данная команда работает только под рутом).
Если плата переведена в режим прошивания DFU, то вывод dmesg должен быть следующим:
[ 4304.984940] usb 2-2: new full-speed USB device number 35 using xhci_hcd
[ 4305.133726] usb 2-2: New USB device found, idVendor=1eaf, idProduct=0003, bcdDevice= 2.01
[ 4305.133733] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 4305.133735] usb 2-2: Product: Maple 003
[ 4305.133738] usb 2-2: Manufacturer: LeafLabs
[ 4305.133739] usb 2-2: SerialNumber: LLM 003
Совокупность параметров:
idVendor=1eaf
idProduct=0003
Product: Maple 003
говорит о том, что плата находится в режиме прошивания DFU. В этом режиме DFU-бутлоадер ждет, что компьютер отправит прошивку по USB-кабелю, после чего он запишет ее во FLASH память.
Если плата не переведена в режим прошивания DFU, значит плата после включения начинает выполнять загруженную программу (если таковая вообще есть). И если загруженная программа сама по себе не создает USB-устройства, тогда в выводе dmesg не будет ни одного нового USB-устроства:
[27417.076144] usb 2-2: new full-speed USB device number 8 using xhci_hcd
[27417.204164] usb 2-2: device descriptor read/64, error -71
[27417.440105] usb 2-2: device descriptor read/64, error -71
[27417.684096] usb 2-2: new full-speed USB device number 9 using xhci_hcd
[27417.812155] usb 2-2: device descriptor read/64, error -71
[27418.052119] usb 2-2: device descriptor read/64, error -71
[27418.164136] usb usb2-port2: attempt power cycle
[27418.576146] usb 2-2: new full-speed USB device number 10 using xhci_hcd
[27418.576315] usb 2-2: Device not responding to setup address.
[27418.784283] usb 2-2: Device not responding to setup address.
[27418.992097] usb 2-2: device not accepting address 10, error -71
[27419.120072] usb 2-2: new full-speed USB device number 11 using xhci_hcd
[27419.120266] usb 2-2: Device not responding to setup address.
[27419.328229] usb 2-2: Device not responding to setup address.
[27419.536044] usb 2-2: device not accepting address 11, error -71
[27419.536153] usb usb2-port2: unable to enumerate USB device
Внимание! Существуют программы, которые сами по себе создают USB-устройства. Например, в программе может быть создана эмуляция USB COM порта. В этом случае, если плата не переведена в режим прошивания DFU, значит DFU-загрузчик просто запустит программу. И на USB-шине будет присутсвовать USB-устройство виртуального COM-порта. Выглядеть в dmesg такое устройство может так:
[25760.232130] usb 2-2: new full-speed USB device number 7 using xhci_hcd
[25760.385437] usb 2-2: New USB device found, idVendor=1eaf, idProduct=0004, bcdDevice= 2. 00
[25760.385444] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[25760.385447] usb 2-2: Product: Maple
[25760.385449] usb 2-2: Manufacturer: LeafLabs
[25760.424009] cdc_acm 2-2:1.0: ttyACM0: USB ACM device
[25760.424307] usbcore: registered new interface driver cdc_acm
[25760.424310] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters
Выглядит немного похоже на режим прошивания DFU. Однако совокупность параметров другая:
idVendor=1eaf
idProduct=0004
Product: Maple
И кроме того, видно символьное устройство виртуального USB COM порта ttyACM0, и присутствует описание «USB Abstract Control Model driver for USB modems and ISDN adapters».
Работа с утилитой dfu-util
В предыдущем разделе плата переключилась в режим прошивания DFU, а значит можно двигаться дальше.
Для работы по DFU-протоколу понадобится пакет dfu-util. Он входит в основные репозитарии Linux. В Debian Linux 11 доступент пакет dfu-util версии 0. 9. После установки данного пакета, станут доступны следующие исполняемые файлы:
Если же на компьютере установлена среда Arduino IDE, то эти бинарники можно вытащить из каталога:
/home/<user>/.arduino15/packages/STM32/tools/STM32Tools/1.4.0/tools/linux/dfu-util
Естественно, данные бинарники будут доступны только если в среде Arduino IDE устанавливались плагины для работы с контроллерами STM32.
Далее надо проверить, как видится DFU-устройство в утилите dfu-util. Для этого надо выполнить команду:
dfu-util —list
В случае, если dfu-util выводит только информацию о копирайтах и никакого списка не выдает, значит DFU-режим не включился:
dfu-util 0.9
Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge. net/p/dfu-util/tickets/
В этом случае надо возвращаться к предыдущему разделу и разбираться что не так.
Если dfu-util —list вместо списка показывает строку:
dfu-util: Cannot open DFU device 1eaf:0003
то это хорошо, значит устройство увиделось, но к нему нет полного доступа. Вроде как при установке пакета dfu-util прописываются настройки DBUS для доступа всех пользователей, но если это не так, то нужно попробовать запустить dfu-util просто из-под рута.
При запуске команды из-под рута можно наконец-то увидеть список DFU-устройств:
Found DFU: [1eaf:0003] ver=0201, devnum=35, cfg=1, intf=0, path=»2-2″, alt=2,
name=»STM32duino bootloader v1.0 Upload to Flash 0x8002000″,
serial=»LLM 003″
Found DFU: [1eaf:0003] ver=0201, devnum=35, cfg=1, intf=0, path=»2-2″, alt=1,
name=»UNKNOWN»,
serial=»LLM 003″
Found DFU: [1eaf:0003] ver=0201, devnum=35, cfg=1, intf=0, path=»2-2″, alt=0,
name=»STM32duino bootloader v1. 0 ERROR. Upload to RAM not supported.»,
serial=»LLM 003″
Если долго не трогать устройство в режиме DFU, информация о DFU-устройствах может поменяться:
Found DFU: [1eaf:0003] ver=0201, devnum=35, cfg=1, intf=0, path=»2-2″, alt=2,
name=»STM32duino bootloader v1.0 Upload to Flash 0x8002000″,
serial=»LLM 003″
Found DFU: [1eaf:0003] ver=0201, devnum=35, cfg=1, intf=0, path=»2-2″, alt=1,
name=»STM32duino bootloader v1.0 Upload to Flash 0x8005000″,
serial=»LLM 003″
Found DFU: [1eaf:0003] ver=0201, devnum=35, cfg=1, intf=0, path=»2-2″, alt=0,
name=»UNKNOWN»,
serial=»UNKNOWN»
Здесь видно, что вначале небыло устройства, которое прописывает программу начиная с адреса 0x8005000, а потом оно появляется. А устройство, которое должно поддерживать функционал прошивки в RAM (но не поддерживает), во втором случае становится UNKNOWN.
Однако если еще подождать (более минуты), и снова получить список DFU-устройств, то список может прийти к такому состоянию:
Found DFU: [1eaf:0003] ver=0201, devnum=35, cfg=1, intf=0, path=»2-2″, alt=2,
name=»STM32duino bootloader v1. 0 Upload to Flash 0x8002000″,
serial=»LLM 003″
Found DFU: [1eaf:0003] ver=0201, devnum=35, cfg=1, intf=0, path=»2-2″, alt=1,
name=»STM32duino bootloader v1.0 Upload to Flash 0x8005000″,
serial=»LLM 003″
Found DFU: [1eaf:0003] ver=0201, devnum=35, cfg=1, intf=0, path=»2-2″, alt=0,
name=»STM32duino bootloader v1.0 ERROR. Upload to RAM not supported.»,
serial=»LLM 003″
Вот такое состояние DFU-устройств уже пригодно для прошивки.
Здесь видно, что заливать программу во FLASH можно либо по адресу 0x8002000, либо по адресу 0x8005000. При заливке DFU-бутлоадера было видно, что его код использует 8 страниц FLASH-памяти. Сам код занимает 0x1c04 байт, но так как FLASH записывается постранично, то на самом деле для кода используется 0x2000 байт. Казалось бы, что программу можно размещать, начиная с адреса 0x8002000. Однако возможно, что DFU-бутлоадер использует соседние страницы FLASH для хранения постоянных данных о своем состоянии (ибо EPROM в STM32F103C8T6 отсутсвует). Поэтому, если нет жестких ограничений по памяти, заливать программу стоит через устройство STM32duino bootloader v1.0 Upload to Flash 0x8005000.
Заливка программы через USB-кабель
Прошивка выполняется следующими командами (пока не проверено):
dfu-util -a 1 —dfuse-address 0x08005000 -D programm.bin
В некоторых случаях может потребоваться команда:
dfu-util -a 1 -s 0x08005000 -D programm.bin
где опция -a обозначает номер устройства, который виден в выхлопе dfu-util в поле alt.
Однако, чтобы программа была работоспособной, она должна быть скомпилирована с учетом настандартного стартового адреса.
Дописать…
В прошлый раз мы рассматривали использование интерфейса SWD чипа STM32 ARM. Однако это не единственный способ взаимодействия с этим устройством. Он также содержит последовательный интерфейс на загрузчике, что позволяет нам читать и записывать во флэш-память. Он далеко не такой мощный, как интерфейс SWD.
Этот пример довольно надуманный. Маловероятно, что на таком маленьком устройстве с контактами по краям доступ к SWD будет сложнее, чем к последовательному. И SWD, и последовательный загрузчик можно «заблокировать» с помощью RDP (защита от чтения). Однако мы видели много чипов, в которых разные интерфейсы отладки/программирования применялись с разными уровнями безопасности. Точно так же последовательные порты часто более очевидны или физически доступны, чем JTAG/SWD.
Это просто для того, чтобы научить некоторым принципам чтения спецификаций, чтения схем, перевода устройства в другой режим загрузки и использования различных инструментов.
Загрузчик обычно является первым кодом, который запускается на процессоре. У него есть задача инициализировать оборудование и выполнить прошивку. В сложных системах в устройстве будет постоянно храниться значительный загрузчик ПЗУ для вызова второго загрузчика.
На очень простых микроконтроллерах ARM (таких как Cortex-M0, который мы используем) нет необходимости в чем-либо столь сложном. Процессор просматривает вторую запись в «таблице векторов» (вектор сброса) и выполняет код по этому адресу.
Однако в STM32 загрузчик ПЗУ хранится в так называемой «системной памяти» (STMicroelectronics называет это так, не знаю почему). Используя контакты и параметры прошивки, вы можете выбрать различные режимы загрузки:
Системная память на STM32F030R8 позволяет использовать последовательный интерфейс для связи с устройством. Некоторые другие STM32 поддерживают I2C или USB.
В линейке STM32 нас больше всего интересуют четыре набора документов:
Распиновка будет здесь, а в STM32 карта памяти тоже здесь.Для линейки STM32 большая часть или все документы общедоступны.
Используемая номенклатура и информация, содержащаяся в различных документах, полностью несовместимы в полупроводниковой промышленности.
В спецификации продукта мы видим ссылку на «Режимы загрузки». Информации не очень много.
В справочном руководстве подробно описано, как переходить в различные режимы загрузки. Мы хотим зайти в «системную память». У этой функции есть два входа: бит nBOOT1 и контакт BOOT0.
По умолчанию устройство загружается с флэш-памяти. Следовательно, контакт BOOT0 должен иметь низкий уровень.
Бит nBOOT1 равен «x», что означает «не важно». Нам нужно проверить, что это такое, и нужно ли нам это изменить. Поиск в справочном руководстве для nBOOT1 показывает нам, что это один бит в байте опции.
Значение по умолчанию — 0x00FF55AA — нам нужно выяснить, что такое бит 20. Если вы много работаете с hex, это очевидно, но полезно иметь возможность использовать для этого калькулятор.
Мы можем ввести значение в калькулятор Windows и сразу увидеть двоичное значение.
Теперь мы могли бы мучительно считать биты, но нажав на маленькую кнопку «точки», окно показывает удобный дисплей.
Бит 20 — nBOOT1 — по умолчанию установлен в 1. Это то, что мы хотим!
(у 0x00FF55AA явно установлен 20-й бит, поскольку байт, в котором он находится, равен 0xFF — все 1 с)
Теперь нам нужно решить, как установить контакт BOOT 0.
Для этого мы хотим вернуться к спецификации продукта.
Это четко обозначенный контакт — контакт 60. Небольшой совет — никогда не думайте, что изображения в таблицах данных содержат текст с возможностью поиска! Возможно, вам придется сканировать страницу за страницей.
Мы могли бы использовать мультиметр, чтобы найти, куда идет этот контакт, но это макетная плата — у нас есть схема.
Есть несколько моментов, на которые стоит обратить внимание в отношении схем.
Два желтых прямоугольника — U5A и U5B — относятся к U5 — микроконтроллеру. Он просто разделен на разные части, чтобы упростить понимание документа.
Номера контактов расположены не последовательно. Опять же, они располагаются в любом порядке, облегчающем понимание документа.
Желтые ромбы означают, что сигнал (или группа сигналов) переходит на другую страницу.
BOOT0 — контакт 60 — можно увидеть на U5B. Затем он ведет к R33 — резистору 10K. Это «подтягивающий» резистор, предназначенный для удержания логического уровня на уровне 0, если контакт не подключен непосредственно к высокому уровню.
Куда идет сигнал BOOT0? Он переходит на другую страницу.
Контакт 7 на разъеме CN7 – хорошо! Все, что нам нужно сделать, это подключить это к высокому логическому уровню, и устройство войдет в системную память. Удобно, что сразу над выводом 7 — вывод 5 — это «VDD», это напряжение питания процессора. Мы можем использовать одну из запасных перемычек от CN11 или CN12 (которые являются просто держателями для запасных перемычек), чтобы соединить их.
Это легко проверить — на вашей плате по умолчанию должен работать мигающий светодиод. Установите перемычку и нажмите черную кнопку сброса. Светодиод больше не должен мигать, так как флэш-код не сработает.
В спецификации продукта указано, что доступ к загрузчику можно получить через контакты PA14/PA15 или PA9/PA10. Нам нужны самые доступные.
Назад к схеме. PA14/15 выведены на контакты 15 и 17 CN7 – рядом друг с другом.
У нас есть устройство, запускающееся в загрузчике, и мы знаем, к каким контактам подключаться. Хотя макетная плата имеет встроенный последовательный USB-адаптер, он подключен к USART2 на PA2/PA3. Перенастроить плату не так уж и просто, поэтому мы будем использовать внешний последовательный USB-адаптер.
Вернитесь к сообщению о взаимодействии с последовательными портами, если вы не можете вспомнить, как их использовать. Помните, что TX идет к RX, а RX – к TX.
Программное обеспечение, которое мы будем использовать, называется stm32flash. Да, это SourceForge, и да, SourceForge каким-то образом все еще жив. Загрузите последнюю версию под названием «stm32flash-0.5.tar.gz».
Для его распаковки, сборки и установки необходимо выполнить следующие действия:
tar -zxvf stm32flash-0.5.tar.gz компакт-диск stm32flash делать sudo make install
При включенной плате разработки STM32, перемычке BOOT0 в высоком положении и подключенном последовательном адаптере вы сможете запустить:
sudo stm32flash /dev/ttyUSB0
Это запросит информацию об устройстве. Если это не сработает, попробуйте поменять местами TX и RX.
А теперь, используя другие команды, мы можем читать и записывать flash.
Мы использовали очень похожий прием на чипах серии LPC5460x, у которых может быть отключен SWD/JTAG, но вы можете перевести устройство в режим загрузки через USB, что позволит вам заново прочитать прошивку. USB. Всегда проверяйте спецификации процессора, с которым вы работаете, чтобы обнаружить «скрытые» функции, подобные этой.
спросил
Изменено 2 года, 8 месяцев назад
Просмотрено 279 раз
\$\начало группы\$
Я разработал печатную плату для проекта с использованием STM32WB55, и после ее изготовления я пытаюсь подключить ее к компьютеру с помощью кабеля Micro USB, чтобы запустить на ней код.
Однако, когда я подключаю его к ПК, я не вижу для него COM-порт. Кажется, он не обнаруживает COM-порт. Все, что я вижу, это DFU в режиме FS под универсальной последовательной шиной, и я не совсем уверен, что это такое и как его использовать. (см. рисунок ниже. Извините, что на французском)
Я хочу запустить код на печатной плате с помощью загрузчика, однако для того, чтобы использовать инструмент STM32Cube IDE, мне нужно увидеть COM-порт.
Как вы думаете, что мне делать?
Я пытался использовать STM32Cube Prog, но я не совсем уверен, как его использовать, и у меня есть все мои коды в STM32CubeIDE. Есть ли способ кодировать с помощью STM32CubeIDE с помощью загрузчика?
\$\конечная группа\$
4
\$\начало группы\$
Режим USB загрузчика заводского ПЗУ STM32 не является виртуальным последовательным устройством. Скорее это устройство DFU, поэтому оно не будет отображаться как «COM-порт». Вместо этого он реализует протокол «Обновление прошивки устройства» для получения загрузок из подходящего программного обеспечения STM32 DFU, которое вы можете выбрать для запуска на своем ПК.
Вы получите виртуальное последовательное устройство, появляющееся через USB-порт STM32, только если вы загрузите собственную прошивку, реализующую виртуальное последовательное устройство.
Если вы хотите использовать режим UART загрузчика, вам потребуется дополнительное устройство USB-UART между вашим компьютером и платой и соответствующие драйверы для этого.
Обычно для разработки, хотя для загрузки и отладки кода следует использовать адаптер SWD. Если у вас его еще нет, подумайте о приобретении ST-LINK или посмотрите, есть ли у Nucleo или аналогичной оценочной платы, с которой вы работали ранее, возможность программирования внешних целей.
Наличие последовательного вывода сообщений, конечно, также очень полезно при разработке прошивки; теоретически есть способы туннелировать его через SWD, но вывод сигнала для подключения и внешнего USB UART и захвата, с которым, как правило, проще работать.