Привет.

Это мой первый пост на этом форуме. Я прочитал несколько сообщений, связанных с USB и USB -сериалом на Mac OS. Но я не могу найти решение моей проблемы.

Я сам решал и решаю проблему. Но я не уверен, что это правильное исправление. Поэтому я публикую здесь, чтобы поделиться своим патчем и услышать ваши мысли.

Среда:
ОС: Mac OS X 10.12.4
Arduino Ide: 1.8.2
Правление: Сушибки Один STM32F103CB (https: // www.Тинди.com/products/maxtch/ ... ПМИТ-КИТС)

Ошибка:
У меня была ошибка после загрузки. IDE не смог повторно подключить серийный монитор.
/Applications/Arduino-1.8.2.app/Contents/Java/arduino-builder -dump-prefs -logger=machine -hardware /Applications/Arduino-1.8.2.app/Contents/Java/hardware -hardware /Users/hanyazou/Library/Arduino15/packages -hardware /Users/hanyazou/Documents/Arduino/hardware -tools /Applications/Arduino-1.8.2.app/Contents/Java/tools-builder -tools /Applications/Arduino-1.8.2.app/Contents/Java/hardware/tools/avr -tools /Users/hanyazou/Library/Arduino15/packages -built-in-libraries /Applications/Arduino-1.8.2.app/Contents/Java/libraries -libraries /Users/hanyazou/Documents/Arduino/libraries -fqbn=Arduino_STM32-hanyazou:STM32F1:sushibitsone_f103c:upload_method=DFUUploadMethod -vid-pid=0X1EAF_0X0004 -ide-version=10802 -build-path /var/folders/b1/159gqtss0vn9gjsspxhl_6840000gn/T/arduino_build_207264 -warnings=none -build-cache /var/folders/b1/159gqtss0vn9gjsspxhl_6840000gn/T/arduino_cache_770802 -prefs=build.warn_data_percentage=75 -verbose /Users/hanyazou/github/MyArduinoScratchPad/Blink/Blink.ino /Applications/Arduino-1.8.2.app/Contents/Java/arduino-builder -compile -logger=machine -hardware /Applications/Arduino-1.8.2.app/Contents/Java/hardware -hardware /Users/hanyazou/Library/Arduino15/packages -hardware /Users/hanyazou/Documents/Arduino/hardware -tools /Applications/Arduino-1.8.2.app/Contents/Java/tools-builder -tools /Applications/Arduino-1.8.2.app/Contents/Java/hardware/tools/avr -tools /Users/hanyazou/Library/Arduino15/packages -built-in-libraries /Applications/Arduino-1.8.2.app/Contents/Java/libraries -libraries /Users/hanyazou/Documents/Arduino/libraries -fqbn=Arduino_STM32-hanyazou:STM32F1:sushibitsone_f103c:upload_method=DFUUploadMethod -vid-pid=0X1EAF_0X0004 -ide-version=10802 -build-path /var/folders/b1/159gqtss0vn9gjsspxhl_6840000gn/T/arduino_build_207264 -warnings=none -build-cache /var/folders/b1/159gqtss0vn9gjsspxhl_6840000gn/T/arduino_cache_770802 -prefs=build.warn_data_percentage=75 -verbose /Users/hanyazou/github/MyArduinoScratchPad/Blink/Blink.ino Using board 'sushibitsone_f103c' from platform in folder: /Users/hanyazou/Documents/Arduino/hardware/Arduino_STM32-hanyazou/STM32F1 Using core 'maple' from platform in folder: /Users/hanyazou/Documents/Arduino/hardware/Arduino_STM32-hanyazou/STM32F1 Detecting libraries used... "/Users/hanyazou/Library/Arduino15/packages/STM32/tools/arm-none-eabi-gcc/4.8.3-2014q1/bin/arm-none-eabi-g++" -c -g -Os -w -DDEBUG_LEVEL=DEBUG_NONE -ffunction-sections -fdata-sections -nostdlib --param max-inline-insns-single=500 -fno-rtti -fno-exceptions -DBOARD_sushibitsone_f103c -DVECT_TAB_ADDR=0x8002000 -DERROR_LED_PORT=GPIOB -DERROR_LED_PIN=1 -w -x c++ -E -CC -mcpu=cortex-m3 -DF_CPU=72000000L -DARDUINO=10802 -DARDUINO_SUSHIBITSONE_F103C -DARDUINO_ARCH_STM32F1 -DSERIAL_USB -DGENERIC_BOOTLOADER -DMCU_STM32F103CB -mthumb -march=armv7-m -D__STM32F1__ -DMCU_STM32F103CB -mthumb -march=armv7-m -D__STM32F1__ "-I/Users/hanyazou/Documents/Arduino/hardware/Arduino_STM32-hanyazou/STM32F1/system/libmaple" "-I/Users/hanyazou/Documents/Arduino/hardware/Arduino_STM32-hanyazou/STM32F1/system/libmaple/include" "-I/Users/hanyazou/Documents/Arduino/hardware/Arduino_STM32-hanyazou/STM32F1/system/libmaple/stm32f1/include" "-I/Users/hanyazou/Documents/Arduino/hardware/Arduino_STM32-hanyazou/STM32F1/system/libmaple/usb/stm32f1" "-I/Users/hanyazou/Documents/Arduino/hardware/Arduino_STM32-hanyazou/STM32F1/system/libmaple/usb/usb_lib" "-I/Users/hanyazou/Documents/Arduino/hardware/Arduino_STM32-hanyazou/STM32F1/cores/maple" "-I/Users/hanyazou/Documents/Arduino/hardware/Arduino_STM32-hanyazou/STM32F1/variants/sushibitsone_f103c" "/var/folders/b1/159gqtss0vn9gjsspxhl_6840000gn/T/arduino_build_207264/sketch/Blink.ino.cpp" -o "/dev/null" Generating function prototypes... "/Users/hanyazou/Library/Arduino15/packages/STM32/tools/arm-none-eabi-gcc/4.8.3-2014q1/bin/arm-none-eabi-g++" -c -g -Os -w -DDEBUG_LEVEL=DEBUG_NONE -ffunction-sections -fdata-sections -nostdlib --param max-inline-insns-single=500 -fno-rtti -fno-exceptions -DBOARD_sushibitsone_f103c -DVECT_TAB_ADDR=0x8002000 -DERROR_LED_PORT=GPIOB -DERROR_LED_PIN=1 -w -x c++ -E -CC -mcpu=cortex-m3 -DF_CPU=72000000L -DARDUINO=10802 -DARDUINO_SUSHIBITSONE_F103C -DARDUINO_ARCH_STM32F1 -DSERIAL_USB -DGENERIC_BOOTLOADER -DMCU_STM32F103CB -mthumb -march=armv7-m -D__STM32F1__ -DMCU_STM32F103CB -mthumb -march=armv7-m -D__STM32F1__ "-I/Users/hanyazou/Documents/Arduino/hardware/Arduino_STM32-hanyazou/STM32F1/system/libmaple" "-I/Users/hanyazou/Documents/Arduino/hardware/Arduino_STM32-hanyazou/STM32F1/system/libmaple/include" "-I/Users/hanyazou/Documents/Arduino/hardware/Arduino_STM32-hanyazou/STM32F1/system/libmaple/stm32f1/include" "-I/Users/hanyazou/Documents/Arduino/hardware/Arduino_STM32-hanyazou/STM32F1/system/libmaple/usb/stm32f1" "-I/Users/hanyazou/Documents/Arduino/hardware/Arduino_STM32-hanyazou/STM32F1/system/libmaple/usb/usb_lib" "-I/Users/hanyazou/Documents/Arduino/hardware/Arduino_STM32-hanyazou/STM32F1/cores/maple" "-I/Users/hanyazou/Documents/Arduino/hardware/Arduino_STM32-hanyazou/STM32F1/variants/sushibitsone_f103c" "/var/folders/b1/159gqtss0vn9gjsspxhl_6840000gn/T/arduino_build_207264/sketch/Blink.ino.cpp" -o "/var/folders/b1/159gqtss0vn9gjsspxhl_6840000gn/T/arduino_build_207264/preproc/ctags_target_for_gcc_minus_e.cpp" "/Applications/Arduino-1.8.2.app/Contents/Java/tools-builder/ctags/5.8-arduino11/ctags" -u --language-force=c++ -f - --c++-kinds=svpf --fields=KSTtzns --line-directives "/var/folders/b1/159gqtss0vn9gjsspxhl_6840000gn/T/arduino_build_207264/preproc/ctags_target_for_gcc_minus_e.cpp" Compiling sketch... "/Users/hanyazou/Library/Arduino15/packages/STM32/tools/arm-none-eabi-gcc/4.8.3-2014q1/bin/arm-none-eabi-g++" -c -g -Os -w -DDEBUG_LEVEL=DEBUG_NONE -MMD -ffunction-sections -fdata-sections -nostdlib --param max-inline-insns-single=500 -fno-rtti -fno-exceptions -DBOARD_sushibitsone_f103c -DVECT_TAB_ADDR=0x8002000 -DERROR_LED_PORT=GPIOB -DERROR_LED_PIN=1 -mcpu=cortex-m3 -DF_CPU=72000000L -DARDUINO=10802 -DARDUINO_SUSHIBITSONE_F103C -DARDUINO_ARCH_STM32F1 -DSERIAL_USB -DGENERIC_BOOTLOADER -DMCU_STM32F103CB -mthumb -march=armv7-m -D__STM32F1__ -DMCU_STM32F103CB -mthumb -march=armv7-m -D__STM32F1__ "-I/Users/hanyazou/Documents/Arduino/hardware/Arduino_STM32-hanyazou/STM32F1/system/libmaple" "-I/Users/hanyazou/Documents/Arduino/hardware/Arduino_STM32-hanyazou/STM32F1/system/libmaple/include" "-I/Users/hanyazou/Documents/Arduino/hardware/Arduino_STM32-hanyazou/STM32F1/system/libmaple/stm32f1/include" "-I/Users/hanyazou/Documents/Arduino/hardware/Arduino_STM32-hanyazou/STM32F1/system/libmaple/usb/stm32f1" "-I/Users/hanyazou/Documents/Arduino/hardware/Arduino_STM32-hanyazou/STM32F1/system/libmaple/usb/usb_lib" "-I/Users/hanyazou/Documents/Arduino/hardware/Arduino_STM32-hanyazou/STM32F1/cores/maple" "-I/Users/hanyazou/Documents/Arduino/hardware/Arduino_STM32-hanyazou/STM32F1/variants/sushibitsone_f103c" "/var/folders/b1/159gqtss0vn9gjsspxhl_6840000gn/T/arduino_build_207264/sketch/Blink.ino.cpp" -o "/var/folders/b1/159gqtss0vn9gjsspxhl_6840000gn/T/arduino_build_207264/sketch/Blink.ino.cpp.o" Compiling libraries... Compiling core... Using previously compiled file: /var/folders/b1/159gqtss0vn9gjsspxhl_6840000gn/T/arduino_build_207264/core/wirish/start.S.o Using previously compiled file: /var/folders/b1/159gqtss0vn9gjsspxhl_6840000gn/T/arduino_build_207264/core/wirish/start_c.c.o Using previously compiled file: /var/folders/b1/159gqtss0vn9gjsspxhl_6840000gn/T/arduino_build_207264/core/wirish/syscalls.c.o Using previously compiled file: /var/folders/b1/159gqtss0vn9gjsspxhl_6840000gn/T/arduino_build_207264/core/board.cpp.o Using previously compiled file: /var/folders/b1/159gqtss0vn9gjsspxhl_6840000gn/T/arduino_build_207264/core/wirish/boards.cpp.o Using previously compiled file: /var/folders/b1/159gqtss0vn9gjsspxhl_6840000gn/T/arduino_build_207264/core/wirish/boards_setup.cpp.o Using precompiled core Linking everything together... "/Users/hanyazou/Library/Arduino15/packages/STM32/tools/arm-none-eabi-gcc/4.8.3-2014q1/bin/arm-none-eabi-g++" -Os -Wl,--gc-sections -mcpu=cortex-m3 "-T/Users/hanyazou/Documents/Arduino/hardware/Arduino_STM32-hanyazou/STM32F1/variants/sushibitsone_f103c/ld/bootloader_20.ld" "-Wl,-Map,/var/folders/b1/159gqtss0vn9gjsspxhl_6840000gn/T/arduino_build_207264/Blink.ino.map" "-L/Users/hanyazou/Documents/Arduino/hardware/Arduino_STM32-hanyazou/STM32F1/variants/sushibitsone_f103c/ld" -o "/var/folders/b1/159gqtss0vn9gjsspxhl_6840000gn/T/arduino_build_207264/Blink.ino.elf" "-L/var/folders/b1/159gqtss0vn9gjsspxhl_6840000gn/T/arduino_build_207264" -lm -lgcc -mthumb -Wl,--cref -Wl,--check-sections -Wl,--gc-sections -Wl,--unresolved-symbols=report-all -Wl,--warn-common -Wl,--warn-section-align -Wl,--warn-unresolved-symbols -Wl,--start-group "/var/folders/b1/159gqtss0vn9gjsspxhl_6840000gn/T/arduino_build_207264/sketch/Blink.ino.cpp.o" "/var/folders/b1/159gqtss0vn9gjsspxhl_6840000gn/T/arduino_build_207264/core/wirish/start.S.o" "/var/folders/b1/159gqtss0vn9gjsspxhl_6840000gn/T/arduino_build_207264/core/wirish/start_c.c.o" "/var/folders/b1/159gqtss0vn9gjsspxhl_6840000gn/T/arduino_build_207264/core/wirish/syscalls.c.o" "/var/folders/b1/159gqtss0vn9gjsspxhl_6840000gn/T/arduino_build_207264/core/board.cpp.o" "/var/folders/b1/159gqtss0vn9gjsspxhl_6840000gn/T/arduino_build_207264/core/wirish/boards.cpp.o" "/var/folders/b1/159gqtss0vn9gjsspxhl_6840000gn/T/arduino_build_207264/core/wirish/boards_setup.cpp.o" "/var/folders/b1/159gqtss0vn9gjsspxhl_6840000gn/T/arduino_build_207264/../arduino_cache_770802/core/core_Arduino_STM32-hanyazou_STM32F1_sushibitsone_f103c_upload_method_DFUUploadMethod_b8b0acbbc794d5ed9ab449fd87ac250d.a" -Wl,--end-group "/Users/hanyazou/Library/Arduino15/packages/STM32/tools/arm-none-eabi-gcc/4.8.3-2014q1/bin/arm-none-eabi-objcopy" -O binary "/var/folders/b1/159gqtss0vn9gjsspxhl_6840000gn/T/arduino_build_207264/Blink.ino.elf" "/var/folders/b1/159gqtss0vn9gjsspxhl_6840000gn/T/arduino_build_207264/Blink.ino.bin" Sketch uses 13052 bytes (9%) of program storage space. Maximum is 131072 bytes. Global variables use 2816 bytes of dynamic memory. /Users/hanyazou/Documents/Arduino/hardware/Arduino_STM32-hanyazou/tools/macosx/maple_upload cu.usbmodem143411 2 1EAF:0003 /var/folders/b1/159gqtss0vn9gjsspxhl_6840000gn/T/arduino_build_207264/Blink.ino.bin dfu-util 0.8 dfu-util: Invalid DFU suffix signature dfu-util: A valid DFU suffix will be required in a future dfu-util release!!! Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc. Copyright 2010-2014 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/ Deducing device DFU version from functional descriptor length Opening DFU capable USB device... ID 1eaf:0003 Run-time device DFU version 0110 Claiming USB DFU Interface... Setting Alternate Setting #2 ... Determining device status: state = dfuIDLE, status = 0 dfuIDLE, continuing DFU mode device DFU version 0110 Device returned transfer size 1024 Copying data from PC to DFU device Download [ ] 0% 0 bytes Download [= ] 7% 1024 bytes Download [=== ] 14% 2048 bytes Download [===== ] 21% 3072 bytes Download [======= ] 29% 4096 bytes Download [========= ] 36% 5120 bytes Download [========== ] 43% 6144 bytes Download [============ ] 50% 7168 bytes Download [============== ] 58% 8192 bytes Download [================ ] 65% 9216 bytes Download [================== ] 72% 10240 bytes Download [==================== ] 80% 11264 bytesdfu-util: can't detach processing.app.SerialException: Error opening serial port '/dev/cu.usbmodem143411'. at processing.app.Serial.(Serial.java:141) at processing.app.Serial.(Serial.java:78) at processing.app.SerialMonitor$3.(SerialMonitor.java:95) at processing.app.SerialMonitor.open(SerialMonitor.java:95) at processing.app.AbstractMonitor.resume(AbstractMonitor.java:110) at processing.app.Editor.resumeOrCloseSerialMonitor(Editor.java:2207) at processing.app.Editor.access$2200(Editor.java:78) at processing.app.Editor$DefaultExportHandler.run(Editor.java:2173) at java.lang.Thread.run(Thread.java:745) Caused by: jssc.SerialPortException: Port name - /dev/cu.usbmodem143411; Method name - openPort(); Exception type - Port not found. at jssc.SerialPort.openPort(SerialPort.java:167) at processing.app.Serial.(Serial.java:130) ... 8 more Error opening serial port '/dev/cu.usbmodem143411'. Download [===================== ] 87% 12288 bytes Download [======================= ] 94% 13052 bytes Download [=========================] 100% 13052 bytes Download done. state(8) = dfuMANIFEST-WAIT-RESET, status(0) = No error condition is present Done! Resetting USB to switch back to runtime mode

Если у вас есть ST-Link V2 или JTAG/Openocd Dongle или USB-UART Dongle
Вы можете попробовать загрузчик STM32Duino Bootloader
https: // github.com/rogerclarkmelbourne/ ... загрузчик
Были некоторые усовершенствования, которые позволяют эскизе быстро перезагружаться после сброса после загрузки эскиза DFU
https: // github.com/rogerclarkmelbourne/ ... его/Мастер

Необходимые инструменты похожи на ST-Link V2 или JTAG/OpenOCD или USB-UART Dongle
https: // github.com/rogerclarkmelbourne/ ... от-linux
Сделайте резервную копию существующего загрузчика, извлекая изображение из флэш -памяти по адресу 0x8000000 - длина 20 кбайт на случай, если вам нужно восстановить загрузчик.

Если вы не слишком знакомы с ними, возможно, остановитесь с загрузчиком загрузки Stock и попробуйте установить загрузчик в другой раз
-----
Что касается меня, поскольку я использую Linux, я использую отдельную утилиту серийного монитора E.глин. Minicom, экран или замазка вместо использования последовательного монитора, связанного с IDE
Вы можете найти подобную отдельную утилиту серийного монитора, если это помогает

В моих эскизах мне нравится заставить эскиз ждать нажатия клавиши перед запуском, e.глин. setup() { ... while (1) { uint8 c = 0; Serial.println("press g to start"); if (Serial.available()) c = Serial.read(); if(c == 'g') break; delay(1000); }

Спасибо за ответ.

Я не знаю о «существующем загрузчике», потому что я не нахожу никакой информации о программном обеспечении о плате, предоставленной поставщиком платы. Поставщик предоставляет дизайн платы (сетевой список и макет) вместо этого. Итак, я изменил загрузчик STM32Duino для сети и сначала вспыхнула его ST-Link. Вот моя модификация для платы.
diff --git a/STM32F1/Makefile b/STM32F1/Makefile index 3aa6252..154b9f5 100644 --- a/STM32F1/Makefile +++ b/STM32F1/Makefile @@ -129,6 +129,7 @@ generic-pb7: begin clean gccversion build_generic-pb7 sizeafter finished copy_g generic-pb0: begin clean gccversion build_generic-pb0 sizeafter finished copy_generic-pb0 end stbee : begin clean gccversion build_stbee sizeafter finished copy_stbee end naze32: begin clean gccversion build_naze32 sizeafter finished copy_naze32 end +sushibits-f103: begin clean gccversion build_sushibits-f103 sizeafter finished copy_sushibits-f103 end generic-pb12: begin clean gccversion build_generic-pb12 sizeafter finished copy_generic-pb12 end hytiny-stm32f103t: begin clean gccversion build_hytiny-stm32f103t sizeafter finished copy_hytiny-stm32f103t end build: elf bin lss sym @@ -330,6 +331,17 @@ copy_naze32: cp $(TARGET).bin binaries/naze32_boot20.bin @echo +build_sushibits-f103: TARGETFLAGS= -DTARGET_SUSHIBITS_F103 +# Set the linker script +build_sushibits-f103: LDFLAGS +=-T$(ST_LIB)/c_only_md_high_density.ld +build_sushibits-f103: elf bin lss sym +copy_sushibits-f103: + @echo + @echo "Copying to binaries folder" + @echo + cp $(TARGET).bin binaries/sushibits_boot20_f103.bin + @echo + build_generic-pb12: TARGETFLAGS= -DTARGET_GENERIC_F103_PB12 # Set the linker script build_generic-pb12: LDFLAGS +=-T$(ST_LIB)/c_only_md_high_density.ld diff --git a/STM32F1/config.h b/STM32F1/config.h index 2ede089..7fae279 100644 --- a/STM32F1/config.h +++ b/STM32F1/config.h @@ -284,6 +284,25 @@ #define LED_PIN 3 #define LED_ON_STATE 0 +#elif defined TARGET_SUSHIBITS_F103 + // PB2 + #define LED_BANK GPIOB + #define LED_PIN 2 + #define LED_ON_STATE 1 + #define BOOTLOADER_WAIT 10 + + // PA0 + #define BUTTON_BANK GPIOE + #define BUTTON_PIN 5 + #define BUTTON_PRESSED_STATE 1 + + // Flag that this type of board has ENABLE like SushiBits + #define HAS_SUSHIBITS_HARDWARE 1 + // PC13 + #define USB_ENABLE_BANK GPIOC + #define USB_ENABLE_PIN 13 + #define USB_ON_STATE 1 + #elif defined TARGET_GENERIC_F103_PB12 #define LED_BANK GPIOB diff --git a/STM32F1/usb.c b/STM32F1/usb.c index 54f1643..719c19e 100644 --- a/STM32F1/usb.c +++ b/STM32F1/usb.c @@ -50,6 +50,12 @@ void setupUSB (void) { gpio_write_bit(USB_DISC_BANK,USB_DISC_PIN,0); /* present ourselves to the host */ #else +#ifdef HAS_SUSHIBITS_HARDWARE + /* Setup USB ENABLE pin as output push/pull */ + SET_REG(GPIO_CR(USB_ENABLE_BANK,USB_ENABLE_PIN),(GET_REG(GPIO_CR(USB_ENABLE_BANK,USB_ENABLE_PIN)) & crMask(USB_ENABLE_PIN)) | CR_OUTPUT_PP << CR_SHITF(USB_ENABLE_PIN)); + gpio_write_bit(USB_ENABLE_BANK, USB_ENABLE_PIN, USB_ON_STATE); +#endif + /* Generic boards don't have disconnect hardware, so we drive PA12 which is connected to the usb D+ line*/ #define USB_DISC_BANK GPIOA #define USB_DISC_PIN 12

Мне нужна была еще одна модификация для загрузчика.Это плохой грязный хак, хотя он работает хорошо.

Поскольку более новая реализация MacOS USB избегает Libusb_Reset_Device () сбросить целевую загрузку STM32, вы должны сбросить цель другим способом. Вы должны «рассмотреть время и самоопределение» для правильной обработки этой ситуации, как говорится в комментарии.
diff --git a/STM32F1/dfu.c b/STM32F1/dfu.c index 6091fe6..d47cfa9 100644 --- a/STM32F1/dfu.c +++ b/STM32F1/dfu.c @@ -278,6 +278,11 @@ bool dfuUpdateByRequest(void) { /* consider timing out and self-resetting */ dfuAppStatus.bState = dfuMANIFEST_WAIT_RESET; + /* + * XXX FORCE RESET!!! + */ + systemHardReset(); + } else if (startState == dfuUPLOAD_IDLE) { /* device expecting further dfu_upload requests */

Какую доску вы используете ?

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

Какую доску вы используете ? Я использую сушибиты одну доску. Среда:
ОС: Mac OS X 10.12.4
Arduino Ide: 1.8.2
Правление: Сушибки Один STM32F103CB (https: // www.Тинди.com/products/maxtch/ ... ПМИТ-КИТС) Я думаю, что эти два модификации реже важны для реализации Mac USB, потому что Libusb_Reset_Device () не может сбросить целевые устройства.
diff --git a/STM32F1/dfu.c b/STM32F1/dfu.c index 6091fe6..d47cfa9 100644 --- a/STM32F1/dfu.c +++ b/STM32F1/dfu.c @@ -278,6 +278,11 @@ bool dfuUpdateByRequest(void) { /* consider timing out and self-resetting */ dfuAppStatus.bState = dfuMANIFEST_WAIT_RESET; + /* + * XXX FORCE RESET!!! + */ + systemHardReset(); + } else if (startState == dfuUPLOAD_IDLE) { /* device expecting further dfu_upload requests */

Хорошо, дайте мне знать, если такая же проблема относится к синей таблетке

На форуме есть ряд других пользователей Mac, и я думаю, что они могут иметь свою личную работу по этим вопросам.

Похоже, что он варьируется в зависимости от возраста / модели Mac и версии OSX, а также о том, подключена ли плата непосредственно к Mac или через клавиатуру (выступая в качестве концентратора USB)

В коде загрузчика есть частично реализованная функция, которая может удерживать ее в режиме DFU, используя команду, отправленную через не нестабильный адрес ОЗУ.
Однако команда / флаг в настоящее время не устанавливается кодом Libmaple до сброса платы.
Но я думаю, что это может быть просто некомментированием.

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

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

Я получил свою синюю палубу раньше, чем ожидалось.

Сначала я написал generic_boot20_pc13.корзина с ST-Link v2.
У меня есть два Mac: iMac:~$ sysctl hw.model hw.model: iMac13,2 // late 2012

ARDUINO_STM32 не может сбросить синюю палочку после загрузки эскиза, потому что опция DFU-UTIL -R не работает на macOS. Я хотел бы это исправить. Да. DFU UTIL должен поддержать сброс для работы

Я не уверен, почему DFU нуждается в этом, так как было бы больше смысла, если, возможно, протокол DFU отправил размер файла, а затем перезагрузился в конце

Но то, как Leaflabs Orginally написал загрузчик, нужен сброс, чтобы перезагрузить его - и я предполагаю.

Я не уверен, почему DFU нуждается в этом, так как было бы больше смысла, если, возможно, протокол DFU отправил размер файла, а затем перезагрузился в конце Согласно спецификации USB DFU, это, по -видимому, является правильным поведением загрузчика.

http: // www.USB.org/разработчики/Docs/devc ... Fu_1.1.PDF 7.Фаза проявления

После того, как запрос DFU_DNLOAD нулевой длины завершает фазу передачи, устройство готово к проявлению новой прошивки. Как описано ранее, некоторые устройства могут накапливать изображение прошивки и выполнять всю операцию перепрограммирования одновременно. У других может быть лишь небольшое количество, оставшееся, чтобы быть перепрограммировано, и у других может быть ни один. Несмотря на это, устройство входит в состояние dfumanifest-sync и ожидает запроса отчета о статусе хостом. После получения ожидаемого dfu_getstatus устройство входит в состояние dfumanifest, где оно завершает свои операции перепрограммирования.После успешного перепрограммирования устройство входит в одно из двух состояний: dfumanifest-sync или dfumanifest-wait-reset, в зависимости от того, способен ли оно общаться через USB. Хост знает о том, какое утверждение будет введено в силу Bttributes Bit BitmanifestationToLerant. Если устройство входит в dfumanifest-sync (bitmainfestationtolerant = 1), то хост выдает запрос dfu_getstatus, и устройство входит в состояние dfuidle. На этом этапе хост может выполнить еще одну загрузку, запрашивать загрузку или выпустить сброс USB, чтобы вернуть устройство в режим времени выполнения приложения. Если, однако, Устройство входит в состояние dfumanifest-wait-reset (bitmanifestationtolerant = 0), то, если BitWillDetach = 1, устройство генерирует последовательность отстранения на шине, в противном случае (BitWillDetach = 0), хост должен выпустить USB-сброс на устройство. После сброса шины устройство оценит статус прошивки и введет соответствующий режим. Bmattributes STM32Duino-Bootloader составляет 0x3 (bitwilldetach = 0, bitwilldetach = 0). В этом случае хост (macOS) должен выпустить USB -сброс на устройство.

Недавно есть этот пост о включении Newlib Nano
http: // www.STM32duino.com/viewtopic.PHP ... = 10#p27885 Дорогие, я играл с опциями компилятора/линкера (последнее ядро ​​Maple F1), и это случилось со мной, что добавление »-specs = nano.Спецификации "для линкера, конечно, немного уменьшил размер эскиза, но также сломал автоматическое сброс платы на синей таблетке: с тех пор, как я должен был сбросить плату вручную, чтобы завершить загрузку..
Удаление опции восстановило функцию сброса автоматического платы.
Не мог проверить на других досках..

Лучший, e.

PS: Компилятор Версия: ARM-None-Eabi-GCC \ 4.8.3-2014Q1 Следовательно, вы можете обновить платформы.txt и исключить это -specs = nano.спецификации, чтобы увидеть, поможет ли это

Я не просмотрел код загрузчика, но я думаю, что DFU -UTIL -R установит биты в загрузчику и триггер, который сброс USB, USB -сброс в основном просто тянет D+, L -линии низкого уровня на 10 мс - 20 мс

Спасибо

Я не знаю, почему Leaflabs решили потребовать DFU для отправки сброса.

Вы можете попробовать изменить эти значения, сообщаемые загрузчиком, и добавить код, чтобы проверить пустую передачу, и, похоже, работает на Mac

Я не могу изменить BitWillDetach (= 0), потому что BitWillDetach = 1 означает, что устройство (загрузчик в данном случае) имеет возможность отсоединения. Я думаю, что это будет трата флэш-памяти, чтобы добавить возможность отключения. Никто не любит раздутый загрузчик.

И я проверил, что libusb_reset_device () на Mac не выдает сигнал сброса (как D+, так и D-линии тянутся на 10 мс). Я уверен, потому что я использовал свой логический анализатор, чтобы исследовать USB -сигнал в USB -кабеле. Загрузчик не сделал ничего плохого.

Я сделал новый патч, который добавляет некоторый тайм -аут, чтобы выйти из статуса MANIFEST_WAIT_RESET. Это хорошо работает на Linux и Mac. Этот мод потребляет 32 байта в бинарном размере. (Размер generic_boot20_pc13.бин увеличился с 7188 до 7220 байтов.)

Я хотел бы отправить PR в репозиторитель STM32-Bootloader.
diff --git a/STM32F1/binaries/generic_boot20_pc13.bin b/STM32F1/binaries/generic_boot20_pc13.bin index 71bce95..ed49094 100644 Binary files a/STM32F1/binaries/generic_boot20_pc13.bin and b/STM32F1/binaries/generic_boot20_pc13.bin differ diff --git a/STM32F1/dfu.c b/STM32F1/dfu.c index 6091fe6..d4fa062 100644 --- a/STM32F1/dfu.c +++ b/STM32F1/dfu.c @@ -60,6 +60,7 @@ void dfuInit(void) { dfuAppStatus.bwPollTimeout2 = 0x00; dfuAppStatus.bState = dfuIDLE; dfuAppStatus.iString = 0x00; /* all strings must be 0x00 until we make them! */ + dfuAppStatus.bwWaitResetTimeout = 0; userFirmwareLen = 0; thisBlockLen = 0;; userAppAddr = USER_CODE_RAM; /* default RAM user code location */ @@ -275,9 +276,11 @@ bool dfuUpdateByRequest(void) { /* device has programmed new firmware but needs external usb reset or power on reset to run the new code */ - /* consider timing out and self-resetting */ dfuAppStatus.bState = dfuMANIFEST_WAIT_RESET; + /* set timeout */ + dfuAppStatus.bwWaitResetTimeout = 500; + } else if (startState == dfuUPLOAD_IDLE) { /* device expecting further dfu_upload requests */ @@ -369,6 +372,9 @@ void dfuUpdateByReset(void) { } void dfuUpdateByTimeout(void) { + if (dfuAppStatus.bState == dfuMANIFEST_WAIT_RESET && --dfuAppStatus.bwWaitResetTimeout == 0) { + systemHardReset(); + } } u8 *dfuCopyState(u16 length) { @@ -464,7 +470,12 @@ bool dfuUploadStarted() { void dfuFinishUpload() { while (1) { + u32 c; + for (c = 0; c < 9000; c++) + { __asm("nop"); + } + dfuUpdateByTimeout(); /* Roger Clark. Commented out code associated with upload to RAM diff --git a/STM32F1/dfu.h b/STM32F1/dfu.h index d6ad1bc..70d2dc4 100644 --- a/STM32F1/dfu.h +++ b/STM32F1/dfu.h @@ -45,6 +45,7 @@ typedef struct _DFUStatus { u8 bwPollTimeout2; u8 bState; /* state of device at the time the host receives the message! */ u8 iString; + u32 bwWaitResetTimeout; } DFUStatus; typedef enum _PLOT {

Это интересно, если несколько удивительный результат, поскольку вытягивание D+/D-Pins Low в течение 10 мс (USB-сброс) предназначен для того, чтобы сообщить контроллерам USB-хоста снова запустить перечисление. Я предполагаю, что я не слишком знаком с этими аспектами, но может показаться, что USB -контроллер Mac может быть багги? Ну, я тоже не уверен

AG123 написал:Это интересно, если несколько удивительный результат, поскольку вытягивание D+/D-Pins Low в течение 10 мс (USB-сброс) предназначен для того, чтобы сообщить контроллерам USB-хоста снова запустить перечисление. Я предполагаю, что я не слишком знаком с этими аспектами, но может показаться, что USB -контроллер Mac может быть багги? Ну, я тоже не уверен

AG123 написал:Это интересно, если несколько удивительный результат, поскольку вытягивание D+/D-Pins Low в течение 10 мс (USB-сброс) предназначен для того, чтобы сообщить контроллерам USB-хоста снова запустить перечисление.

Я думал, что загрузчик ждет команды RFU Reset, а не какого-то общего USB-сброса, вызванного вытягиванием D+ и D- Low

Rogerclark написал:Я думал, что загрузчик ждет команды RFU Reset, а не какого-то общего USB-сброса, вызванного вытягиванием D+ и D- Low

Я попробовал ваш патч, Hanyazou, но, к сожалению, это не работает для меня. Доска не будет сброситься после загрузки эскиза.
Ханьязу написал:Я не могу изменить BitWillDetach (= 0), потому что BitWillDetach = 1 означает, что устройство (загрузчик в данном случае) имеет возможность отсоединения. Я думаю, что это будет трата флэш-памяти, чтобы добавить возможность отключения. Никто не любит раздутый загрузчик.

И я проверил, что libusb_reset_device () на Mac не выдает сигнал сброса (как D+, так и D-линии тянутся на 10 мс). Я уверен, потому что я использовал свой логический анализатор, чтобы исследовать USB -сигнал в USB -кабеле. Загрузчик не сделал ничего плохого.

Я сделал новый патч, который добавляет некоторый тайм -аут, чтобы выйти из статуса MANIFEST_WAIT_RESET. Это хорошо работает на Linux и Mac. Этот мод потребляет 32 байта в бинарном размере. (Размер generic_boot20_pc13.бин увеличился с 7188 до 7220 байтов.)

Я хотел бы отправить PR в репозиторитель STM32-Bootloader.
diff --git a/STM32F1/binaries/generic_boot20_pc13.bin b/STM32F1/binaries/generic_boot20_pc13.bin index 71bce95..ed49094 100644 Binary files a/STM32F1/binaries/generic_boot20_pc13.bin and b/STM32F1/binaries/generic_boot20_pc13.bin differ diff --git a/STM32F1/dfu.c b/STM32F1/dfu.c index 6091fe6..d4fa062 100644 --- a/STM32F1/dfu.c +++ b/STM32F1/dfu.c @@ -60,6 +60,7 @@ void dfuInit(void) { dfuAppStatus.bwPollTimeout2 = 0x00; dfuAppStatus.bState = dfuIDLE; dfuAppStatus.iString = 0x00; /* all strings must be 0x00 until we make them! */ + dfuAppStatus.bwWaitResetTimeout = 0; userFirmwareLen = 0; thisBlockLen = 0;; userAppAddr = USER_CODE_RAM; /* default RAM user code location */ @@ -275,9 +276,11 @@ bool dfuUpdateByRequest(void) { /* device has programmed new firmware but needs external usb reset or power on reset to run the new code */ - /* consider timing out and self-resetting */ dfuAppStatus.bState = dfuMANIFEST_WAIT_RESET; + /* set timeout */ + dfuAppStatus.bwWaitResetTimeout = 500; + } else if (startState == dfuUPLOAD_IDLE) { /* device expecting further dfu_upload requests */ @@ -369,6 +372,9 @@ void dfuUpdateByReset(void) { } void dfuUpdateByTimeout(void) { + if (dfuAppStatus.bState == dfuMANIFEST_WAIT_RESET && --dfuAppStatus.bwWaitResetTimeout == 0) { + systemHardReset(); + } } u8 *dfuCopyState(u16 length) { @@ -464,7 +470,12 @@ bool dfuUploadStarted() { void dfuFinishUpload() { while (1) { + u32 c; + for (c = 0; c < 9000; c++) + { __asm("nop"); + } + dfuUpdateByTimeout(); /* Roger Clark. Commented out code associated with upload to RAM diff --git a/STM32F1/dfu.h b/STM32F1/dfu.h index d6ad1bc..70d2dc4 100644 --- a/STM32F1/dfu.h +++ b/STM32F1/dfu.h @@ -45,6 +45,7 @@ typedef struct _DFUStatus { u8 bwPollTimeout2; u8 bState; /* state of device at the time the host receives the message! */ u8 iString; + u32 bwWaitResetTimeout; } DFUStatus; typedef enum _PLOT {

Вы пробовали вариант предложения @Danieleff, как опубликовано в PR @AG123 (на GitHub) ?

Rogerclark написал:Вы пробовали вариант предложения @Danieleff, как опубликовано в PR @AG123 (на GitHub) ?

Я обновил все сценарии загрузки клена с помощью предлагаемого исправления @Danieleff

Я не уверен, что это вызовет проблемы для Рика, если он не использует серийный терминал Arduino, но худший случай должен быть короткой задержкой (тайм -аут)

Извините за поздний ответ. Я возвращаюсь домой сейчас.
Но мой Mac и синий бои требует этого изменения.
echo -n Waiting for ${dummy_port_fullpath} serial... COUNTER=0 while [ ! -c ${dummy_port_fullpath} ] && ((COUNTER++ < 40)); do sleep 0.1 done + sleep 0.3 echo Done

Можете ли вы проверить изменение -c на -r?

Нет. Это терпит неудачу также, если ему не хватает «сон 0.3 '
COUNTER=0 while [ ! -r ${dummy_port_fullpath} ] && ((COUNTER++ < 40)); do sleep 0.1 done #sleep 0.3

Интересно, все ли это Mac или только одна конкретная модель.

Если все это Macs, дополнительный сон может быть добавлен в сценарий Mac, но 0.3 может быть недостаточно для медленных машин.

Какая скорость процессора и т. Д. - ваш Mac, и какая версия OSX вы используете.

У меня есть старая машина, управляемая Йосемити, с которой я могу проверить, но у меня сейчас нет времени

Мой Mac - это iMac в конце 2012 года 3.4 ГГц Intel Core i7 и OS версия OS IS Mac OSX 10.12.4.

Это хорошо работает на моем Mac.
echo -n wait for ${dummy_port_fullpath}... COUNTER=0 while ! dd if=${dummy_port_fullpath} of=/dev/null count=0 > /dev/null 2>&1 && ((COUNTER++ < 40)); do sleep 0.1 done echo done.

Я не слишком уверен, есть ли/usr/bin/тест или/бин/тест на macOS, но я предполагал [ ! -r ${dummy_port_fullpath} ]

Ханьязу написал:Мой Mac - это iMac в конце 2012 года 3.4 ГГц Intel Core i7 и OS версия OS IS Mac OSX 10.12.4.

Это хорошо работает на моем Mac.
echo -n wait for ${dummy_port_fullpath}... COUNTER=0 while ! dd if=${dummy_port_fullpath} of=/dev/null count=0 > /dev/null 2>&1 && ((COUNTER++ < 40)); do sleep 0.1 done echo done.

Я послал пиар.
https: // github.com/rogerclarkmelbourne/ ... 2/pull/297