Failed to reconnect serial monitor after uploading on macOS

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.

setup() {
...

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

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.

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’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.

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

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

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.

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

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.

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

First, I wrote generic_boot20_pc13.bin with ST-Link V2.
I have two Mac:
iMac:~$ sysctl hw.model
hw.model: iMac13,2 // late 2012


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.

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.

there is this post recently about including newlib nano
http://www.stm32duino.com/viewtopic.php … =10#p27885
Dears, I was playing with the compiler/linker options (latest Maple F1 core) and it happened to me that appending “–specs=nano.specs” to the linker, of course reduced a bit the sketch size but also broke the automatic board reset on a blue pill: since that addition I had to manually reset the board in order to complete the upload..
Removing the option restored the automatic board reset feature.
Couldn’t test on other boards..

Best, E.

ps: compiler version: arm-none-eabi-gcc\4.8.3-2014q1

hence you may like to update platforms.txt and exclude that –specs=nano.specs to see if it’d help

i’ve not reviewed the bootloader code, but i’d think dfu-util -R would set the bits in the bootloader and trigger that usb reset, usb reset is basically just pulling the D+, D- lines low for 10ms – 20ms

Thanks

I dont know why Leaflabs chose to require DFU to send reset.

You could try changing those values reported by the bootloader, and add some code to check for a empty transmission, and seem that works on the mac

I can’t change the bitWillDetach (= 0) because bitWillDetach = 1 means the device (the bootloader in this case) have the detach-attach capability and the bootloader does not have the capability. I think it will be waste of flash memory to add the detach-attach capability. No one does like bloated bootloader.

And I’ve checked that libusb_reset_device() on Mac does NOT issue reset signal (Both D+ and D- lines are pulled down for 10ms). I’m sure because I’ve used my logic analyzer to probe USB signal on USB cable. The bootloader has done nothing wrong.

I’ve made new patch which adds some timeout to exit the MANIFEST_WAIT_RESET status. This works well on Linux and Mac. This mod consume 32 bytes in the binary size. (The size of generic_boot20_pc13.bin increased from 7188 to 7220 bytes.)

I’d like to send PR to the STM32-bootloader repo.

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 {

it is an interesting if somewhat surprising result as pulling D+/D- pins low for 10ms (usb reset) is intended to tell the usb host controllers to start enumerating again. i’d guess i’m not too familar with these aspects but it may seem that the mac’s usb controller could be buggy? well, i’m not sure too

ag123 wrote:it is an interesting if somewhat surprising result as pulling D+/D- pins low for 10ms (usb reset) is intended to tell the usb host controllers to start enumerating again. i’d guess i’m not too familar with these aspects but it may seem that the mac’s usb controller could be buggy? well, i’m not sure too

ag123 wrote:it is an interesting if somewhat surprising result as pulling D+/D- pins low for 10ms (usb reset) is intended to tell the usb host controllers to start enumerating again.

I thought the bootloader was waiting for the DFU reset command, rather than some generic USB reset caused by pulling D+ and D- low

RogerClark wrote:I thought the bootloader was waiting for the DFU reset command, rather than some generic USB reset caused by pulling D+ and D- low

I’ve tried your patch hanyazou, but unfortunately it doesn’t seem to work for me. The board won’t reset after sketch upload.

hanyazou wrote:I can’t change the bitWillDetach (= 0) because bitWillDetach = 1 means the device (the bootloader in this case) have the detach-attach capability and the bootloader does not have the capability. I think it will be waste of flash memory to add the detach-attach capability. No one does like bloated bootloader.

And I’ve checked that libusb_reset_device() on Mac does NOT issue reset signal (Both D+ and D- lines are pulled down for 10ms). I’m sure because I’ve used my logic analyzer to probe USB signal on USB cable. The bootloader has done nothing wrong.

I’ve made new patch which adds some timeout to exit the MANIFEST_WAIT_RESET status. This works well on Linux and Mac. This mod consume 32 bytes in the binary size. (The size of generic_boot20_pc13.bin increased from 7188 to 7220 bytes.)

I’d like to send PR to the STM32-bootloader repo.

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 {

Have you tried a variation of @danieleff’s suggestion, as posted to the PR by @ag123 ( on github ) ?

RogerClark wrote:Have you tried a variation of @danieleff’s suggestion, as posted to the PR by @ag123 ( on github ) ?