Fresh-from-factory initialization of GD32F450

[SpacedCowboy]

I'm considering replacing the RP2040 in a design of mine, which I was using as a system controller, and one of the prime benefits is that by simply exposing a button for the user to hold down (which drags the QSPI /CS line low), the chip behaves like a USB flash drive, drag a .UF2 file there, and you just un-bricked anything that was bricked or updated to the latest firmware. Easy.

So, in this design I'd like more pins than an RP2040 provides - a lot more and they have to be fast to drive an LCD display. I'm considering the GD32F450 in the BGA176 package, but I can't seem to figure out if it's possible to do something similar to what the RP2040 offers. The GD chip does have more on offer (no need to max the SPI busses, no need for the current i/o expander, no need for the flash chip or crystal, more SRAM...) so it becomes only slightly more expensive than laying down a whole new RP2040, and gives me more flexibility

I don't specifically need the flash-disk functionality, C source or library code would do, but I would like the ability to install firmware using the built-in boot loader without having to place anything there myself first. It seems from reading the data sheet that the built-in GD boot loader does support USB firmware install (yay!) but I can't find mention of the protocol it uses (boo!), and the binary they offer to get it out of DFU is Windows-only (which doesn't suit, I'm intending this design to be cross-platform).

So has anyone had any experience getting the GD32F4 chips to boot into USB-capable DFU and burn new firmware in without needing to use the Windows DFU-loader ? Yesterday I pinged the support contact that mon2 mentioned, but he's maybe busy, or timezones haven't aligned or something, so I thought I'd ask here too

[thm_w]

What do you mean by "Without needing to use the windows DFU-loader"?
You'll need some DFU software to program the device, linux or windows.

https://e-iot.info/e-iot-platform-hardware-software-manual/chapter-t-04.html
https://github.com/riscv-mcu/gd32-dfu-utils

If you want drag and drop, then you'll need a custom mass storage device bootloader. It looks like RP2040 is using UF2, there are some STM32 UF2 implementations.

[SpacedCowboy]

The RP2040 has a built-in boot loader that implements the sequence "instantiate the device as a flash drive, wait for UF2 file, flash QSPI, reboot", which is triggered by holding QSPI /CS down on boot. This boot loader is built into the ROM of the chip, so it's always there, and can't be bypassed or subverted - hold down the button and provide the UF2 - simple.

The only mention I can find of the boot loader on the GD32F450 is in the GD32F450xx_Datasheet_Rev2.2.pdf document:

The boot loader is located in the internal 30KB of information blocks for the boot ROM memory (system memory). It is used to reprogram the Flash memory by using USART0 (PA9 and PA10), USART2 (PB10 and PB11, or PC10 and PC11), and USBFS (PA9, PA10, PA11 and PA12) in device mode. It also can be used to transfer and update the Flash memory code, the data and the vector table sections. In default condition, boot from bank 0 of Flash memory is selected. It also supports to boot from bank 1 of Flash memory by setting a bit in option bytes.

So it seems you can download via USB, and you can do it using the built-in boot loader (by setting the boot pins, which could be done in the same way as the RP2040, holding a button down on power-up), but it's not clear *how* to talk to it, or whether it does enumerate as a flash disk like the RP2040 (I doubt this is the case or they'd probably mention it). What would be good to know is whether my own cross-platform code can scan for a device in DFU and then send it data.

I mean, I could slap a USB analyzer on the link, and record the process of using the Windows DFU loader (which presumably does this exact thing) but it'd be nice if I didn't have to, and there was some documentation somewhere, or (even better ) some code...

If the only option is that you have to use a Windows DFU pre-built binary, then the chip isn't an option for me, and I'd prefer not to go down the analyze-the-bus-traffic for the simple reason that I'd have to buy a USB analyzer

If that second link is generic, and the DFU mode works to a standard protocol, that's awesome, I can crib from the code and get what I need

[thm_w]

Yes the DFU bootloader protocol is relatively generic
http://dfu-util.sourceforge.net/