Unable to detect generic STM32 after burning bootloader

[Jugulaire]

Hi,

I've burned the bootloader generic_boot20_pc13.bin on my board. Everything is okay when it's uploading.

╭─jugu@jugu-ThinkPad-X220  ~/Arduino/hardware/Arduino_STM32-master/tools/linux64/stm32flash  
╰─$ sudo ./stm32flash -w ~/Downloads/generic_boot20_pc13.bin -v -g 0x0 /dev/ttyUSB0
stm32flash Arduino_STM32_0.9

http://github.com/rogerclarkmelbourne/arduino_stm32

Using Parser : Raw BINARY
Interface serial_posix: 57600 8E1
Version      : 0x22
Option 1     : 0x00
Option 2     : 0x00
Device ID    : 0x0410 (Medium-density)
- RAM        : 20KiB  (512b reserved by bootloader)
- Flash      : 128KiB (sector size: 4x1024)
- Option RAM : 16b
- System RAM : 2KiB
Write to memory
Erasing memory
Wrote and verified address 0x08001c14 (100.00%) Done.

Starting execution at address 0x08000000... done.

After pluggin the USB on my computer and running dmesg i got this error :

[ 2273.436617] usb 2-1.2: new full-speed USB device number 44 using ehci-pci
[ 2273.508627] usb 2-1.2: device descriptor read/64, error -32
[ 2273.684642] usb 2-1.2: device descriptor read/64, error -32
[ 2273.860600] usb 2-1.2: new full-speed USB device number 45 using ehci-pci
[ 2273.932654] usb 2-1.2: device descriptor read/64, error -32
[ 2274.108751] usb 2-1.2: device descriptor read/64, error -32
[ 2274.284675] usb 2-1.2: new full-speed USB device number 46 using ehci-pci
[ 2274.692714] usb 2-1.2: device not accepting address 46, error -32
[ 2274.764709] usb 2-1.2: new full-speed USB device number 47 using ehci-pci
[ 2275.172701] usb 2-1.2: device not accepting address 47, error -32
[ 2275.172928] usb 2-1-port2: unable to enumerate USB device

Anybody know whats wrong ? Note : the led is blinking when Boot0 and Boot1is on 0

[Jugulaire]

Edit : After lot of test, it seem to work with boot1 and boot2 at 0. But i got : dfu-util: No DFU capable USB device available on Upload. In some case, the device is not detected.. I have already check the USB cable updated the udev rules and of course select 48mhz for usb mode in Arduino IDE.

[brainsucker-na]

I'm not sure if this is the same issue, but building binaries of latest master branch with gcc-arm-none-eabi 15:4.9.3+svn231177-1 on ubuntu 16.10 produces .bin files ~40 bytes smaller than binaries on github. Unfortunately this compiled bootloader (generic-pc13 for me) never works properly as Maple DFU device, always showing an "Unrecognized USB device message" (win10). Uploading .bin from github instantly fixes the issue.

[rogerclarkmelbourne]

@brainsucker-na

What version of gcc are you using ?

The code was updated to fix and issue with newer versions of gcc (I think possibly it was tested with gcc 5.2 but you'd need to check the comment on the commit)

However its possible that newer versions of gcc have even more complex optimisation which causes your builds to not work.

[brainsucker-na]

4.9.3, its a latest package in official ubuntu repo. Could you please tell me which version was used to build these latest binaries (uploaded to github)?

[rogerclarkmelbourne]

The default compiler on my machine (Windows 7 PC) is gcc 5.4.1

So I'm pretty sure that's what they were built with.

[brainsucker-na]

Thanks, binaries compiled with gcc-arm-none-eabi-5_4-2016q3-20160926-win32.zip are working fine.

Quite a journey to disable button support for generic-pc13. Btw, since most of such boards (blue-pills) have no button anyway, isn't it a good idea to build such binary as well (and may be suggest it by default).

I personally had a couple of "nice" hours, trying to understand why my pill is helplessly blinking after half of power-ons, but perfectly works in other half. Sometimes reset helped, sometimes power cycle, some times disconnecting other components from i2c or power. But in fact it was just a wheel encoder connected to PC14 :) Zomg.

[rogerclarkmelbourne]

I was thinking of using Boot1 on the Blue Pill as the button, as Boot1 has no effect when Boot0 is Low.

But could be used to hold the bootloader in DFU (aka perpetual bootloader mode)

However I've never got around to doing it

[brainsucker-na]

That probably will be a proper way to implement this, indeed.

Also it might be worth modifying line in readme.md to list specific current GCC versions known to work and the broken ones (5.4 vs 4.9.3), it now lists only 4.8. Thanks for your work.

[Jugulaire]

Okay, for me the problem was simple : Hit reset on programming. My chinese cheap board does not implement auto reset feature so i need to do this by hand.

[protobits]

Hi, I replaced the R10 resistor on my BluePill board with a 1.5k resistor which I traced as a pull-up to 3.3V (not to 5V as schematic says). I understand this is how it should work. However, after flashing the generic PC13 firmware it does not enumerate (I get the fast blink followed by the slower blink of the LED). I also tried to recompile without the button definition in config.h and I get the same behavior. What could be happening?

[rogerclarkmelbourne]

@v01d

I think pullup to 3.3V is actually correct.

Its documented in many places e.g.

http://www.beyondlogic.org/usbnutshell/usb2.shtml

Which board are you using ? (link please)

Its also possible your board has a hardware fault. Most of the cheap boards from eBay etc are not tested at all by the manufacturer and sometimes there are dry joints on the USB connector etc

We've also seen other problems, like the crystal not being connected - but its still possible to flash via USB Serial or STLink as that uses the internal RC oscillator inside the MCU

[rogerclarkmelbourne]

Actually, if you want to try something else...

See http://www.stm32duino.com/viewtopic.php?f=3&t=2217&p=30058#p30058

I've been working on a combined bootloader and test sketch

See the zip file in the forum post

[protobits]

It is the blue pill, don't know how exactly to describe it or link to it. It has R11 as a 22ohm resistor in series to D+ and R10 was a 10k resistor between R11 and 3.3V, which I replaced with a 1.5k (I confirmed this by testing resistance between this point (PA12) and 3.3V).

What should be the common behavior of the LED if everything is OK? Is it expected to keep slowly blinking?

[protobits]

From the first link I understand the resistor encodes the USB speed. And from dmesg output I see a high-speed device is detected. So that part should be ok. The problem seem to be with enumeration, which I think comes from controlling PA12 pin.

[rogerclarkmelbourne]

You are totally correct.

The bootloader breaks the USB spec in order to force enumeration, because it sets PA12 to GPIO mode, and pulls it low for a short time, then releases it back to its normal USB operation

Unfortunately these boards do not have the necessary extra hardware which would allow them to conform with the USB spec, and this was the only way anyone found to make them re-enumerate as required.

The idea for this came from @victor_pv and I think he wrote the additional code to do that, because the original bootloader was only for the Maple mini board, which has the correct additional hardware to re-enumerate correctly following the USB spec.

If you need a board that conforms to the spec, buy a board like a Maple mini clone which has an extra 2 transistors to correctly re-enumerate the USB.

[protobits]

The problem is I'm using the Blue Pill to prototype a design which I'm doing around an STM32F103C8T6 and now I'm wondering if it will work since this does not.

The Maple Mini is hard to find here so I cannot try it. In any case, I looked at its schematic and I see a transistor which I really don't understand why helps. Does the D+ line require a specific current to work? (the base current is fixed).

[rogerclarkmelbourne]

This is not really an issue with the bootloader.

You should look at other online resources for how to design USB enumeration correctly

[protobits]

But the bootloader should enumerate as DFU device, that is what I'm after. Thus, it is the bootloaders responsibility of correctly enumerating.

On Mon, Jun 19, 2017 at 11:39 PM, Roger Clark notifications@github.com wrote:

This is not really an issue with the bootloader.

You should look at other online resources for how to design USB enumeration correctly

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/rogerclarkmelbourne/STM32duino-bootloader/issues/19#issuecomment-309628399, or mute the thread https://github.com/notifications/unsubscribe-auth/AAJ3qob_Qpe6TQIFnme1uBzqI6nWNrfwks5sFzD_gaJpZM4McONr .

[protobits]

Ok, after long searching I found a binary which correctly enumerates the USB so I know it isn't a hardware fault. It is the cdcacm.bin from this thread: http://www.stm32duino.com/viewtopic.php?f=28&t=878&start=10

The binary from this repo (generic for PC13) does not enumerate for me. Could this be a problem with the code or the build?

[protobits]

YESSSSSSSSSS Got it working!!

I confirm the problem is with the build. I built without Os flag (used O0), which required extending the FLASH size on the LD script and this enumerates correctly.

So, there is either something in the code or with the compiler used to build the binaries in the repo. If it is a compiler issue, maybe the binaries should be compiled on a specific compiler (maybe using some CI service). If it is the code, maybe it is worth looking why it fails with Os.

At the previously linked thread they mention about an issue with volatiles, don't know if it is the case for this code. http://www.stm32duino.com/viewtopic.php?f=28&t=878&start=20

[rogerclarkmelbourne]

See the readme

Also Note. Use GCC 4.8 (not 4.9 or newer, as these versions have more aggressive optimisation which causes hardware registers not be read correctly and consequently the bootloader does not work)

Also. You should use the makefile

[protobits]

I've read that, but the precompiled binary gives me the same issue so I'm letting you know of that issue. In any case, 4.8 is quite old. It would be nice to support newer compilers.

El 20/6/2017 1:18, "Roger Clark" notifications@github.com escribió:

See the readme

Also Note. Use GCC 4.8 (not 4.9 or newer, as these versions have more aggressive optimisation which causes hardware registers not be read correctly and consequently the bootloader does not work)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/rogerclarkmelbourne/STM32duino-bootloader/issues/19#issuecomment-309640454, or mute the thread https://github.com/notifications/unsubscribe-auth/AAJ3qmmx34N-ptd1zUGpTa5A4VMVuN4Bks5sF0gNgaJpZM4McONr .

[rogerclarkmelbourne]

Thanks

Its odd that you have the issue, but hundreds of other people who downloaded the precompiled binary did not report an issue. I would know if they had an issue, as there are loads of users on STM32duino.com plus a load of ham radio guys who use it etc and on youtube.

The code got updated a while ago so that we could use a slightly newer compiler, but generally this bootloader is written to be used with the Arduino IDE and AFIK that currently uses GCC 4.8.3-2014q1

[rogerclarkmelbourne]

Actually... What version of GCC are you using

I think the version of GCC thats in my path is newer than the Arduino version so its possible it was compiled with gcc 5.4.1

This does not explain however why the bin doesn't work for you, but does work for a lot of other people

[protobits]

Damn, I just reflowed the solder in the USB pins and it now works also with your binary and very consistently. It was a hardware problem after all. =/

Sorry for wasting your time =S Thanks for the help anyways

On Tue, Jun 20, 2017 at 2:33 AM, Roger Clark notifications@github.com wrote:

Actually... What version of GCC are you using

I think the version of GCC thats in my path is newer than the Arduino version so its possible it was compiled with gcc 5.4.1

This does not explain however why the bin doesn't work for you, but does work for a lot of other people

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/rogerclarkmelbourne/STM32duino-bootloader/issues/19#issuecomment-309649385, or mute the thread https://github.com/notifications/unsubscribe-auth/AAJ3qsYKeg0SKDYazLKj2BvPLVirdvVKks5sF1m_gaJpZM4McONr .

[rogerclarkmelbourne]

OK. I'll add you to the list of people for whom it works ;-)