Generic STM32F103R board not showing up in device manager and serial ports

blahlicus
Sun Mar 12, 2017 6:41 pm
Hey, I’ve recently purchased yet another STM32F103 based board off of taobao (here), I was able to flash the stm32duino generic bootloader from here to the device via an external USB to serial (RS232 cable) device by connecting my power lines to 3.3v and GND, then the data lines to PA9 and PA10.

The device could be programmed either by an external USB to serial device, or by the built-in RS232 one as circled in green below, I’ve confirmed it by uploading blink sketches via both methods.

But I was unable to get the chip’s own USB (circled in red) to work at all, as in, on Windows, a new device does not appear in the “Ports” or “Universal Serial Buss controllers” trees in device manager, not even a new device with the yellow triangle warning message appears.

Just to be clear, the USB port was able to power the device, and the blink sketch that I’ve previously uploaded via serial still works under USB power, but the host computer cannot talk to the device at all.

I’m quite new to STM32 so I am really at a lost here, could someone help out?

Image



blahlicus
Mon Mar 13, 2017 9:54 am
That didn’t work at all, I’ve ran install_drivers.bat, then plugged in the board, seeing as it didn’t work, I also ran install_STM_COM_drivers.bat but it made no difference.

Below is a screenshot of my device manager with the device plugged in, I think I should make it clear, no new devices are detected at all when it is plugged in, there is no “new device is plugged in” notification sound when it is plugged in, it is as if the cable is only giving the board power but nothing else, I also tried several different cables and it made no differences.

Image


stevestrong
Mon Mar 13, 2017 10:23 am
The issue is that you are using the “serial” upload method, which does not compile the USB serial, that’s why you see no COM port.

Try following:
1. flash the bootloader (over the serial port PA9/10) – BOOT1 set to “1”.
2. use the “STM32duino bootloader” method when uploading blink sketch over the red USB port – (BOOT01 jumpers set to “0”). Now you should see COM port.


RogerClark
Mon Mar 13, 2017 10:37 am
This is the second concurrent thread where people are having an issue with this.

see

viewtopic.php?f=28&t=1877


stevestrong
Mon Mar 13, 2017 1:01 pm
RogerClark wrote:This is the second concurrent thread where people are having an issue with this.
see
viewtopic.php?f=28&t=1877

blahlicus
Mon Mar 13, 2017 2:20 pm
Hey, I don’t think that is the issue that you guys are describing, like i said before, the USB seems to literally act like a power cable only, there are no “libusb-win32” devices at all in the device manager, I have already uploaded the bootloader (BOOT1 set to 1) and then tried the USB (BOOT0/1 set to 0) and literally nothing new shows up under device manager, compiling and uploading a blink sketch with “stm32duino bootloader” without selecting any ports yields an error.

For reference, I was able to get my bluepills working as per the instructions on the wiki, they appeared as “unrecognised devices” under device manager before everything was correctly configured but this generic board does not appear as anything at all under device manager.


Pito
Mon Mar 13, 2017 2:24 pm
Then do measure the wiring between the usb socket and the usb pins at the stm32 package.. With an ohmmeter.
And try to get the schematics..

zmemw16
Mon Mar 13, 2017 2:55 pm
that board has very similar looks to a mini_CZ(??) ?
i have vet & zet versions and istr putting or seeing something on the wiki.

could you post top and bottom pictures?
any text to suggest maker or version ?

stephen


stevestrong
Mon Mar 13, 2017 2:55 pm
Yes, we need the schematics of the board to see how the red USB connector is wired on the board with the STM32 chip.

Btw, you should flash the bootloader when BOOT0 is set to “1”, not BOOT1!
BOOT1 should be always tied to GND.


zmemw16
Mon Mar 13, 2017 3:22 pm
i’ll take the risk

the jumpers for boot0 and boot1 are ‘normally’ each in a line of 3 pins, the middle pin is the boot line.

‘o’ or gnd……..bootn……….. ‘1’ or 3v3
////|……………| link

‘o’ or gnd……..bootn……….. ‘1’ or 3v3
///////////// |……………| link

they were almost certainly set to the 0 side of those 3 pins originally
apologies if i’m teaching you how to suck eggs :D :D :D :D
stephen


blahlicus
Tue Mar 14, 2017 1:17 pm
Here are some high resolution macro shots of the front and back as requested, it has an onboard RS232 to upload from, has an STLink connector, and the client USB, I tried checking continuity of the data pins of the USB and got 400ohm on one of the pins on the controller, but I don’t really know what to probe for so any guidelines would be nice.

Image
Image


stevestrong
Tue Mar 14, 2017 1:34 pm
According to the datasheet, BOOT0 is solely as input available on pin 60 of the LQFP64 package. Please check if you can access it.
BOOT1 is connected to PB2.
Now you know how and which pins you should control to flash the bootloader and upload further software.

Pito
Tue Mar 14, 2017 4:10 pm
usb part.JPG
usb part.JPG (22.37 KiB) Viewed 604 times

zmemw16
Tue Mar 14, 2017 5:06 pm
looking at the top right, the red links are boot0 & boot1
they’re both 3v3, that’s boot from embedded sram according to AN2606
boot1 boot0
X 0 user flash
0 1 system flash
1 1 sram

try moving boot0 to gnd or move both to gnd
if you have one, try using a stlink, well worth the £2 or so

the other red links (bottom right) appear to be set for usb, alternative is CAN on the right hand end of the bottom rows

the vet/zet variant has transistors q2, q3 associated with the serial interface, so try the board against that schematic for vct/vet
hth
stephen


victor_pv
Wed Mar 15, 2017 5:19 pm
From the pictures looks like the transistor Q1 is wired to pin 38 in the MCU (PC7), not sure if it is active High or Low.
The USB pins go PA11 and PA12, which are the right ones.
If PC7 is driven the wrong way it may be blocking USB communication. I dont remember how the pull up transistor is managed in the Maple (active high or low?), but I do believe in the code for Generic boards we don’t even try to use a pin for that functions, so it is probably left as input, in which case the transistor may or may not be leaving the pull up resistor connected. Unless the resistor get’s disconnected, the USB serial may not enumerate at all.
You could try in your sketch driving that pin low for a few ms, then high. And if that doesn’t work try the other way, driving it low, then high. I dont remember how long the pull up resistor needs to be connected, I believe it should be in response to some host action, but in practice I think the core just keeps it connected for set amount of time, try a ms or two.

Now, as far as the software. I think like someone posted before, that you may not be following the right process.

To get the USB serial detected you need to:
1.- Upload the stm32duino bootloader. At this point the board should show as a DFU device, but NOT as serial.
2.- Upload a sketch using the stm32duino bootloader. At this point the Serial USB should show up.


Pito
Wed Mar 15, 2017 5:43 pm
The high-side USB switch is active low (pnp or pmos Q1). The pin driving the Q1 must be set and compiled within the bootloader.

victor_pv
Thu Mar 16, 2017 3:36 am
Pito wrote:The high-side USB switch is active low (pnp or pmos Q1). The pin driving the Q1 must be set and compiled within the bootloader.

ag123
Tue Mar 28, 2017 9:37 pm
i’d like to suggest this: install the maple or stm32duino bootloader as it has been successfully done

if it is a leaflabs maple style boards, i.e.
if the reset button and user buttons and leds is the same setup / connecting to the same pins as leaflabs maple
press reset and the user led should blink quickly 6 times
if this can be observed, it’d at least confirm that the bootloader is successfully installed and running properly

there is a strange feeling that either the boot loader isn’t correctly installed or that some errors cause the boot loader to crash on the board, there could be various hardware / software related reasons, e.g. HSE external crystal running at a different frequency or the board is wired differently etc
for the next part i’m only familar with linux,

in linux run lsusb
http://www.stm32duino.com/viewtopic.php … dfu#p25536
if you see 1eaf:0004 when running lsusb command this is the normal running mode (your sketch is installed and running)
if you see 1eaf:0003 when running lsusb that is maple in ‘perpetual bootloader mode’ ready to load the sketch
i’m not sure how to diagnose the same / tell if device 1eaf:0003 or 1eaf:0004 is connected, in windows, any suggestions?

found a useful link in windows (XP i think) , in device manager 1 could check the VID / PID of a device connected
http://xpenology.me/how-to-see-the-valu … pid-stick/
if no device drivers are hooked up, it would most likely show as an unknown device

seeing these vid : pid would confirm that (1) the bootloader is successfully installed and running (2) usb is working as expected

then the remaining parts is to figure out / install the windows usb driver stack and the config vid/pid so that windows can detect it correctly as usb-serial or dfu device


Leave a Reply

Your email address will not be published. Required fields are marked *