Configurable flash / ram split with minichlink

[iracigt]

This adds support for changing the amount of SRAM available in parts where the flash / SRAM split is configurable. Right now, this only works for the wch-linke adapter. The split is given as a command line flag and applied during the bulk memory write. Without this, the CH32V307 is limited to 32k of SRAM of a possible 128k. Adding this setting addresses issues #232, #280, and (in part) #303.

As referenced in issues #232, #280, and #303, some of the CH32V20x and CH32V30x parts have a user configurable option trading flash size for user RAM size. As described by the CH32V307 datasheet (pg 4):

The products with 256K FLASH+64K SRAM support user select word to be configured as one of several
combinations of (192K FLASH+128K SRAM), (224K FLASH+96K SRAM), (256K FLASH+64K SRAM),
(288K FLASH+32K SRAM).

Speculation is that the chips cannot execute from flash and instead copy the entire contents of the firmware image to hidden internal SRAM. This flag would then be configuring the amount of that internal RAM used for code storage vs user RAM.

This information is stored in the user option section of flash. According to #232, the official programmer sets this via a special command, the same one used to set readout protection. This patch uses the command described there, however does sanity checks based on chip id and applies the setting only if appropriate for the target.

I suspect there is a more general solution to be had here. The flag can be set by firmware running on the chip. Updates require unlocking the flash, making the write, and then become active after a reset. One generic possibility would be to upload a code stub that sets the flag. Another would be to use the read word and write word functionality to set it.

Another drawback to this patch is the setting is only applied during the bulk memory write. This is fine for the common case of uploading code. One weirdness is that the new -S [FLASH kB] [RAM kB] flag needs to appear before the -w flag. Note that the current erase and program workflow clears this flag to the default (32k SRAM for the '307). I'm open to suggestions on how to improve that aspect.

I've tested this patch with my WCH CH32V307V-EVT dev board and its integrated WCH programmer. My testing has been somewhat limited, but an application that allocates a 48k SRAM buffer and uses it seems to be working as expected. I don't currently have other hardware to test on.

[cw2]

Speculation is that the chips cannot execute from flash and instead copy the entire contents of the firmware image to hidden internal SRAM.

Sorry for hijacking the PR, I just recalled this has actually been confirmed - https://cpldcpu.wordpress.com/2024/05/01/decapsulating-the-ch32v203-reveals-a-separate-flash-die/

[cnlohr]

Oh no, I already have something like this in another one of my branches. But I do it in the Makefile. I have it working with the 307.

Sorry I just noticed this now.

This is much more comprehensive than my change though. Blahhh I will see if I can find common ground.

[eeucalyptus]

Could you rebase the branch to the current upstream branch?
Unfortunately I don't have a controller with configurable memory for testing. Are you on the discord? Could you maybe hmu for testing? handle is the same as here

[iracigt]

Rebase done. I'm not currently in the discord, but you can send an invite link to my email in the git log if you like.

It's probably worth restructuring how this patch works. The current approach feels inconsistent with the rest of minichlink. Ideally setting the split would be its own operation. Right now it just changes the behavior of the flash erase (?) sequence of the flash write function. I'm working now on a version that uses ReadWord and WriteWord instead, which should be compatible with all programmers, not just the WCH-LinkE.

[cnlohr]

Invite sent. I'd like to chat before we merge this.

[iracigt]

I've rewritten my code in minichlink to be more generic by using ReadWord, WriteWord, ReadHalfWord, and WriteHalfWord in place of the wch-linke specific operations. This required reading the CHIP_ID, so I added a register definition for that to ch32v003fun.h. There's also test program in examples that prints the current settings and probes RAM until it reaches the end and faults.

Overall the -S [FLASH kB] [RAM kB] flags are still there, but now are a separate operation. This means you should pass them after -w if using it while writing a new flash image. It can also now be used standalone to change the split without erasing flash.