Why is DFU alt=0 name @Internal Flash /0x08000000/512*002Kg'?

dfu-util lists 2 entries, Option Bytes and Internal Flash.

What does 512*002K mean in 0x08000000/512*002Kg for Internal Flash?

I read this as 1024K, but internal flash is 128K. The Option Bytes name makes sense: 1*16 for 16 bytes at 0x1ffff800.

$ dfu-util -l
Found DFU: [28e9:0189] ver=1000, devnum=5, cfg=1, intf=0, path="1-2", alt=1, name="@Option Bytes  /0x1FFFF800/01*016 g", serial="??"
Found DFU: [28e9:0189] ver=1000, devnum=5, cfg=1, intf=0, path="1-2", alt=0, name="@Internal Flash  /0x08000000/512*002Kg", serial="??"

This is a bug with the GD32V’s bootloader and it’s the reason that upstream dfu-util doesn’t work to flash the device. You can see how this entry is supposed to be parsed by reading the dfu-util source: 512 is the number of pages and 002K (=2048) is the page size. Multiplying this out, you get a memory size of 1MB, which is obviously incorrect. The Nucleisys version of dfu-util has been patched to ignore the information reported by the bootloader and instead use a page size of 1024 and a page count of either 64 or 128, depending on the part number.

1 Like

FYI, upstream dfu-util now works with the GD32VF103 if you compile it from source. (There’s no release that contains the fix yet.) I wrote a much cleaner version of the patch from Nucleisys, which was accepted four months ago. I thought I’d mentioned it in another thread here, but that seems to have been deleted.

1 Like