GD32 - writing program ram

Boards based on the GigaDevices GD32F103 microcontroller
User avatar
RogerClark
Posts: 7494
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: GD32 - writing program ram

Post by RogerClark » Wed May 04, 2016 9:43 pm

@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

User avatar
ahull
Posts: 1659
Joined: Mon Apr 27, 2015 11:04 pm
Location: Sunny Scotland
Contact:

Re: GD32 - writing program ram

Post by ahull » Wed May 04, 2016 11:28 pm

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

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

Re: GD32 - writing program ram

Post by RogerClark » Wed May 04, 2016 11:49 pm

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

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

Re: GD32 - writing program ram

Post by Pito » Thu May 05, 2016 6:28 am

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 :)
Pukao Hats Cleaning Services Ltd.

Post Reply