Failed to reconnect serial monitor after uploading on macOS

Apple Mac OSX
hanyazou
Posts: 29
Joined: Fri May 05, 2017 2:38 am

Failed to reconnect serial monitor after uploading on macOS

Postby hanyazou » Fri May 05, 2017 3:16 am

Hello there.

This is my first post at this forum. I read some posts related to USB and USB serial on Mac OS. But I can't find the solution of my problem.

I addressed and solve the problem by myself fotunately. But I'm not sure this is proper fix. So I post here to share my patch and hear your thoughts.

Environment:
OS: Mac OS X 10.12.4
Arduino IDE: 1.8.2
Board: SushiBits One STM32F103CB (https://www.tindie.com/products/maxtch/sushibits-arm-development-kits)

Error:
I've had a error after uploading. The IDE failed to re-connect serial monitor.

Code: Select all

/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.<init>(Serial.java:141)
   at processing.app.Serial.<init>(Serial.java:78)
   at processing.app.SerialMonitor$3.<init>(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.<init>(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


Solution:
I added short sleep (1 sec) after dfu-util -R to solve the problem. The target seems to take a little bit longet to came back on newer Mac OS.

Code: Select all

diff --git a/tools/macosx/maple_upload b/tools/macosx/maple_upload
index 8d15eff..906afc7 100755
--- a/tools/macosx/maple_upload
+++ b/tools/macosx/maple_upload
@@ -50,4 +50,8 @@ if [ ! -x ${DFU_UTIL} ]; then
     exit 2
 fi

+echo ${DFU_UTIL} -d ${usbID} -a ${altID} -D ${binfile} -R ${dfuse_addr} -R
 ${DFU_UTIL} -d ${usbID} -a ${altID} -D ${binfile} -R ${dfuse_addr} -R
+
+# take a breath waiting for restarting the target device
+sleep 1

ag123
Posts: 539
Joined: Thu Jul 21, 2016 4:24 pm

Re: Failed to reconnect serial monitor after uploading on macOS

Postby ag123 » Fri May 05, 2017 9:05 pm

if you happen to have an st-link v2 or jtag/openocd dongle or usb-uart dongle
you may like to try the stm32duino bootloader
https://github.com/rogerclarkmelbourne/ ... bootloader
there have been some enhancements which lets the sketch restart quickly after the reset following a dfu sketch upload
https://github.com/rogerclarkmelbourne/ ... its/master

the needed tools are like an st-link v2 or jtag/openocd or usb-uart dongle
https://github.com/rogerclarkmelbourne/ ... from-Linux
do backup the existing bootloader by extracting the image from the flash memory at 0x8000000 - length 20 kbytes just in case u'd need to restore the bootloader.

if you aren't too familar with these, perhaps stay with the stock boot loader and try installing the bootloader another time
-----
as for myself as i'm using linux, i use a separate serial monitor utility e.g. minicom, screen or putty instead of using the serial monitor bundled in the ide
you may like to find a similar separate serial monitor utility if that helps

in my sketches i like to make the sketch wait for a key press before running, e.g.

Code: Select all

   
setup() {
...

while (1) {
    uint8 c = 0;
    Serial.println("press g to start");
    if (Serial.available()) c = Serial.read();
    if(c == 'g') break;
    delay(1000);
}

hanyazou
Posts: 29
Joined: Fri May 05, 2017 2:38 am

Re: Failed to reconnect serial monitor after uploading on macOS

Postby hanyazou » Fri May 05, 2017 11:26 pm

Thank you for your reply.

I don't know about 'the existing bootloader' because I coundn't find any software information about the board provided by the board supplier. The supplier provide board design (net list and layout) instead. So I've modified the STM32duino bootloader for the net list and flash it by ST-Link at first. Here is my modification for the board.

Code: Select all

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


I'd like to use the serial monitor which is builtin to the IDE because I must use 1200bps open/close reset method for restarting into DFU mode. The IDE automatically close the serial monitor connection while uploading the sketch properly.

I think the problem have root in macOS USB implementation and timing. It must fail to open if the IDE and/or the serial monitor try to open the serial port before the STM32duino bootloader is recognized as a serial port by the OS. Some sleep might fix this trouble.

hanyazou
Posts: 29
Joined: Fri May 05, 2017 2:38 am

Re: Failed to reconnect serial monitor after uploading on macOS

Postby hanyazou » Sun May 07, 2017 5:51 am

I've needed one more modification for the bootloader.This is a bad dirty hack though it works well.

Because newer macOS USB implementation avoids libusb_reset_device() from resetting the STM32 bootloader target, you must reset the target in other way. You should 'consider timing out and self-resetting' for proper handling this situation as the comment says.

Code: Select all

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 */


My board and Mac work very well with these bootloader modification and my SushiBits One board variant. I've uploaded a video tells how it works. I upload the Blink.ino 3 times in the video. It works very nice. Thank you for Arduino for STM32 and this forum members.

https://youtu.be/b_IgPVzI7hU

I uploaded my patch to the github.

https://github.com/hanyazou/STM32duino- ... tsOneF103C
https://github.com/hanyazou/Arduino_STM ... tsOneF103C

BUT it was still require the 'sleep 1' in the tool maple_upload. That is the topic of this thread...

User avatar
RogerClark
Posts: 5591
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: Failed to reconnect serial monitor after uploading on macOS

Postby RogerClark » Thu May 11, 2017 10:17 am

Which board are you using ?

I can see you change when I look at the last commit to your repo, but it looks like you added a new board variant, rather than some feature change

hanyazou
Posts: 29
Joined: Fri May 05, 2017 2:38 am

Re: Failed to reconnect serial monitor after uploading on macOS

Postby hanyazou » Thu May 11, 2017 11:02 am

Which board are you using ?

I'm using SushiBits One board.
Environment:
OS: Mac OS X 10.12.4
Arduino IDE: 1.8.2
Board: SushiBits One STM32F103CB (https://www.tindie.com/products/maxtch/ ... pment-kits)


I think these two modification bellow are essential for Mac USB implementation because libusb_reset_device() can not reset target devices.

Code: Select all

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 */


Code: Select all

diff --git a/tools/macosx/maple_upload b/tools/macosx/maple_upload
index 8d15eff..906afc7 100755
--- a/tools/macosx/maple_upload
+++ b/tools/macosx/maple_upload
@@ -50,4 +50,8 @@ if [ ! -x ${DFU_UTIL} ]; then
     exit 2
 fi

+echo ${DFU_UTIL} -d ${usbID} -a ${altID} -D ${binfile} -R ${dfuse_addr} -R
 ${DFU_UTIL} -d ${usbID} -a ${altID} -D ${binfile} -R ${dfuse_addr} -R
+
+# take a breath waiting for restarting the target device
+sleep 1


I purchased a blue pill board on ebay for my investigation. But it will take a few weeks before I will receive the board.

User avatar
RogerClark
Posts: 5591
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: Failed to reconnect serial monitor after uploading on macOS

Postby RogerClark » Thu May 11, 2017 10:38 pm

Ok, let me know if the same issue applies to the Blue Pill

There are a number of other Mac users on the forum, and I think they may have their own personal work-around for these issues.

It seems to vary depending on the age / model of Mac and the version of OSX and also whether the board is plugged directly into the Mac or via the keyboard ( acting as a USB hub)

There is a partially implemented feature in the bootloader code, which can hold it in DFU mode, using a command sent via a non volatile ram address.
However the command / flag is not currently being set by the Libmaple code prior to resetting the board.
But I think it may just be a matter of uncommenting it.

If I get chance I will see if I can find what you need to uncomment, or possibly what code you need to add.

Of course, this may not fix it for you, but it wont do any harm to try it.

hanyazou
Posts: 29
Joined: Fri May 05, 2017 2:38 am

Re: Failed to reconnect serial monitor after uploading on macOS

Postby hanyazou » Sat May 13, 2017 6:50 am

I've received my blue-pill earlier than expected.

First, I wrote generic_boot20_pc13.bin with ST-Link V2.
I have two Mac:

Code: Select all

iMac:~$ sysctl hw.model
hw.model: iMac13,2   // late 2012

Code: Select all

MacBook-Pro:~$ sysctl hw.model
hw.model: MacBookPro11,5   // mid 2015


and Linux and macOS:

Code: Select all

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 16.04.2 LTS
Release:        16.04
Codename:       xenial

Code: Select all

$ sw_vers
ProductName: Mac OS X
ProductVersion: 10.12.4
BuildVersion: 16E195


I executed these command on each HW x OS combination to see vendor and product ID after dfu-util -R

Code: Select all

$ dfu-util -d 1eaf:0003 -U tmp.hex --alt 2
$ dfu-util -d 1eaf:0003 -D tmp.hex --alt 2 -R


result is:
macOS@MacBook Pro: 1eaf:0003
ubuntu@MacBook Pro: 1eaf:0004
macOS@iMac: 1eaf:0003
ubuntu@iMac: 1eaf:0004

Arduino_STM32 can't reset blue-pill after uploading sketch because dfu-util's -R option does not work on MacOS. I'd like to fix this.

User avatar
RogerClark
Posts: 5591
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: Failed to reconnect serial monitor after uploading on macOS

Postby RogerClark » Sat May 13, 2017 6:57 am

Arduino_STM32 can't reset blue-pill after uploading sketch because dfu-util's -R option does not work on MacOS. I'd like to fix this.


Yes. DFU util needs to support reset for it to work :-(

I'm not sure why DFU needs this, as it would make more sense if perhaps the DFU protocol sent the file size and then rebooted at the end

But the way Leaflabs orginally wrote the bootloader it needs the reset to reboot it - and I assume there must have been a good reason for this, as the Leaflabs guys really knew what they were doing.

hanyazou
Posts: 29
Joined: Fri May 05, 2017 2:38 am

Re: Failed to reconnect serial monitor after uploading on macOS

Postby hanyazou » Sat May 13, 2017 8:25 am

I'm not sure why DFU needs this, as it would make more sense if perhaps the DFU protocol sent the file size and then rebooted at the end


According to USB DFU specification, this seems to be proper behavior of the bootloader.

http://www.usb.org/developers/docs/devc ... FU_1.1.pdf
7.Manifestation Phase

After the zero length DFU_DNLOAD request terminates the Transfer phase, the device is ready to manifest the new firmware. As described previously, some devices may accumulate the firmware image and perform the entire reprogramming operation at one time. Others may have only a small amount remaining to be reprogrammed, and still others may have none. Regardless, the device enters the dfuMANIFEST-SYNC state and awaits the solicitation of the status report by the host. Upon receipt of the anticipated DFU_GETSTATUS, the device enters the dfuMANIFEST state, where it completes its reprogramming operations.Following a successful reprogramming, the device enters one of two states: dfuMANIFEST-SYNC or dfuMANIFEST-WAIT-RESET, depending on whether or not it is still capable of communicating via USB. The host is aware of which state the device will enter by virtue of the bmAttributes bit bitManifestationTolerant. If the device enters dfuMANIFEST-SYNC (bitMainfestationTolerant = 1), then the host issues the DFU_GETSTATUS request, and the device enters the dfuIDLE state. At that point, the host can perform another download, solicit an upload, or issue a USB reset to return the device to application run-time mode. If, however, the device enters the dfuMANIFEST-WAIT-RESET state (bitManifestationTolerant = 0), then if bitWillDetach = 1 the device generates a detach-attach sequence on the bus, otherwise (bitWillDetach = 0) the host must issue a USB reset to the device. After the bus reset the device will evaluate the firmware status and enter the appropriate mode.


The STM32duino-bootloader's bmAttributes is 0x3 (bitWillDetach=0, bitWillDetach=0). The host (MacOS) must issue a USB reset to the device in this case.


Return to “OSX”

Who is online

Users browsing this forum: No registered users and 1 guest