GD32 – writing program ram

Hi, I’ve tried to find a datasheet but except a marketing document called datasheet I have not find any.
So my Q to a more lucky GD users – is it possible to write/read into the program ram (64/128kB)?
P.

What do you mean by program RAM ?

Do you mean the EEPROM or the few bytes of non volatile RAM

I doubt the GD32 is different from the STM32 in how you write to either, in fact the Bootloader , which writes to EEPROM is a direct copy of the STM32 bootloader.

If you mean non volatile RAM, I vaguely recall looking something on the forum about it, as it may have been useful for signalling from the sketch to the bootloader, but we never ended up using it for that, and I don’t think anyone else uses it.
But if anyone knows about NV RAM I think it would be @ahull

GD is a flashless chip.
There is a second one chip glued on top of the arm – a 128kB SPI flash, and the 8pin serial flash is bonded to the arm.
Upon boot the GD reads the SPI flash into the Program RAM – there is 128kB large “program RAM”.
It runs the program out of the program RAM then. Therefore 0 waitstates. And other implications too – ie writing to flash might be slow..

My Q is about writing/reading the 128KB Program RAM (not r/w to the external flash chip or 20kB ram).

Pito wrote:GD is a flashless chip. There is a second one chip glued on top of the arm – a 128kB SPI flash, and the 8pin serial flash is bonded to the arm. Upon boot the GD reads the SPI flash into the Program RAM – there is 128kB large RAM. It runs the program out of the program RAM then. Therefore 0 waitstates. And other implications too – ie writing to flash might be slow..
My Q was about the 128KB Program RAM.

We need a good RefMan for this, I cannot find any. Writing to the “program space” would most probably end with writing to the external flash. And maybe to the ram as well. Unless there is a “switch” for ram access only .. Thinking on bypassing the flash.. Would be great to have a GD32 chip without flash chip bonded. So I can load/store binaries out of an external SPI FRAM/SRAM/MRAM, or modify the program in prog_RAM on the fly…

Pito wrote:GD is a flashless chip.
There is a second one chip glued on top of the arm – a 128kB SPI flash, and the 8pin serial flash is bonded to the arm.
Upon boot the GD reads the SPI flash into the Program RAM – there is 128kB large “program RAM”.
It runs the program out of the program RAM then. Therefore 0 waitstates.

Yes, that was interesting when it came out :
http://zeptobars.com/en/read/GD32F103CB … ga-Devices

Yea, we discussed that a month ago in “How the chip works” topic..

I’ve recently been working with some flash chips, and if the flash in the GD32 is anything like the other flash i’ve seen so far, it won’t be as simple as writing to a certain memory address. To write to a section of the flash you have to clear it first (and this is thus not just the bits you want, it has to be at least a page), and then write the data you want (also usually page per page). On the 4Mb chip i have the page size is 256 bytes. and writing is pretty slow since clearing such a page takes 40ms.
Reading however is fast .

*edit*
i just read it’s mirrored to sram, that is indeed interesting XD

It is not even sure that the mechanics are available on CPU side, transfers could be done in hardware for both direction and RAM still been seen as emulated flash compatible with the STM one, in the case of F1xxx, with 1KB pages.

@pito

Thanks for enlightening me.

prior to your post, I thought it used zero wait state flash. (As I missed your other post and that link to the teardown of the die)

I recall posting a link to the GD32 programming manual to the forum, but I dont know if it contained information about access program ram.

Have you tried doing a test like declaring a const static char buffer, (which the compiler and linker would put in .rodata) and then attempting to write to it? I presume that the program RAM must be write protected ?

Also, the Bootloader writes to EEPROM, which must get copied back to Program Ram.
However, I presume you want fast access to the program RAM, without waiting for the flash to erase etc.

Edit.

The link in the original thread was broken, but I found I copy I’d downloaded and got its filename and then Googled for that filename and found this

http://gd32mcu.21ic.com/data/documents/ … ENV1.0.pdf

There STM32F103 manual is structured completely differently from the GD32 manual. So its hard to compare registers.

I recall ages ago, that there was a thread on a russian language website which outlined the differences between the GD32 and STM32 registers, but I don’t recall anyone realising that it actually copied the program into ram at startup.
(It would also need to copy after accessing the EEPROM straight after its been flashed)

Edit.

If you can’t manage to download the manual let me know and I’ll put it on my google drive, as its far far big (15Mb) to post as an attachment to the forum

Well I guess one approach would be to write a unique string to flash, then chase up the memory map from bottom to top, looking for all occurrences of that string. If the flash memory is indeed copied to RAM of some sort, and that RAM is mapped to address space, the string should show up in the memory map. You should therefore find the sting in at least two places. Once where the variable you are comparing with to do your search, and once where the flash copy appears in ram. You could also look for the checksum of the string, thus avoiding having a second copy anywhere. You would only then find the copy which we think will have been transferred from flash to RAM. You might need to watch out for endian-ness as you couldn’t be absolutely certain how the string would be represented, but my gut feeling would be it would be stored in byte order or reverse byte order.

Good idea Andy

Do start with you could just have something like 0xAA to 128 bytes next to each other as a const static buff , then if you found that pattern in only one place, you could try using some other value e.g 0x55 and see it it ends up in the same place, and then try 0x12345678 and work out the byte order

It downloaded fine and fast. 8MB rared. Thanks.
I think they use one fast SPI for the flash. There is a firmware loader implemented, which loads/writes/mirrors the flash into the ram. When writing to the flash on the fly you must do a write in the ram subsequently.
I’ve seen somewhere a guy was writing the GD “stops working for a while writing to the flash”. That is the major difference against STM (it was before the teardown).
Great idea, indeed