stm32f103 usb not working
Brought to you by:
m-atthias
Menu
▾
▴
Hi,
I've got some stm32 bluepill boards and wanted to use the "usb-terminal" version of mecrisp-stellaris on it. But after flashing it, the device is not recognized when plugged in via USB.
Linux kernel output says "Device not responding to setup address".
What I've tried:
- flashed some stm32 usb bootloader hex file, to make sure USB is not broken on my board. That worked as expected, so the hardware is ok.
- hooked up a logic analyzer to the USB pins. I can see the host computer sending setup packets, but no "ack" comes from the stm32. The computer retries a few times, resets the device and tries some more, but without success.
- searched the web for similar problems. Made shure a pullup resistor is connected to PA12 (it is, 1.5kOhm).
- tried the non-usb hex file of mecrisp, which works just fine. Loading the "usb-f1.txt" into that and resetting leads to the exact same non-working condition.
- tried an older version of mecrisp (2.4.7, which was mentioned in some discussion topic here as having "working usb"). also does not work.
- tried both "-ra" and non-"ra" variants of mecrisp, but no difference.
Any idea what might be going wrong?
Try mecrisp-stellaris-2.6.5/stm32f103-ra/precompiled/mecrisp-stellaris-stm32f103-with-usb-terminal.bin
That should work. The default is always a USART.
Cheers
Terry
Same result with that exact file:
If that works for others with "bluepill" boards, what hardware differences could be relevant here? I know there's a lot of "bluepill" clones out there, and counterfeit stm32f103. But on my bluepills, the IC markings look quite good and the exact part number at least doesn't match one known counterfeit version that I found online. I verified the pullup resistor on PA12, which some boards seem to be missing. The pinout can't be wrong as the chip doesn't allow changing the USB DP/DM lines, so if it can work sometimes (as with the bootloader hex file), then it must be connected correctly to the USB port.
That's an easy question to answer : see my bluepill diagnostics at:
https://mecrisp-stellaris-folkdoc.sourceforge.io/bluepill-diags-v1.640.html
Nice! Of course it wasn't as straightforward as the manual said, because the image uses the USB interface that doesn't work. But trying out bits of the source code, I find:
- jdec-ident-code = 0 (not stm32)
- DBGMCU_IDCODE != 0 (can be read, not affected by stm32 erratum)
- flashsize reported as 256k (not 64k with additional hidden 64k)
So it's a counterfeit chip. Which was to be expected, I suppose. Going to try my soldering skills to replace the ICs.
Did you see that there is a SWD terminal selected by PA0 connected to Vcc ? This enables SWDCOM over SWD pins, so no usart needed.
I included this option if USB wont work, and I use it for in house development pf that project.
https://mecrisp-stellaris-folkdoc.sourceforge.io/bluepill-diagnostics-v1.6.html#optional-swdcom-terminal
Don't discount the Chinese clones, they're faster, cheaper and have no silicon faults, compared to the STM32F103 origonal chip.
if it runs mecrisp-Stellaris, the SWDCOM terminal will show it with the forth prompt. Maybe that mcu just doesn't have USB ?
Regarding the chinese clones: My thought is that basically I have a chip without a datasheet/manual. It "mostly" does what the official stm32 docs say, but there are differences that I only find out about once I accidentally run into them. And I guess I can't ever get a "completely correct" datasheet/manual for the chip, or any errata. This makes it hard to work with (exhibit a: the original post in this thread). I'd rather work with chips where I know any problem I run into is my own fault for not understanding/following the docs. And I can solve those by reading the docs.
SWDCOM looks interesting, but I'm also interested in playing around with USB in mecrisp (not only for console, but also emulating keyboards, multiple endpoints). So that's not a workaround I would like.
As the STM32duino bootloader hex file worked fine (bluepill was detected as a USB device), I'm sure the clone does have USB support, but just differs from the original in some way. Maybe I'll try to implement USB just like that bootloader did, but for now I'll use the blackpill board I also have lying around (stm32f411, the "usb-f4.fs" implementation works on that one).
To a great extent, mecris-Stellaris Forth makes docs less important due to the REPL. One can just try stuff and see what happens in the traditional Forth development way.
That the big advantage of SWDCOM because the Bluepill diags are actually a Forth development system under the hood, with a lot of tools for you to use, such as some register printouts.
Of course SWDCOM may not work if the diags binary doesn't run,
If it does run on SWDCOM 'words4' will print out the massive forth resources now on that chip.