I’m pretty sure I’m missing an important step but I really can’t figure out which one, so after a full day of research, I decided to post here, even if I look like a newbie – which I am regarding STM32 btw 
.
Hardware : “Blue Pill” from Aliexpress.
OS1 : Windows 10 64bit French
OS2 : Windows 7 32bit French
What I did successfully:
– Added and configured Arduino_STM32 to my Arduino IDE
– Connected the blue pill using a USB-serial adapter
– Flashed the Blink sample sketch using serial => success, works as expcted
– Flashed the SerialCallResponse sample sketch using serial => success, works as expcted
What doesn’t work:
– Using micro USB to communicate with the board. When connected, Windows pops up (the French version of) this message, and in the device manager, an “Unknown device” shows up under USB bus controllers (French version of this)
What I tried:
1) replaced the 10K SMD resistor R10 by a 1K5 one, as indicated on the wiki.
2) installed the driver by starting “Arduino_STM32\drivers\win\install_drivers.bat”. It popped up 3 command windows: one (calling the two others) saying:
Installing Maple DFU driver...
Installing Maple Serial driver...
[ag123 – Mon Nov 06, 2017 12:15 am] –
try installing a sketch e.g. a blinky sketch, usb-serial is actually part of stm32duino libmaple core sketch, making sure SERIAL_USB is defined in the build flags in relevant section in boards.txt, maybe that helps
The latest bootloader includes a dummy sketch, so after it switches from bootloader to sketch it should show up as serial.
When you plug the board in, the LED should flash very quickly 6 times followed by 6 flash (but not as fast) flashes
This indicates the bootloader is working.
As the latest bootloader comes with a dummy sketch to test the Serial, after the LED stops flashing the board should switch to the sketch and re-enumerate as a Serial device
Look in the Windows device manager and initially you should see the libusb-win32 device, and after 1 sec, you should see the serial device
If the drivers didnt load, you will see 2 different known devices, one for when the bootloader is running and the other for the sketch Serial
From my last 10 pieces/lot order 2 boards could be flashed with the bootloader over ST-Link, but showed the same effect (not recognized on USB). Meaning they have a HW error somewhere.
As they did cost 1.5 EUR / piece, it is not worth trying to fix them, although I tried to resolder the USB pins without any positive effect.
So just by more and leave the problematic ones on side.
Btw, how exactly did you install the driver?
Did you open a CMD window with admin rights and executed the install batch file?
1. When I upload my sketch (I have to press reset button) it uploads fine, and switches to COM25. I see COM25 in the DevMan.
I can see my data in Teraterm.
2. When I press reset, the COM25 disappears, it is not available anymore. In the DevMan I see only the MAPLE_DFU.
When I unplug/plug the usb COM25 still not available.
3. When I upload my sketch again, it uploads fine (I have to press reset) and the COM25 is again there (I see it in DevMan as COM25). I see my data in Teraterm.
4. When I press reset, the COM25 disappears, I see only MAPLE DFU in the DevMan. The only way to get COM25 back is to upload a sketch..
[RogerClark – Mon Nov 06, 2017 12:50 am] –
The latest bootloader includes a dummy sketch, so after it switches from bootloader to sketch it should show up as serial.
When you plug the board in, the LED should flash very quickly 6 times followed by 6 flash (but not as fast) flashes
This indicates the bootloader is working.
Hmmm, this is not what I’m seeing. I tried burning the bootloader again and it looks like it succeeds, but I’m not getting 6 quick flashes. The previous sketch (blink) seems to start again, so the led is blinking with a 1+1 sec cycle…
I’m burning the bootloader with the following command:
python ./stm32loader.py -p COM4 -w generic_boot20_pc13.bin
[Pito – Mon Nov 06, 2017 7:00 pm] –
I flashed the latest bootloader into my new BPill (it flashes 6x fast and 6x slower upon reset). Replaced the 10k resistor with 2k2 one. Win7 64b. Rogers repo.
1. When I upload my sketch (I have to press reset button) it uploads fine, and switches to COM25. I see COM25 in the DevMan.
I can see my data in Teraterm.
2. When I press reset, the COM25 disappears, it is not available anymore. In the DevMan I see only the MAPLE_DFU.
When I unplug/plug the usb COM25 still not available.
3. When I upload my sketch again, it uploads fine (I have to press reset) and the COM25 is again there (I see it in DevMan as COM25). I see my data in Teraterm.
4. When I press reset, the COM25 disappears, I see only MAPLE DFU in the DevMan. The only way to get COM25 back is to upload a sketch..
Hi,
I guess what you describe is the expected behaviour: you get the 6 flash and the device *is* recognized, first as a MAPLE DFU (Roger says “libusb-win32” above, but I guess it’s the same), and then as a serial port.
I’d be happy if mine did the same
Vincent
Its not uncommon for dry joints on the USB connector
[RogerClark – Tue Nov 07, 2017 1:10 am] – Sounds like faulty usb connections
Its not uncommon for dry joints on the USB connector
I would have expected no detection at all in this case, but maybe if only D+ ou D- is affected it could be a “half usb” and cause the observed symptoms. I’ll resolder the connector tonight along with preparing the second board. Thanks for the tip.
Kind regards,
Vincent
PS: it shall go via MapleDFU to the Serial upon pressing reset, afaik.. Mine COM appears only after an upload. After pressing reset it ends up in MapleDFU.. 
viewtopic.php?f=3&t=2602
then i concur with roger’s point as well usb cables don’t always work as well as they look
i happened to have one of those usb voltage current meter dongles
https://www.ebay.com/sch/i.html?_nkw=us … er&_sop=15
for once i connected it in series with a MM, only to realise that 5v expected from usb does an erratic bungee jump, it gives me 3v, 2.9v, 4.5v, 1.5v, 0.8v depending on how that plug interface is shifted ever so slightly, switched a usb cable, things get more stable
OK, here’s a report of the tests I made this evening:
1) I resoldered the USB connector on the first board (damn, those traces are thin), checked continuity and checked there was no short. It didn’t change anything (but I admit I had little hope as there was no 6 quick flashes anyway).
2) I unpacked the second board I had (same seller, same order) and tried the same procedure : moved the jumper + reseted + connected serial to the serial/USB converter + burned bootloader with python script. Again, no error… but again, no 6 flashes after restoring the jumper and a new reset.
3) I fired the Arduino IDE and uploaded a blink sketch through Serial: upload suceeded and sketch started.
4) I tried again to burn the bootloader, to no avail. No error, but after reboot, the blink sketch restarts and no 6 flashes
5) Just to be sure, I retried the burn procedure with the ST Demonstrator as explained on the wiki. It terminated successfully and… BINGO ! 6 quick flashes !!
6) I replugged the board using the micro USB and yoo-hoo, it got recognized as “Maple Serial (COM14)” in the device manager
7) I then restarted the IDE, chose the STM32duino bootloader as upload method and could flash a blink sketch (with other delays to make sure a new version was really flashed): success.
So my conclusion is that somehow, there is something wrong when using the python bootloader burning procedure on these boards, although it returns with no error. I’m using Python 2.7 btw. I guess it should have worked with that version, right ?
What still puzzles me is that I’m pretty sure I had already tried the ST Demonstrator with the first board, but it didn’t work. I admit maybe the jumpers were not placed correctly at that time or some other error on my part…
Anyway, I have the second board ready for my tests. Thanks to all for your help.
@Roger, are you interested in getting one of those weird “non-python-burnable” boards ? The first one is still as-is, with the script showing no error but unable to burn the bootloader it seems. I can send it to you at no cost if it helps, just tell me.
Kind regards,
Vincent
Perhaps in this case the python flasher is not able to unlock
However its strange that you get some flashes.
Apart from trying on a Windows machine using ST’s own tools…
The only other similar problem was where someone had a faulty oscillator crystal, and the built in Serial bootloader does not use the crystal, hence its possible to flash but then things don’t work correctly.
BTW. I presume the crystal is 8Mhz ?
[RogerClark – Tue Nov 07, 2017 10:26 pm] –
I’ve heard of some boards where the flash is locked.
Perhaps in this case the python flasher is not able to unlock
However its strange that you get some flashes.
Apart from trying on a Windows machine using ST’s own tools…
Well, ST’s tool can seemingly flash through serial indeed, but so does the Arduino IDE with sample sketches…
The only other similar problem was where someone had a faulty oscillator crystal, and the built in Serial bootloader does not use the crystal, hence its possible to flash but then things don’t work correctly.
BTW. I presume the crystal is 8Mhz ?
Yes, it’s marked 8.000.
I didn’t check it with a scope but the blink delays are roughly correct (well, I probably wouldn’t detect a 5% drift but we’re not an order of magnitude out).
That being said, the duration of flashing through python felt shorter than with the ST tool.
How long should the burning take ? Less than 1 second ? 1-2 seconds ? 3-5 seconds ? More ?
I might try to take a look at the flash script… Any way to enable debugging or any hint where to look ?
Kind regards,
Vincent
You could try reading back the flash, if the python tool supports that.
PS. Why are you using Python ? there is a binary stm32flash for most platforms, including the source if you are on a OS that we didnt compile a binary for
Most people either use STM’s own free Windows GUI tool for this or use the stm32flash binary
Note.
Someone reported the the upload speed used in my scripts for stm32flash of 230400 was not supported by their USB to Serial adaptor.
So I’m going to need to change all the scripts to use 115200 as all adaptors seem to support that speed.
[RogerClark – Tue Nov 07, 2017 11:42 pm] –
It normally takes a few seconds to flash the bootloader (as it now includes a dummy sketch and its 28 in total I think)
You could try reading back the flash, if the python tool supports that.
Mmmh, it looked shorter than that. I’ll see what I can find…
PS. Why are you using Python ? there is a binary stm32flash for most platforms, including the source if you are on a OS that we didnt compile a binary for.
Most people either use STM’s own free Windows GUI tool for this or use the stm32flash binary
?
Err, sorry, I looked on your github https://github.com/rogerclarkmelbourne/ … bootloader and the only flash tool I could find (in the “flash” subfolder) is a python script.
Google returns many “stm32flash”. Can you point me to the version you use ?
Note.
Someone reported the the upload speed used in my scripts for stm32flash of 230400 was not supported by their USB to Serial adaptor.
So I’m going to need to change all the scripts to use 115200 as all adaptors seem to support that speed.
That is a possibility indeed…
I’m using a CP210x-based USB to serial converter. Never had issues with it but I don’t know for sure if I ever used it above 115200…
Kind regards,
Vincent
there is stm32flash.exe
I forget the exact syntax but the uploader uses
stm32flash -g 0x8000000 -b 115200 -w %str% %1
I suspect %str% %1% is the file to write to the board
[RogerClark – Thu Nov 09, 2017 12:54 am] –
Look in https://github.com/rogerclarkmelbourne/ … /tools/win
there is stm32flash.exe
Got it, thanks.
I forget the exact syntax but the uploader uses
stm32flash -g 0x8000000 -b 115200 -w %str% %1
I suspect %str% %1% is the file to write to the board
To be precise, %str% is the file and %1% is the serial port, so I used
stm32flash -g 0x8000000 -b 115200 -w generic_boot20_pc13.bin COM4
Needs to be updated
Which line needs to be changed (line number)
[RogerClark – Fri Nov 10, 2017 1:08 am] – Which line needs to be changed (line number)
It’s Line 428 (as indicated 
)
KR,
Vincent
