Correction about the Flash Zero-Wait on GD32F103

[tomli at tomli.me]

Hello.

In the email I sent in Feburary,

    https://lists.gnupg.org/pipermail/gnuk-users/2018-March/000021.html

I described the operation of the flash memory of GD32F103 as,

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

Now it turned out to be a complete mistake. I confused and
mixed the datasheet of GD32F103, and GD32F130, whith is another
series of low-cost microcontroller based on Cortex-M3.

In fact, page 22 (physical page 46) of the GD32F1x0 datasheet reads,

> Up to 64KB of on-chip flash memory for storing instruction/data
> No waiting time within 32K bytes when CPU executes instruction
> A long delay when fetch 32K ~ 64K bytes date from flash

But page 44 of the GD32F10x datasheet reads,

> Up to 3072KB of on-chip flash memory for instruction and data.
> No waiting time within first 256K bytes when CPU executes instructions.
> A long delay when CPU fetches the instructions out of the range.

In conclusion, while the flash memory of GD32F130 only has
zero-wait access within the 32 KiB range, the flash memory
of GD32F103, the chip we are testing, should have complete
zero-wait access within the range of 256 KiB, which essentially
means the whole flash memory is zero-wait, since we are not
using high-density models.

Therefore, we should be able to use this chip without worrying
about incompatibility, or timing attacks.

Sorry for the previous misinformation.

BTW, I have confirmed on my board that the updated Chopstx and Gnuk
is indeed working correctly. Thanks for your hard-work. I guess it's
the right time to upstream the OpenOCD patches for GD32 development.

Happy Hacking,
Tom Li

Beijing GNU/Linux User Group
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 851 bytes
Desc: Digital signature
URL: <https://lists.gnupg.org/pipermail/gnuk-users/attachments/20180815/e9d4dbc2/attachment.sig>