«Черная таблетка» STM32 не может надежно войти в режим DFU
Я следую стандартному процессу, чтобы поместить STM32 "черную таблетку" (STM32F401CC) в режим DFU, чтобы я мог загрузить из Arduino IDE через USB:
- Удерживайте кнопку boot0.
- Сначала нажмите и отпустите.
- Освободить boot0.
Когда плата не включена в цепь, это работает несколько надежно, но не на 100%. При макетировании всего с несколькими подключениями он становится очень ненадежным, а иногда вообще не работает.
Последовательное USB-устройство, настроенное моим скетчем Arduino, работает нормально, только режим DFU не хочет работать.
Когда ему не удается войти в режим DFU, я вижу следующую ошибку в процессе загрузки Arduino:
-------------------------------------------------------------------
STM32CubeProgrammer v2.13.0
-------------------------------------------------------------------
An error occurred while uploading the sketch
Error: Target device not found
Establishing connection with the device failed
Я использую Arduino на Ubuntu 20.04, и в случае сбоя я вижу в /var/log/syslog
:
Apr 27 13:26:08 smurfenaar kernel: [79594.279257] usb 1-3: USB disconnect, device number 10
Apr 27 13:26:08 smurfenaar kernel: [79595.078232] usb 1-3: new full-speed USB device number 11 using xhci_hcd
Apr 27 13:26:09 smurfenaar kernel: [79595.192387] usb 1-3: device descriptor read/64, error -71
Apr 27 13:26:09 smurfenaar kernel: [79595.413389] usb 1-3: device descriptor read/64, error -71
Apr 27 13:26:09 smurfenaar kernel: [79595.636370] usb 1-3: new full-speed USB device number 12 using xhci_hcd
Apr 27 13:26:09 smurfenaar kernel: [79595.751435] usb 1-3: device descriptor read/64, error -71
Apr 27 13:26:09 smurfenaar kernel: [79595.973367] usb 1-3: device descriptor read/64, error -71
Apr 27 13:26:09 smurfenaar kernel: [79596.082540] usb usb1-port3: attempt power cycle
Apr 27 13:26:10 smurfenaar kernel: [79596.462407] usb 1-3: new full-speed USB device number 13 using xhci_hcd
Apr 27 13:26:10 smurfenaar kernel: [79596.462674] usb 1-3: Device not responding to setup address.
Apr 27 13:26:10 smurfenaar kernel: [79596.666550] usb 1-3: Device not responding to setup address.
Apr 27 13:26:10 smurfenaar kernel: [79596.874414] usb 1-3: device not accepting address 13, error -71
Когда это удается, я вижу:
pr 27 13:22:33 smurfenaar kernel: [79379.772197] usb 1-3: new full-speed USB device number 9 using xhci_hcd
Apr 27 13:22:33 smurfenaar kernel: [79379.899601] usb 1-3: New USB device found, idVendor=0483, idProduct=df11, bcdDe
vice=22.00
Apr 27 13:22:33 smurfenaar kernel: [79379.899605] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Apr 27 13:22:33 smurfenaar kernel: [79379.899607] usb 1-3: Product: STM32 BOOTLOADER
Apr 27 13:22:33 smurfenaar kernel: [79379.899609] usb 1-3: Manufacturer: STMicroelectronics
Apr 27 13:22:33 smurfenaar kernel: [79379.899611] usb 1-3: SerialNumber: 3466365E3135
и я также могу увидеть это с помощью команды lsusb
:
Bus 001 Device 052: ID 0483:df11 STMicroelectronics STM Device in DFU Mode
@NeilenMarais, 👍4
2 ответа
Я нашел это решение на форумах stm32duino:
Привязка A10 к GND успешно переводит его в режим загрузчика DFU в 100% случаев (хотя, вероятно, достаточно просто не оставлять PA10 плавающим)
Гипотетическое объяснение: в последнем абзаце раздела 4.3 документа AN2606 (руководства по загрузчику STM) говорится:
Рекомендуется поддерживать контакты RX неиспользуемых интерфейсов загрузчика (линии USART_RX, SPI_MOSI, CAN_RX и USB D+/D-, если они есть) на известном (низком или высоком) уровне при запуске загрузчика (этап обнаружения) . Если оставить эти выводы плавающими на этапе обнаружения, это может привести к активации неиспользуемых интерфейсов.
PA10 — это вывод RX для USART_1. Я считаю, что поскольку PA10 плавает, загрузчик чувствует трафик на USART_1 и считает, что это интерфейс, который он должен использовать, и поэтому отключает USB. Привязав PA10 к GND, загрузчик не воспринимает трафик UART и правильно включает USB.
Хотя я последовал совету по подключению его к земле, я предполагаю, что подключение его к земле через высокое значение сопротивления также сработает и должно позволить вам продолжать использовать PA10 для чего-то другого. После привязки PA10 к GND я обнаружил, что переход в режим DFU на 100% надежен, даже когда плата находится в цепи.
Недавно я приобрел две платы WeAct V3.0 STM32F411" Black Pill на eBay. Я купил много плат и усилителей; Другие электронные товары от этого продавца в прошлом без каких-либо проблем. Этот продавец на eBay имеет очень высокий рейтинг: 99,8% положительных отзывов, продано более 1 миллиона товаров. Однако я не могу подтвердить, являются ли эти платы «подлинными». платы WeAct, поскольку я не покупал их напрямую у WeAct.
Обе мои платы Black Pill можно запрограммировать с помощью ST-LINK V2, используя стандартные 3 (или 4) проводные контакты интерфейса SWD. Никаких проблем.
Однако обе платы изначально не смогли войти в режим программирования USB DFU после перезагрузки плат с нажатой кнопкой BOOT0
. Затем я попробовал заземлить контакт A10
, как предложено выше. Это полностью исправленное программирование DFU. Теперь обе платы каждый раз прекрасно программируются в режиме DFU.
Единственным недостатком является необходимость нажатия кнопок BOOT0
+ NRST
на плате, чтобы инициировать режим программирования DFU перед загрузкой с помощью Arduino IDE.
- esp32, platformio A fatal error occurred: Packet content transfer stopped (received 8 bytes) *** [upload] Error 2
- Запрограммируйте черную таблетку SMT32 без нажатия кнопок или специальных устройств
- "avrdude: stk500_getsync(): not in sync: resp=0x00", или некто по имени Avr не позволяет мне загрузить мою программу
- Загрузка Arduino Nano дает ошибку: avrdude: stk500_recv(): programmer is not responding
- Я закирпичил свой Arduino Uno? Проблемы с загрузкой скетчей на плату
- Проблема с загрузкой в Arduino Uno
- CH340 Nano avrdude: stk500_getsync() не синхронизирован, resp=0xa4
- Проблема с загрузкой кода