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

Overview

I need to program a recently purchased STM32F407ZGT6 board
In 'normal mode' my computer doesn't recognizing the board as a Ports (COM & LPT)/STMElectronics Virtual COM Port when connected via USB (I'm using a Windows 10 Pro). The LEDs turn on and I can get it into 'DFU mode'. When I try to debug the code, I get the "No ST-LINK detected!" message in either mode.
This is my first time connecting the board and also my first time dealing with STM32
Despite the instructions, I want to program the board using C directly from the STM32CubeIDE

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 on Device Manager.

The tutorial [2] uses 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:

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

What are your thoughts? Any other driver or idea that I might be missing?

CodePudding user response：

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, I2C, SPI, UART. That last is not a USB Virtual COM port, it is 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.