Page 1 of 1

'Manual' reset needed for bootloader 2.0

Posted: Fri Aug 07, 2015 1:47 am
by kolalde
First (and foremost), this work is excellent!

After I loaded the bootloader2.0, using both the sketch and directly loading the binary (no difference), it seems I'm only able to download a new sketch if I manually hit the reset button just before the download starts. Well, after downloading the new bootloader the first sketch download works, but subsequent downloads need the reset button pressed.

My environment:
Mac OSX 10.10.2
Maple Mini clone, BAITE BTE14-07 ( ... 64071.html)
Arduino 1.6.5
Arduino_STM32 (not sure of build, or version, or ??, but I grabbed from GitHub Aug 4, 2015)

Steps I took:
- With only a USB cable connected to the board (which gives me a device of /dev/cu.usbmodemfa131)
- With the original bootloader loaded, load the maple_mini_bootloader_updater sketch. Open the serial window, reply Y, all good, no errors.
- I set the Bootloader version to Bootloader 2.0 in the Tools menu and I'm able to immediately load a new (different) sketch. Nice and REAL fast, no real errors.
- Then I try to load the same sketch again:

Code: Select all

/Users/olaldk/Documents/Arduino/hardware/Arduino_STM32/tools/macosx/maple_upload cu.usbmodemfa131 2 1EAF:0003 /var/folders/cv/nnms9czs7w7_nrw1xv40zs3jlfppl5/T/build8396541035725626353.tmp/DS18x20_SSD1306.cpp.bin 
Failed to open serial device.
dfu-util: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!

dfu-util 0.8

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

Deducing device DFU version from functional descriptor length
dfu-util: No DFU capable USB device available
- I notice the maple_upload command is still pointing to the cu.usbmodelfa131, but I no longer see that device doing a "ls /dev/cu*".
- I also notice if I connect a CP2102 and select the new device in the Arduino Tools/Port menu (really just the board's RTS pin to STM32 RESET pin and GND seem needed), I am able to download without manually pressing reset. But then the board doesn't get reset properly after download:

Code: Select all

Download	[=========================] 100%        29412 bytes
Download done.
state(8) = dfuMANIFEST-WAIT-RESET, status(0) = No error condition is present
Resetting USB to switch back to runtime mode
dfu-util: error resetting after download
- Trying to only use the CP2102 for download didn't work. Externally powering the mini, hooking up the RX/TX to TX1/RX1, with and without boot1 pulled to ground. Where the heck is boot0?

So, finally, the questions.

- Can I use the new bootloader 2.0 with only one USB connection (I'll take the native port or the CP2102)?
- In either case, what am I doing wrong to not handle the STM32 reset correctly (either missing the reset before the download, native USB), or resetting after the download (CP2102)?
- I think I read something about the USB driver not being able to be both a DFU driver and a "serial monitor" driver, like the original maple mini bootloader, though I'm pretty new to any/all details.

Any pointer would be appreciated!


Speaking of appreciation, again, this work is awesome. Coming back to hobby micro-controllers after a 15 year break (we had kids), I started to play with my old collection of PIC parts (don't laugh, but having fun with 16F87x parts). Then found the ESP8266, better times, loved the memory, missed the pins. Then broke down and started playing with Arduino, love the community support, back to little memory. I was about to jump to larger AVR parts, then read about the STM32/Arduino work, just brilliant. Memory and pins, woot. I'll probably throw some serially connected ESP-01s on them in AT mode, we'll see. I just got the mini yesterday, need to dig more...

Re: 'Manual' reset needed for bootloader 2.0

Posted: Fri Aug 07, 2015 2:40 am
by mrburnette
I'll probably throw some serially connected ESP-01s on them in AT mode, we'll see.
Do not waste your time. Use the ESP8266 Arduino core: ... rduino-ide


Re: 'Manual' reset needed for bootloader 2.0

Posted: Fri Aug 07, 2015 5:11 am
by kolalde
mrburnette wrote:
I'll probably throw some serially connected ESP-01s on them in AT mode, we'll see.
Do not waste your time. Use the ESP8266 Arduino core: ... rduino-ide


Sure, I've never used the AT stuff yet. Started with LUA, then native (stayed there for some time), then Ivan's stuff. Very nice. But since I'll need to get the devices to communicate, and I figured I'll be using uart serial (I didn't see i2c slave for stm32duino), thought I'd try the AT stuff. Right now, I've got the ESPs at I2C masters to PIC slaves. The PICs handle the 7-segment, or 20x4 LCDs, the ESPs orchestrate and communicate outside.

Re: 'Manual' reset needed for bootloader 2.0

Posted: Fri Aug 07, 2015 6:26 am
by kolalde
OK, poking around a little more, I guess I have a problem with the bootloader2 enumerating the usb devices, so upload_reset can reset the device, so dfu-util can do the upload (am I close?). I this where linux maybe I'd look at udev type stuff, but there's no udev un OSX.....I'll keep reading.

Re: 'Manual' reset needed for bootloader 2.0

Posted: Fri Aug 07, 2015 8:18 am
by RogerClark
A few weeks ago I added a reset utility that is called by the maple_upload script.

This is supposed to send the magic reset sequence of chars etc to the USB Serial, which is interpreted by the core code in the sketch, which in turn resets the board.
When the board resets, it first runs the bootloader, which then enumerates as the dfu device ready for upload

Did you set the com port in the IDE to be the com port of that they board enumerates with

You can try manually running the upload_reset utility from the command line. From memory I think the usage is


i.e maple_reset calls upload_reset like this

${DIR}/upload-reset ${dummy_port_fullpath} 750

The DELAY TIME is a bit of a hack, as it takes some time for the OS to re-enumerate and have the DFU device available for DFU-util

So if DFU-util is called too soon after upload_reset, the DFU device is not ready.

In order that I could get millisecond level delays between telling the board to reset and the util returning, I built the configurable delay

Anyway, see if the upload_reset works for you to start with, by running it from the command line

BTW. Also make sure the permissions are ok on all the scripts, but I presume as maple_upload runs the other scripts and binaries, but we did have someone who was syncing them via the cloud who had permissions issues.

Re: 'Manual' reset needed for boot loader 2.0 [WORKAROUND]

Posted: Fri Aug 07, 2015 9:25 pm
by kolalde
Thanks for the advice guys.

Working from:
- the USB /dev/... device isn't showing up when using bootloader2.0 (ever) but works for original maple-mini bootloader.
- this is working for others, not me
- no need to look at any of the dfu stuff, if the USB isn't there so upload-reset can't do it's thing

So maybe not code (directly), but environmentally triggered. I switched the USB cable from a local port on the MBP (Late 2011) to a USB 2.0 4 port hub connected to my thunderbolt display, then connected to the MBP, that worked. OK, sure.

Not sure what timing? thing is at play here, but it's very repeatable. Direct to MBP, no /dev/{cu|tty].usbmodem* device. Connect through hub (through display), all good.

I didn't try hub to MBP, I've got to rush out now, just thought I'd try this on a hunch. I've got a Mac-mini (mid 2010) as well, I'll try that at some point too.


Re: 'Manual' reset needed for bootloader 2.0

Posted: Fri Aug 07, 2015 9:54 pm
by RogerClark
try putting the board into perpetual bootloader mode

Perhaps, the time the bootloader is a dfu device is too short for your hardware hub etc

Re: 'Manual' reset needed for bootloader 2.0

Posted: Fri Aug 07, 2015 10:25 pm
by kolalde
Ok, I'll try when I get back, but I don't understand.

If after the upgrading to 2.0, I no longer see the /dev usb device, isn't that the root problem?

I already know I can hit the reset button just before the load starts and the upload works. Using 2.0 I never see the /dev device, and hence never see the led flashing, since upload-reset can't reset.

I'd guess perpetual bootloader will allow the upload, but I'm not sure what that tells us.

No? BTW, I'll definitely try it and let you know, just trying to wrangle my understanding of how this works.


Re: 'Manual' reset needed for bootloader 2.0

Posted: Fri Aug 07, 2015 10:35 pm
by RogerClark
I think the new bootloader has a shorter timeout than the original maple bootloader, while it waits for upload via DFU.

The code for bootloader 2.0 was derived mainly from the modified maple bootloader, developed by JonathanOlafsson, and its optimised for both speed and size.

So I suspect what is happening is that as it only spends about 1 second waiting for DFU upload, that your USB hardware chain is not re-acting fast enough for the OS to enumerate the DFU device.

I think Victor PV had a similar issue on one of his Windows boxes, but I can't recall if he every got to the bottom of the problem.

The Bootloader is very easy to rebuild, You just need to add the Arduino's arm compiler location to your PATH and do make maple-mini

I forget the exact thing you need to change in the config, but its basically the number of flashes. If you increase that value, it will hold in the bootloader longer

Re: 'Manual' reset needed for bootloader 2.0

Posted: Thu May 04, 2017 4:42 pm
by dieter-l
yesterday I had the same problem after changing to an new PC running under Win10.
After a long night I found the following issues with a Bluepill and the bootloader 2.0:

- Connected to an USB 2.0 Port: everything working fine, no Problems
- Connected to an USB 3.0 Port: Manual reset of the Bluepill necessary.

After Investigation with UsbTreeView I found the issue only with the Renesas USB 3.0 Hostcontroller.
I found a firmware update for the Controller - applying it, reboot the PC -
now the Bluepill is working on the Renesas USB 3.0 Controller too.