STM32 Black pill not showing COM port in Windows nor Linux

[SpareFag]

Hello gang,

I'm trying follow this tutorial to print hello world on a PC console: https://www.bennettnotes.com/notes/stm32-blackpill-with-stmcubeide-usb-serial/

Everything works well except the COM port doesn't show on Windows, hence I cannot connect to Putty. I trying entering incremental port numbers (COM1, COM2 etc), but still nothing. I correctly installed the firmware for my ST Link V2, as well as this one :https://www.st.com/en/development-tools/stsw-stm32102.html

I also tried on Linux, but not tty available as well. Any advice please?

[pcprogrammer]

Did you try to see if the DFU port shows up when you reset the board while holding the BOOT button.

This will ensure the USB connection to the PC is working.

I did not read what is on the page you linked, but what I normally do when developing on boards like these is to blink the led on C13 in some part of the program to show it is at least running my code.

So if it is not in the project, try to add it your self.

[SpareFag]

I did try the bliking, with different delays, and it worked just fine. The next project I intend to make requires me to send data to and from a console on my PC, and that's where the missing COM port is annoying.

[darkspr1te]

Hello gang,

I'm trying follow this tutorial to print hello world on a PC console: https://www.bennettnotes.com/notes/stm32-blackpill-with-stmcubeide-usb-serial/

Everything works well except the COM port doesn't show on Windows, hence I cannot connect to Putty. I trying entering incremental port numbers (COM1, COM2 etc), but still nothing. I correctly installed the firmware for my ST Link V2, as well as this one :https://www.st.com/en/development-tools/stsw-stm32102.html

I also tried on Linux, but not tty available as well. Any advice please?

In your code do you have the required USB handles and MX_USB_Iinit in your main.c ? without those your blink will still work but USB serial will not.
You can also add checks to the usb code to confirm the system has usb operation.



darkspr1te

[pcprogrammer]

Trying to debug the USB code on the other hand will not work. Setting breakpoints in USB code leads to timeouts on the side of the host and things won't work.

Best approaches to testing USB is using a tool like wireshark to track the packets. On the device side toggling IO pins from within the interrupt routine(s) and check them with a scope can be very helpful.

But that is probably ahead of schedule judging by the original posters question and information given.

[pcprogrammer]

I have a couple of these WeAct STM32F411 boards myself and are trying the DFU boot on a linux machine and it does not show up as an USB device. So my first advise probably was not helpful, at least on linux. No idea if it works on Windows.

If I just plug it in and let the default code the board came with start it does show up as a boot loader device.



I don't have the STM IDE installed so no testing of that part.

[pcprogrammer]

Did some reading of the documentation and to make the DFU boot work pin B2 has to be at ground level. It is a bit unfortunate that the makers of the board did not add a pull down resistor on this pin. 10K would have done the trick.

I just shorted it to ground for testing it.

Now it shows up as an USB device as can be seen in the "lsusb" listing.

[langwadt]

Did some reading of the documentation and to make the DFU boot work pin B2 has to be at ground level. It is a bit unfortunate that the makers of the board did not add a pull down resistor on this pin. 10K would have done the trick.

I just shorted it to ground for testing it.

Now it shows up as an USB device as can be seen in the "lsusb" listing.

if it is the usual "blackpill" boards it should go into DFU mode if you reset while pressing the boot button and if not it'll run in normal mode

[pcprogrammer]

Well I have tried that, did I not?

The problem is that the BOOT1 pin also has to be 0, otherwise it will start execution from user RAM.

In my first test the pin B2 (BOOT1) was not connected and thus floating and detected as a 1. Tried it several times, no DFU mode running. Connected it to ground, wham, first try DFU mode running.

Edit: So either my boards are some clones not having a pull down resistor, or there is to much EMC radiating from my monitors and computer that the B2 pin is seen as 1. I have a couple of these boards from two different Aliexpress vendors, and they all react he same.

[langwadt]

Well I have tried that, did I not?

The problem is that the BOOT1 pin also has to be 0, otherwise it will start execution from user RAM.

In my first test the pin B2 (BOOT1) was not connected and thus floating and detected as a 1. Tried it several times, no DFU mode running. Connected it to ground, wham, first try DFU mode running.

Edit: So either my boards are some clones not having a pull down resistor, or there is to much EMC radiating from my monitors and computer that the B2 pin is seen as 1. I have a couple of these boards from two different Aliexpress vendors, and they all react he same.

the original schematic shows a pulldown, https://stm32-base.org/assets/pdf/boards/original-schematic-STM32F411CEU6_WeAct_Black_Pill_V2.0.pdf

[pcprogrammer]

Thanks for the schematic. 

I checked one of my boards and I will be dammed, the resistor is there. My multi meter shows 9.996Kohm to ground. But still all three of the boards I have need tying the B2 pin to ground to get the DFU mode operational.  (The other two don't have the pins soldered yet, so no bad solder joint.)

Go figure

One of my boards has v3.0 written on the bottom silk screen

[DavidAlfa]

Yeah for some reason it doesn't work well when cold?
I often had to heat the stm32 with my finger for few seconds, then it worked. Very weird.
Then I started to use the st-link.

Weact explains this here, saying the issue comes from other stores copying their product and using very old stm32 batches.

Mine is revision A, date code 034, apparently from mid-August 2010. Or could it be 2020? Using a single number for the year is just stupid.
Weact says they use new chips, not old stock.

[wek]

Yeah for some reason it doesn't work well when cold?

It sounds like consequence of using 25MHz crystal for HSE on that board:

Note: Due to HSI deviation and since HSI is used to detect HSE value, the user must use low
frequency rather than high frequency HSE crystal values (low frequency values are better
detected due to larger error margin). For example, it is better to use 8 MHz instead of
25 MHz.

JW

[pcprogrammer]

Mine is revision A, date code 034, apparently from mid-August 2010. Or could it be 2020? Using a single number for the year is just stupid.
Weact says they use new chips, not old stock.

Two of my chips have 024, so a bit older then yours? The other chip shows 537 so September 2015?

Ah well, I also use ST-link to program, so no biggie.

[wek]

Mine is revision A, date code 034, apparently from mid-August 2010. Or could it be 2020? Using a single number for the year is just stupid.

Two of my chips have 024 [...]

2020. The 'F4 has been introduced in 2011 with the 'F405/407/415/417, then followed the 'F42x/43x. The "junior line" of 'F40x/'F41x/'F42x (wich x<=3) came somewhat later, maybe 2013-2014.

Yes, the single-digit year is stupid, but then users are not really supposed to chew on the manufacturing date/trace codes etc.

To return to OP's question, can somebody who has the blackpill please test whether
stm32serial.bin from https://github.com/DaveBben/STM32F411_Blackpill_Serial_USB_CDC_Example/tree/main/Debug does work as expected?

JW

[pcprogrammer]

Yeah for some reason it doesn't work well when cold?

It sounds like consequence of using 25MHz crystal for HSE on that board:

Note: Due to HSI deviation and since HSI is used to detect HSE value, the user must use low
frequency rather than high frequency HSE crystal values (low frequency values are better
detected due to larger error margin). For example, it is better to use 8 MHz instead of
25 MHz.

JW

I don't see this being the problem, because the HSE is only used for the USB connection. The detection of the boot mode has already been done before it even gets to the switch to the HSE clock.

Sure I did not check if it enters boot mode and fails on USB or tries to boot from user ram, but it working when B2 (BOOT1) is actually grounded makes me believe it is the latter.

My boards do have 25MHz crystals or oscillators, where I expected 8MHz since that is what is used on most of these small boards, but thinking about it reaching 100MHz from 8MHz is maybe not possible with the PLL in these devices? So thanks for pointing that out.

To return to OP's question, can somebody who has the blackpill please test whether
stm32serial.bin from https://github.com/DaveBben/STM32F411_Blackpill_Serial_USB_CDC_Example/tree/main/Debug does work as expected?

Maybe tomorrow.

[pcprogrammer]

Programmed one of my boards with the stm32serial.bin file from https://github.com/DaveBben/STM32F411_Blackpill_Serial_USB_CDC_Example/tree/main/Debug and it works.

All it does is spit out "Hello World" over and over again.

On my linux mint machine the device shows up as "/dev/ttyACM0", provided it is the first device of that type connected to the system.

[rooppoorali]

Are you sure that it's not a bad board?

[SpareFag]

Programmed one of my boards with the stm32serial.bin file from https://github.com/DaveBben/STM32F411_Blackpill_Serial_USB_CDC_Example/tree/main/Debug and it works.

All it does is spit out "Hello World" over and over again.

On my linux mint machine the device shows up as "/dev/ttyACM0", provided it is the first device of that type connected to the system.

Did you do anything special for it to work?

Are you sure that it's not a bad board?

I don't think so. when I type dmesg -w then plug the ST Link, I get a notification on the console that it has been plugged in Any way to check if the board is faulty?

[pcprogrammer]

No nothing special. Just downloaded the binary and used ST's programming software to load it to the FLASH. Used a Chinese ST-link V2 clone to connect the board.

Used default settings "et voila" it worked.

Testing the board can be done as described in the other responses here, by making it go into DFU boot. Ground pin B2 and press the boot and reset button. Let go of the reset button and after a while let go of the boot button. It should show up on the computer like shown below.



Edit: To check if the FLASH of the board is OK you can use the verify option when programming. I used this software: https://www.st.com/en/development-tools/stm32cubeprog.html

[SpareFag]

No nothing special. Just downloaded the binary and used ST's programming software to load it to the FLASH. Used a Chinese ST-link V2 clone to connect the board.

Used default settings "et voila" it worked.

Testing the board can be done as described in the other responses here, by making it go into DFU boot. Ground pin B2 and press the boot and reset button. Let go of the reset button and after a while let go of the boot button. It should show up on the computer like shown below.



Edit: To check if the FLASH of the board is OK you can use the verify option when programming. I used this software: https://www.st.com/en/development-tools/stm32cubeprog.html

Forgot to ask: how did you know your port was ttyACM0? And which software did you use to connect the console to it?

[pcprogrammer]

Under linux USB to serial devices mostly use either ttyUSBx or ttyASMx under the device tree, where x depends on the number of devices connected. The first USB to serial device will be at ttyUSB0 or ttyASM0, the next one on ttyUSB1, etc.

A simple check is done with "ls /de/ttyUSB*" or "ls /dev/ttyASM*" to see which serial device is connected.

I used cutecom to connect to the port, but there are lots of terminal programs one can use.

[SpareFag]

One final question (I hope). It's my first experience with STM32, so do you know where I can find instructions to load the .bin file to the flash?

[pcprogrammer]

Maybe this can help:



or check the manual: file:///tmp/mozilla_peter0/dm00403500-stm32cubeprogrammer-software-description-stmicroelectronics.pdf