[SOLVED] Problems with the bootloader

Uploading sketches via ST-Link is still easy goin
Using bootloader instead still same old … (

From time to time – maybe 20-30% – the loader doesn’t find its beliked DFU although the port is still visible/listed

z1.jpg (94.03 KiB) Viewed 2357 times

Which OS?

stevestrong wrote:Which OS?

The resetting error at the end should be ok people say. I saw it when in “good period” and “bad period” too.
I have periods where the upload works 99% fine, and periods where I have to press reset during upload all the time (with a correct USB clock). Still thinking what could be the cause for such changes in the DFU mood. Win7-64 here, latest hw, USB3.0, USB2.0.

I had problems mostly when the executed code blocks the on-chip USB serial to work, i.e. nested ISRs.
But most of the time is the Java running in the Win10 background which becomes unstable…

Even the Maple Mini will fail on Windows once-in-a-while. While I have not been on Windows in a year, my very well tuned Win8.1 box used to fail perhaps 4 or 5 time per 100 (guess … I did not count every failure.) Just when you though everything was perfect – poof, an upload FU.

Point is, it is not a Red_Pill, Blue_Pill, Black_Pill, or Maple Mini issue … it is the technology. If you must have 100% upload reliability, you are using the wrong technology. While Linux hosting is better IMO than Windows 8/10, it is still not perfect; an occasional hiccup will happen.

My overall recommendation:
–> Develop and test on a Maple Mini, the de facto standard
–> Migrate/Port to the Red/Blue/Black boards for inexpensive projects and deployments where having a bootloader is of no value

Ray

The way the bootloader and Core reset the USB is basically a hack that we had to use because the Blue Pill etc do not have the necessary additional hardware to reset the USB correctly.
This hack, breaches the USB spec, so is not guaranteed to work.

The Blue Pill also has another design fault as it uses a 10k USB pull up resistor, but the USB spec requires 1.5k

The Maple mini has the additional USB reset hardware, and uses the correct pull up, and is therefore far more reliable.

I use all sorts of MCUs for work, and find even expensive commercial SWD programmers sometimes fail to upload, and I am forced to powercycle the MCU, and try again.

Hopefully someone has already solved/fixed this issue – but I wasn’t able to find such a solution.
ISSUE:
I have a similar problem with the Blue Pill bootloader running on Windows 10 x64.
I downloaded the generic_boot20_pc13.bin per the instructions at http://wiki.stm32duino.com/index.php?ti … bootloader.
Before loading the first sketch, the Blue Pill shows up in the Device Manager as “Atmel USB Device – Maple DFU” device. But the Arduino v1.8.3 IDE expects/requires the Blue Pill to be a virtual COM port device to download a sketch (i.e. “Ports(COM & LPT) – COMx” under the Device Manage).
In searching the web I found a suggestion to “push reset button after the sketch has compiled and before the download starts”. With luck one can push the reset button at the right time during the Arduino compile/download process to make this work. Then, once one has successfully downloaded their first sketch, the Blue Pill shows up in as a “Ports(COM & LPT) – COMx” device. This allows the Arduino IDE to properly download any subsequent sketch. The problem seems to be that on reset the bootloader expects a sketch to be present before it forces the re-enumeration to switch from being a “Maple DFU” device to a “virtual COM” device, which is what the Arduino IDE expects/requires for downloading a sketch.
SUGGESTION:
Eliminate this initial sketch download issue/problem by Including a dummy sketch (e.g. simply blinks the LED) as part of the bootloader download process. Thus on reset the bootloader will always find a sketch to run and will always force a re-enumeration to switch from being a “Maple DFU” device to a “virtual COM” device.

The idea of including a dummy sketch has already been discussed.

I have a method to do this, but I don’t have time to make the change at the moment

I can confirm, I always have to press the reset button on the blue pill for the upload process to find the dfu.
I’m on Win10/64Bit

From my work on IT i know that MS changed the USB driver framework on W10/64Bit and a lot of low level stuff is broken or behaves now differently. I would bet that the hack doesn’t work anymore like it used to.

In order the DFU upload to work you should use the “STM32duino bootloader” upload option, AND you have to close the USB serial COM port before upload.

The reason for this is that a magic sequence is sent over USB serial (virtual COM port) by the dfu util which “software” resets the boards. If the COM port is busy, the magic sequence cannot be sent, hence no reset. In this case you must reset manually the board.

This behavior is currently “normal”.

Of course you are totally correct, you made me though laugh it would be a shame as an IT guy…
Well actually, if one has the serial port open, you will get an immediate error that the port is in use which is then obvious!

What I am referring to is that I always have to wait to this point
maple_loader v0.1
Resetting to bootloader via DTR pulse
Reset via USB Serial Failed! Did you select the right serial port?
Assuming the board is in perpetual bootloader mode and continuing to attempt dfu programming...

Searching for DFU device [1EAF:0003]...

[universam10 – Wed Jul 19, 2017 6:49 am] –
Nevertheless, I have to admit that I am not using Arduino at all but only PlatformIO, so there might be an issue in this regard.

Oh, why don’t you say so from the beginning?
PIO uses a different dfu loader and upload script, that’s why it will not work.
I think I posted somewhere in the forum how to solve this, so you better search for it

Not really helpful on 1300 posts

I’ve posted the underlying code which is run that is the maple_loader, taken from Arduino.

Read beginning from this post: viewtopic.php?f=41&t=728&start=40

Please help me, I’m having a problem getting the Blue Pill Bootloader to work on my Windows 10 x64 system. I downloaded the generic_boot20_pc13.bin from the latest Github “Latest commit e851e8a 6 days ago” and downloaded it to my Blue Pill STM32F103C8 board. The board shows up in the Device Manager using “Show hidden devices” as hidden: “Other devices” “Maple 003” (both with ?) and non-hidden “Ports (COM & LPT)” “USB Serial Device (COM4)”. I’m trying to download the the File > Examples > 01.Basic > Blink Sketch, and my setup is – Tools > Board: “Blue Pill F103C8”, Upload method: “STM32duino bootloader”, Port: “COM4”. I always get the following results no matter when I click the reset button:
—————————————————————————————————————————–
Sketch uses 17168 bytes (26%) of program storage space. Maximum is 65536 bytes.
Global variables use 4796 bytes (23%) of dynamic memory, leaving 15684 bytes for local variables. Maximum is 20480 bytes.
maple_loader v0.1
Resetting to bootloader via DTR pulse
Searching for DFU device [1EAF:0003]…
dfu-util – (C) 2007-2008 by OpenMoko Inc.
This program is Free Software and has ABSOLUTELY NO WARRANTY

Couldn’t find the DFU device: [1EAF:0003] ——————————————————————————————————————————

Did you load the drivers ? I presume so, because you say its appearing as Maple Serial ??

Did you select the COM port in the IDE ?

If you open the serial terminal in the IDE, with the COM post selected, do you see it printing an information message (the default bootloader does this until you upload a sketch)

Thanks for the reply.
Yes the driver is loaded, I selected the COM port, and yes I’m getting the “Congratulations, you have the …” message over and over. As it goes through the process I hear two beeps close together at about the same time as the log says “Resetting to bootloader via DTR pulse”,”Searching for DFU device [LEAF:0003]…”, then nothing in the log until “dfu-util – (C) 2007-2008…”.
If I were to guess, I’d say maybe the bootloader isn’t giving the PC long enough to get through whatever it does before the Arduino IDE/DFU has time to start the download process.

Normally dfu waits for ages

Open your device manager and see if the dfu device appears briefly

Another thing you can do to upload if the sketch is not resetting into the bootloader is to unplug the USB

Tell the IDE to upload, wait for the compile to finish and the upload attempt to start, then plug in the board

On my W7 machine it then uploads almost instantly

But perhaps W10 is slower than W7

Well I opened the Device Manager, plugged in the Blue Pill STM32F103C8 board, and the “Other devices” “Maple 003” showed up briefly as expected.
I then tried unplugging the board after the Sketch finished compiling, but unfortunately still no luck.
The board continues to send the “Congratualtions, ….” message on the COM port.
By the way, a few weeks ago the earlier bootloader worked, but then it quit working after I had some Windows 10 updates. I also noticed that if deleted the “Other devices” “Maple 003” and “Ports (COM & LPT)” “USB Serial Device (COM4)” devices and then plugged in the board I got two “Setting up device” messages when Windows 10 re-installed these two devices. I don’t know if this was happening before or not, but I thought I’d mention it.

I don’t use W10 because of these sorts of problems, when it does an update and trashes all my drivers.

Anyway.
I have not tested this…
If you have a blue pill with the generic_pc13 bootloader installed, try pulling pin PC14 high, then power cycle the board.

The code in the bootloader is supposed to check PC14 and if it’s high, it locks the bootloader into DFU mode, waiting for upload.

Just tested this, but it doesnt work

I’ll need to compile a new version which uses boot1 (This doubles up a a GPIO pin)

I just tested the latest generic_pc13.bin from github and its working fine on my W7 machine

I have a PR I need to merge before I can change the code to use Boot1 to hold in DFU mode

I checked again, and pulling PC14 high when powering on the board does cause the bootloader (generic-pc13) to hold in DFU mode

This is also know as “Perpetual bootloader” mode.

I’ve also merged a PR that unifies the GD32 and STM32 bootloaders and done some other housekeeping

And I have extended the default bootloader DFU wait to be just over twice as long as before – so this is around 2 seconds.

Hopefully this will resolve the problems people seem to be having with slow USB detection on Windows 10

I’m very sorry Roger and everyone else. My mistake. I discovered that my problem was that I didn’t have the Maple DFU driver properly installed. Once I installed/reinstalled the driver the Blue Pill bootloader works just fine. I’m not sure why it worked before unless one of the Windows 10 updates caused the Maple DFU driver to get deleted. Again I’m sorry for the false alarm.

Umm

I will have to change the dfu hold time back to what it was before.

I was having the same problem, only capable of flashing while pressing reset button on the ”right” time, usually just before uploading from arduino ide. My device was not appearing in dfu-list -l, only on the brief moments after the reset. The problem was that the upload-reset program was not working quite right, from the stm32 repo in device manager from this link: http://dan.drown.org/stm32duino/package … index.json. Replacing it with the ‘upload-reset’ from the main repo in https://github.com/rogerclarkmelbourne/ … 2.wiki.git, finally worked instantly. No manual reset needed anymore and instant upload

https://github.com/rogerclarkmelbourne/ … STM32/wiki
srp

The Boards Manager package you used is created and maintained by @ddrown, and not updated very often.

The repo on GitHub gets updates every week, and sometimes multiple updates per week, so it’s always best to use the repo