WIP: New platform: WeActStudio.BluePill-Plus-GD32 #2071

ALTracer commented 2025年02月09日 17:17:18 +01:00 (Migrated from github.com)

Detailed description

• This is a whole new cleaned up platform.
• The existing problems are mismatching LED pins and incomplete mappings of board features between stlink/swlink and bluepillplus. In-tree platforms default to 72 MHz and do not leverage full potential of Gigadevices. Unmapping own SWJ-DP is not always acceptable, and stlink pinout is just weird.
• This PR solves that by providing all necessary bindings in a dedicated platform, with chip detection and PLL configuration.

I do not expect this to be merged, because in-tree -Dprobe=bluepill already does provide some functionality. I do not implement vanilla PC13 bluepills, it's impossible for me to discern these from bluepillplus. This platform has feature parity with blackpill-f4, except I'm dissatisfied with its USBOTG-FS DWC2 bugs.
Choice of USART for Aux and SWO was influenced by existing 2x128 aux_serial DMA ping-pong buffers, which are insufficient for 1024 byte Zmodem packet operation I need in DUT firmware. So SWO is faster for burst operation. When that's refactored, I'll swap them back such that 6Mbaud VCP is possible.

TODO: I'd like to use platform_ident to indicate autodetection results, and to leverage meson options to pick linkerscripts which influence flash size for drivers and RAM size for heap/buffers/SWO.

Your checklist for this pull request

• I've read the Code of Conduct
• I've read the guidelines for contributing to this repository
• It builds for hardware native (see Building the firmware)
• It builds as BMDA (see Building the BMDA)
• I've tested it to the best of my ability
• My commit messages provide a useful short description of what the commits do

Closing issues

## Detailed description * This is a whole new cleaned up platform. * The existing problems are mismatching LED pins and incomplete mappings of board features between stlink/swlink and `bluepillplus`. In-tree platforms default to 72 MHz and do not leverage full potential of Gigadevices. Unmapping own SWJ-DP is not always acceptable, and `stlink` pinout is just weird. * This PR solves that by providing all necessary bindings in a dedicated platform, with chip detection and PLL configuration. I do not expect this to be merged, because in-tree `-Dprobe=bluepill` already does provide some functionality. I do not implement vanilla PC13 bluepills, it's impossible for me to discern these from bluepillplus. This platform has feature parity with `blackpill-f4`, except I'm dissatisfied with its USBOTG-FS DWC2 bugs. Choice of USART for Aux and SWO was influenced by existing 2x128 aux_serial DMA ping-pong buffers, which are insufficient for 1024 byte Zmodem packet operation I need in DUT firmware. So SWO is faster for burst operation. When that's refactored, I'll swap them back such that 6Mbaud VCP is possible. TODO: I'd like to use `platform_ident` to indicate autodetection results, and to leverage meson options to pick linkerscripts which influence flash size for drivers and RAM size for heap/buffers/SWO. ## Your checklist for this pull request * [x] I've read the [Code of Conduct](https://github.com/blackmagic-debug/blackmagic/blob/main/CODE_OF_CONDUCT.md) * [x] I've read the [guidelines for contributing](https://github.com/blackmagic-debug/blackmagic/blob/main/CONTRIBUTING.md) to this repository * [x] It builds for hardware native (see [Building the firmware](https://github.com/blackmagic-debug/blackmagic?tab=readme-ov-file#building-black-magic-debug-firmware)) * [x] It builds as BMDA (see [Building the BMDA](https://github.com/blackmagic-debug/blackmagic?tab=readme-ov-file#building-black-magic-debug-app)) * [x] I've tested it to the best of my ability * [x] My commit messages provide a useful short description of what the commits do ## Closing issues

ALTracer commented 2025年07月13日 16:51:49 +02:00 (Migrated from github.com)

This now supports 96 MHz APM32F103CB.
As well as classic 72MHz STM32F103CB, 96MHz GD32F103CB and 120MHz GD32F303CC (Cortex-M4), differentiating on CoreSight ROM table PIDR value. Unique ID in DESig is not exactly helpful, but serialno.c still works.
All four WeActStudio.BluePill-Plus-* boards have identical PCB, with LED on PB2 active-high, and button on PA0, USB FS device on type-C port, and 8 MHz crystal. All four chips lack USB DFU bootloader capability, only USART1 is supported for initial flashing, if you don't have another USB-SWD/JTAG adapter.
CH32F103C8 not considered due to insufficient Flash capacity.

This now supports 96 MHz APM32F103CB. As well as classic 72MHz STM32F103CB, 96MHz GD32F103CB and 120MHz GD32F303CC (Cortex-M4), differentiating on CoreSight ROM table PIDR value. Unique ID in DESig is not exactly helpful, but serialno.c still works. All four WeActStudio.BluePill-Plus-* boards have identical PCB, with LED on PB2 active-high, and button on PA0, USB FS device on type-C port, and 8 MHz crystal. All four chips lack USB DFU bootloader capability, only USART1 is supported for initial flashing, if you don't have another USB-SWD/JTAG adapter. CH32F103C8 not considered due to insufficient Flash capacity.