Oh I see, I overread this.
After reading through the schematics I’ve expanded the example because that board definitley needs a different clock initialization function (12MHz crystal instead of 8MHz clock-in signal). There’s now an
octopus environment in the
platformio.ini for the board (selectable via the project environment switcher as always).
I’ve also added the build flags and code to use the USB serial by default (
SerialUSB), redirected the UART output (
Serial) to the pin header for the Raspberry Pi (has TX2 and RX2 on it), and changed the blink LED to PA13. Though you have to be careful with the PA13 pin when using an SWD programmer like an STLink to program the board, PA13 is also the SWDIO programming signal… if the firmware reconfigures that pin to be a GPIO output, you will probably need to connect the NRST line from the MCU to the programmer to and make it use a hardware reset (possibly needing a change in the OpenOCD board configuration), otherwise programming is possible.
And in fact the board features a standard
USB-A USB-C connector (“USB2”) which is connected to the MCU. So, if you reset the MCU into bootloader mode (set the BOOT0 jumper and press reset once, USB-DFU open on USB pins PA11 and PA12 which goes to the USB-C connector), the MCU is flashable via its built-in USB DFU bootloader. PlatformIO also supports programming via that (
upload_protocol = dfu in the
dfu-util). So, you should be able to upload a firmware via that, get the board to blink and get serial output via the USB Serial opened by the board, even without a SWD programmer.
Though if you want to live-debug the board, a SWD programmer is preferrable. Mind the PA13 caveat though.
Edit: Corrected USB pins – there are two USB connectors on the board, both go the MCU, but only the USB-C connector is used by the USB-DFU bootloader.
Edit 2: If USB DFU upload is not working, it may be due to wrong USB VID/PID information in the board manifest .The bootloader mode document only talks about the PID being 0x0421 for STM32F446xx devices, but not about the VID. Looking it up in a database reveals VID = 0x0483, but for DFU devices STM32CubeProgrammer autofills
0xDF11. The tuple may still be switched (PID / VID switched around), or the values might be wrong. Use the STM32CubeProgrammer and see if it can connect to the chip via DFU, and what VID/PID it shows.