Official GD32 demo boards

Boards based on the GigaDevices GD32F103 microcontroller
User avatar
Pito
Posts: 1119
Joined: Sat Mar 26, 2016 3:26 pm
Location: Rapa Nui

Re: Official GD32 demo boards

Post by Pito » Fri Mar 10, 2017 10:23 pm

SPIx - yes as I wrote above it is a "none listed SPI".
The GD's "program RAM" addresses are the flash addresses in the STM.
The GD's "flash" has no addresses as it is accessed via SPIx (via a standard serial flash protocol).
The GD's RAM addresses are the RAM addresses in the STM.
There could be a code (around the GD's uart bootloader code??) messing with SPIx <-> "program RAM" transactions.
Assumptions only...
PS: most probably you want to find a none-listed gpio pin for SPIx' chip select.. That could be done such you toggle hidden pins and measure the current consumption of the GD chip. When low and the current increases say by 10mA it is the flash..
Last edited by Pito on Fri Mar 10, 2017 10:51 pm, edited 1 time in total.
Pukao Hats Cleaning Services Ltd.

victor_pv
Posts: 1261
Joined: Mon Apr 27, 2015 12:12 pm

Re: Official GD32 demo boards

Post by victor_pv » Fri Mar 10, 2017 10:46 pm

I would think it uses a dedicated port, perhaps accessible as spi3, or perhaps in some other range of addresses.
So we know there is a flash die, and we know the code is copied to a RAM block upon boot up.

I think the question to answer first would be: Is some code in the MCU run to do that copy, or is it dedicated hardware that does it?
If it is code in the MCU, then both the flash device and the RAM where the program is copied may be accessible to software.

From reading the datasheet, I found this address with a "System Configuration Register". I could not find what "code execution efficiency" exactly does, but for some reason I suspect it has something to do with that flash to ram copy.

Code: Select all

Base address: 0x4002 103C

Bits Fields Descriptions
7 CEE Code execution efficiency
0:Default code execution efficiency。
1:Code execution efficiency enhancement

NOTE:
1. Only bit[7] can be read-modify-write, other bits are not permitted.
2. Only GD32F10xC/D/E/F/G/I/K can be configured as Code execution efficiency enhancement mode
In the stm32 bootloader we write to flash from MCU code. Has anyone ever tried the bootloader in a GD32 device?
And I dont know if it was on this forum or where, someone mentioned that after writing to flash in a GD32 you need to reboot the device. If that is the case, then writing to flash only writes to flash, not to the ram copy, and that's why it needs to be rebooted, to reload it. The datasheet doesn't say anything about that, so probably not correct.

Also, even on stm32 before you write to flash there is a number of registers that need to be set a certain way, unlock the flash, etc. There is a programming manual for the STM32 that describes it all, separated from the normal reference manual.
If there is something like that for the GD32 may shed some light.

EDIT: I wrote too fast, there is indeed something about the flash in the GD32 reference manual, and this interesting paragraph in page 52:
No waiting time within first 256K bytes when CPU executes instructions. A long delay
when CPU fetches the instructions out of the range.
Makes me believe the device has up to 256KB of ram for the caching, and there is dedicated hardware to control all that. I wonder how long is the delay to fetch instructions out of the range, may load them in 2KB pages at a time or who knows. Doesn't say if only the first access out of the range required a long delay, or every instruction, or once the second block is accessed after the delay, there is a long delay if the code jumps back to the first 256KB...

User avatar
Pito
Posts: 1119
Joined: Sat Mar 26, 2016 3:26 pm
Location: Rapa Nui

Re: Official GD32 demo boards

Post by Pito » Fri Mar 10, 2017 11:07 pm

That is maybe for the large GD devices with 3MB of flash, as they are not able to produce 3MB of program RAM (but max 256k).
For those small chips the flash:progRAM is 1:1.
As a first step I would try to identify the CSelect of the external flash. By toggling the hidden gpio pins and measuring the Vdd current. When gpio low it should increase by 5-10mA.
Last edited by Pito on Fri Mar 10, 2017 11:13 pm, edited 1 time in total.
Pukao Hats Cleaning Services Ltd.

victor_pv
Posts: 1261
Joined: Mon Apr 27, 2015 12:12 pm

Re: Official GD32 demo boards

Post by victor_pv » Fri Mar 10, 2017 11:13 pm

Pito wrote:That is maybe for the large GD devices with 3MB of flash, as they are not able to produce 3MB of program RAM.
For those small chips the flash:progRAM is 1:1.

From the manual, seems like up to the devices with 256KB of flash, they have 1:1 to RAM. But I bet the way of preloading and accessing that memory is exactly the same, just in the smaller devices there is never a need to fetch pages from a different area since all fit in RAM.
If you have one of those, have you tried looking at the embedded bootloader?

User avatar
Pito
Posts: 1119
Joined: Sat Mar 26, 2016 3:26 pm
Location: Rapa Nui

Re: Official GD32 demo boards

Post by Pito » Fri Mar 10, 2017 11:14 pm

I do not have any GDs.. How you can look at the eternal bootloader? Is it readable?
Pukao Hats Cleaning Services Ltd.

victor_pv
Posts: 1261
Joined: Mon Apr 27, 2015 12:12 pm

Re: Official GD32 demo boards

Post by victor_pv » Sat Mar 11, 2017 1:17 am

Pito wrote:I do not have any GDs.. How you can look at the eternal bootloader? Is it readable?
It's in a section of the memory address space, so you can read it with a debugger probe or from software running in the MCU.

User avatar
RogerClark
Posts: 5943
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: Official GD32 demo boards

Post by RogerClark » Sat Mar 11, 2017 4:48 am

@victor

Re: Bootloader

It worked without any major changes, I just had to change the PLL multipler as the GD32 boards I have, use a 12Mhz crystal instead of 8Mhz

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest