windowsdriverstm32micropythonstm32cubeide

Why is my STM32F407 not being recognized by the computer (Windows 10)?


Overview

Here is what I found

I found this question [1] where Device Manager reads the STM as Disk drives/STM32. My PC identifies it as mass storage and portable devices on Windows 10 Pro. When in DFU mode, I can see it as Universal Serial Bus Device/STM32 BOOTLOADER in Device Manager.

The tutorial [2] uses the Flash Loader Demo, and this older tutorial [3] uses STSW-STM32080, but both of the drivers are tagged as obsolete on the ST website. STM32CuberProgrammer is indicated instead, but I would like to flash and debug directly from the IDE. Another forum reply [4] says that "you need a ST-LINK V2 programmer to program the brand new chip".

In summary

I can see the solution being one of the following options:

  1. correct answer: I need to use the ST-LINK-V2 to program from the IDE and that's the only way
  2. I need to flash a bootloader via STM32CubeProgrammer to get it to work via IDE (is there a standard code for this?)
  3. I have to build the cross-compiler for MicroPython [5] before I get to program it in C

Is there a solution? Are there another driver or idea that I might be missing?


Update

I went on and got my hands on a ST-LINK V2. I made the connection via the JTAG/SWD connector (see schematic), and I also tried connecting directly with the pins:

ST-Link JTAG/SWD Pins
SWCLK 9 PA14
SWDIO 7 PA13
GND 10 GND
3.3V 1 3.3V
RST 3 PB4

The ST-Link is not recognized. The ST-LINK blinks and the board is powered up, but that's it. Device Manager before and after) shows the same.

So I went on checking if I was missing any new driver/program. I installed the STSW-LINK004 (STM32 ST-LINK Utility v4.6.0.0) based on these instructions, but without any luck, and Utility cannot find it either. I've reset the computer after each driver installation. If I connect my board via USB in DFU mode, it is still recognized as STM32 BOOTLOADER, but if I do it with the ST-Link, nothing changes.

Updated solution

It turned out the ST-LINK was faulty and therefore not connecting. After finding another ST-LINK V2, the computer can recognize the board under Universal Serial Bus devices/STM32 STLink.


Solution

  • Debugging with STM32CubeIDE will always need an ST-LINK or other JTAG or SWD debug probe.

    The bootloader allows you to program the microcontroller with a binary image, and that's it. The IDE will happily produce such a binary image, and possibly even have a wizard for transferring it via DFU. But that's only programming, no debugging. And only be when the bootloader is running. If you did debug-like things like reading RAM contents, you'd get what the bootloader stores there while it is running, not the variables that your own program uses.

    The ROM bootloader supports several ways of receiving new code to flash—USB (DFU), CAN, I²C, SPI, and UART. That last is not a USB virtual COM port; it is an honest-to-God UART using the USART peripheral in the microcontroller and RX/TX pins.

    If you want a virtual COM port for your custom firmware to use to send data to the PC, you have to program the USB peripheral.