Status Update: Initial Experiments with the GD32 chip

[NIIBE Yutaka]

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
(quarter) true.

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
attack.

> 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:

   https://www.tindie.com/products/maxtch/sushibits-arm-development-kits/

It seems it's from Shanghai.  I'll try to find other.
--