News of the day regarding my CH32V307 journey.
I've found (a bit) more info about the RAM/Flash situation. Read it in a closed ticket in the openwch github issues. Apparently WCH still haven't released official documentation about it. Go figure. Maybe they want to reserve the possibility to change the memory architecture of the family at any point in the future, so they keep it quiet.
Anyway, for what we know, here goes (with a bit of conditional as this is again not 100% official):
- It has a total of 320KB RAM and a total of 488KB Flash. (Yes, that much.)
- The seemingly "odd" available combinations mentioned earlier are in fact simple to understand once we know that: the total of the available Flash (for code) and available RAM (for data) is 320KB, the total amount of RAM. So all combinations from 32/288 to 128/192 are just that. Which seem to imply that *all* code from Flash is copied into RAM at boot, and executed from RAM. It would thus seem that the core is unable to directly execute code from its own internal Flash (and there doesn't seem to be caches nor programmable wait states anyway). That is not an uncommon situation for many lower-cost MCUs, especially from China. It's even very possible that the internal Flash is actually a separate die inside the package. Would be interesting to see the internals to confirm.
- What that also means is that even at the highest code size setting (288KB Flash), there would still be 200KB available Flash for read/write access for storing user data. It's undocumented, but relatively easy to test. The question is, is this available at the expected addresses? May be tough if we have no docs about that, we'll have to experiment.
Other than this, I was trying to use SPI in half-duplex mode, and while having some issues, since the RM was not very detailed about it, and since it's a known fact that they've copied a lot of ST material, I've looked at the RM of a STM32 MCU about the SPI peripheral to figure it out. Yes.
And so I can also confirm that they've indeed copied a significant part of ST RM's. Even the bit fields of most registers have the same (or almost) names. Fun.
Speaking of SPI half-duplex, I found out that in master, half-duplex, in RX mode, the MCU starts clocking immediately as long as the peripheral is enabled and never stops clocking until we disable it. Which is relatively unpractical for many applications. Turns out the STM32 SPI does the same thing. I have yet to find a way of having it at least stop clocking exactly on words boundaries (to avoid "spurious" extra clock pulses.)