So my Q to a more lucky GD users – is it possible to write/read into the program ram (64/128kB)?
P.
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
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).
My Q was about the 128KB Program RAM.

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.
http://zeptobars.com/en/read/GD32F103CB … ga-Devices
Reading however is fast

*edit*
i just read it’s mirrored to sram, that is indeed interesting XD
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
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
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
