Status Update: Initial Experiments with the GD32 chip
gniibe at fsij.org
Thu Mar 1 02:58:51 CET 2018
tomli at tomli.me wrote:
> I got a new working ST-Link programmer and did some experiments on this GD32
> chip in this week.
Thanks a lot for sharing your experience. It is quite interesting.
Could you please confirm two things.
(1) Zero-wait state access to flash
(2) 16-bit halfword access in flash programming
According to my reading of the GD32F103x User Manual, both are
supported (in the section 2. Flash memory controller).
> 1. Because the property of the underlying flash technology by GigaDevice,
> the first 32 KiB of the flash is zero-wait for reading, but the writing and
> erasing of the chip is significantly much more longer than STM32, as a
> result, the programming software needs some modifications.
> The official application notes recommends:
> i) increase the erase timeout per page to 300ms,
> increase the mass erase timeout to 3s.
> ii) increase the program time per word to 2ms,
> increase the program time per page to 300ms.
While this is acceptable...
> In addition, the access time for data behind of first 32 KiB is slow,
> one should put timing-crtitial data at the beginning of the flash chip.
... This would be not. I thought as if internal SRAM copies full of
128KiB. I wonder how slow it is.. and/or if it is OK (in China)
advertising the chip as "zero-wait access" when it's only partially
If it's only for the first 32KiB, I would not like to use this chip...
Zero-wait is important for killing an attack vector of possible timing
> 2. The GigaDevice flash doesn't support "block write" mode, which is the
> default mode to program the flash on OpenOCD, further, OpenOCD will fall
> back to single halfword (16-bit) accesses when block write is not available,
> however, it's also doesn't work on this flash. The only known working mode
> on this chip is the 32-bit fullword access.
Currently, the use of data in flash by Gnuk (the data format) depends on
halfword size access.
We will need major change if 16-bit access is not supported.
> 6. I still have problem with USB enumeration and the chip cannot be
> recognized by the computer. Sometimes the USB CDC demo in chopstx
> works, sometimes it doesn't, Gnuk simply hangs.
It sounds like it's an issue (or two) of USB driver. I mean, software.
> I'm going to order and wait for the official development board and
> uses it as the reference platform for further testing, otherwise it's
> going to be clueless.
OK. Let's see.
Today, I find this one:
It seems it's from Shanghai. I'll try to find other.
More information about the Gnuk-users