Correction about the Flash Zero-Wait on GD32F103
tomli at tomli.me
tomli at tomli.me
Tue Aug 14 19:58:18 CEST 2018
In the email I sent in Feburary,
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.
Beijing GNU/Linux User Group
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 851 bytes
Desc: Digital signature
More information about the Gnuk-users