ch32v307, risc-v minicore with ethernet

[ali_asadzadeh]

tellurium thanks for sharing, Please add instruction on installing the compiler and debugger tool on win11 for ch32v307 in your website or here.

[bingo600]

tellurium thanks for sharing, Please add instruction on installing the compiler and debugger tool on win11 for ch32v307 in your website or here.

I found , that compiler inst. were documented here (ARM) ... So just replace "compiler inst w. Risc-V
https://mongoose.ws/documentation/tutorials/tools/

Riscv Compiler   (I would do the manual install)
https://xpack.github.io/dev-tools/riscv-none-elf-gcc/

https://github.com/xpack-dev-tools/riscv-none-elf-gcc-xpack/releases/

I just had to replace the compiler + objcopy "exe name" in the makefile
Using linux.

[wilhe_jo]

Well, the CH32 have another great feature: high-speed usb PHY on chip!

Sofar TinyUSB got me to something working pretty quickly.

The IDE package provided by WCH also runs relatively smooth...

73

[tellurium]

Well, the CH32 have another great feature: high-speed usb PHY on chip!

Again this makes me wonder - why they put so little RAM / flash on that chip, considering high speed Ethernet and USB peripherals?
Is that because this is a "testing" chip, and WCH plans to release a "big brother" of CH32V307 soon?

[wilhe_jo]

Well, for quite some applications, the memory is not really a big problem.

If you think the ch32v307 seems odd, look at this one: CH569

ATM, I design a usb RF power sensor where all the calibration stuff etc is handled on the pc.
For such applications (ie data processing is handled on the pc), this is quite a nice fit.

73

[SiliconWizard]

Well, the CH32 have another great feature: high-speed usb PHY on chip!

Again this makes me wonder - why they put so little RAM / flash on that chip, considering high speed Ethernet and USB peripherals?
Is that because this is a "testing" chip, and WCH plans to release a "big brother" of CH32V307 soon?

It's not that little. And this is meant to be cheap. You can't have it all. But yes they're probably going to expand the family.

Note that, as I explained earlier, its RAM/Flash availability is a bit odd and not very clearly documented.
It actually has 128 KB of RAM and 288 KB of flash.
But the catch is that some of the RAM can be used to cache some of the flash (in a non-documented way, at least AFAICT), so that the more RAM you have available, and the less flash. It's configurable through option bytes, from 32 KB RAM/288 KB flash to 128 KB RAM/192 KB flash. It's probably not going to help much if you need at the same time more RAM and more flash, but something that's good to know nonetheless.

I get it that this is still a bit tight for a typical application using Ethernet (at least if you're going to use TCP/IP, otherwise that can be relatively lightweight), but for USB HS, not really. People are getting spoiled these days, or I don't know! Remember that for a good while before FTDI released their first USB HS chip and later on, more MCUs started to appear with USB HS, the almost only "cheap" solution you had was the Cypress FX2. And it only had 16 KB of RAM in total, for both code and data.

I'm actually glad to have USB HS in this "modest" MCU. USB HS is still relatively uncommon in MCUs in general and you usually have to resort to Cortex-M7 stuff, so the "top of the line" basically. And some Cortex-M4 stuff, most of which requring an external PHY. I have plenty of applications that can leverage USB HS without requiring a powerful MCU, and that gives us a good alternative to FTDI chips.

I wouldn't mind more RAM, but the amount it has can still be put to some good use. Same for flash. Some would probably like an external QSPI flash solution better, to have a lot more room, but that requires an external chip, usually takes a lot more time to boot, and is slower.

So, I'm not expecting to have an alternative to NXP iMXRT10xx with this, but it's still pretty cool. I'm starting to like it and already have a few projects in mind in which it would be a good fit.

[ali_asadzadeh]

Thanks for the update, I have followed the instruction with these

I opened the git bash in the wch project directory and typed like this

xpm init # Only at first use.
xpm install @xpack-dev-tools/riscv-none-elf-gcc@latest --verbose

It went ok

after install I have added  "C:\>%USERPROFILE%\AppData\Roaming\xPacks\@xpack-dev-tools\riscv-none-elf-gcc\13.2.0-2.1\.content\bin"  the to the windows path
now I can Use

riscv-none-elf-gcc --version

in git bash and it would print like this

riscv-none-elf-gcc.exe (xPack GNU RISC-V Embedded GCC x86_64) 13.2.0
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Now when I tpye make in the wch project I would get this errors

make
riscv64-unknown-elf-gcc main.c mongoose.c vendor/system_ch32v30x.c vendor/startup_ch32v30x_D8C.S -W -Wall -Wextra -Wno-error -Wundef -Wshadow -Wdouble-promotion -Wformat-truncation -fno-common -Wconversion -Wno-sign-conversion -ffunction-sections -fdata-sections  -march=rv32imafc -mabi=ilp32f  -DSYSCLK_FREQ_144MHz_HSE -I. -Ivendor -g3 -Os  -T vendor/link.ld -nostartfiles --specs=nano.specs  -lc -lgcc -Wl,--gc-sections  -o firmware.elf
make: riscv64-unknown-elf-gcc: No such file or directory
make: *** [Makefile:25: firmware.elf] Error 127

I tried to modify the make file to this

Code: [Select]

CFLAGS = -W -Wall -Wextra -Wno-error -Wundef -Wshadow -Wdouble-promotion
CFLAGS += -Wformat-truncation -fno-common -Wconversion -Wno-sign-conversion
CFLAGS += -ffunction-sections -fdata-sections #-fmessage-length=0 -fsigned-char
CFLAGS += -march=rv32imafc -mabi=ilp32f #-msmall-data-limit=8 -mno-save-restore
CFLAGS += -DSYSCLK_FREQ_144MHz_HSE -I. -Ivendor -g3 -Os $(CFLAGS_EXTRA)

LDFLAGS = -T vendor/link.ld -nostartfiles --specs=nano.specs #--specs=nosys.specs
LDFLAGS += -lc -lgcc -Wl,--gc-sections #-Wl,-Map=$@.map

SOURCES = main.c mongoose.c vendor/system_ch32v30x.c vendor/startup_ch32v30x_D8C.S

ifeq ($(OS),Windows_NT)
  RM = cmd /C del /Q /F /S
else
  RM = rm -rf
endif

all: firmware.bin

firmware.bin: firmware.elf
riscv-none-elf-objcopy -O binary $< $@
ls -l firmware.*

firmware.elf: $(SOURCES) hal.h Makefile
riscv-none-elf-gcc $(SOURCES) $(CFLAGS) $(LDFLAGS) -o $@

flash: firmware.bin
wchisp flash $<

clean:
$(RM) firmware.* *.su


and I get this error

riscv-none-elf-gcc main.c mongoose.c vendor/system_ch32v30x.c vendor/startup_ch32v30x_D8C.S -W -Wall -Wextra -Wno-error -Wundef -Wshadow -Wdouble-promotion -Wformat-truncation -fno-common -Wconversion -Wno-sign-conversion -ffunction-sections -fdata-sections  -march=rv32imafc -mabi=ilp32f  -DSYSCLK_FREQ_144MHz_HSE -I. -Ivendor -g3 -Os  -T vendor/link.ld -nostartfiles --specs=nano.specs  -lc -lgcc -Wl,--gc-sections  -o firmware.elf
Cannot create temporary file in C:\Windows\: Permission denied
make: *** [Makefile:25: firmware.elf] Error 127

[ali_asadzadeh]

If you think the ch32v307 seems odd, look at this one: CH569

Wch has come to destroy some ARM chips including STM32 with its insane prices!

[SiliconWizard]

riscv-none-elf-gcc main.c mongoose.c vendor/system_ch32v30x.c vendor/startup_ch32v30x_D8C.S -W -Wall -Wextra -Wno-error -Wundef -Wshadow -Wdouble-promotion -Wformat-truncation -fno-common -Wconversion -Wno-sign-conversion -ffunction-sections -fdata-sections  -march=rv32imafc -mabi=ilp32f  -DSYSCLK_FREQ_144MHz_HSE -I. -Ivendor -g3 -Os  -T vendor/link.ld -nostartfiles --specs=nano.specs  -lc -lgcc -Wl,--gc-sections  -o firmware.elf
Cannot create temporary file in C:\Windows\: Permission denied
make: *** [Makefile:25: firmware.elf] Error 127

I don't know what's the deal with this version of the compiler on Windows and why it's trying to create temporary files in C:\Windows - that sounds pretty bad. So maybe this compiler has been built with someone's feet, or you haven't properly installed it. Dunno. Normally GCC binaries don't need any specific installation, but this particular build may be different, may require some environment variables to be defined, whatnot.

One quick thing you can try before solving this compiler (probably installation) issue is to add the '-pipe' option to CFLAGS. It should normally prevent GCC from having to create temp files, so (if everything goes well, no hard guarantee here) that may solve your issue.

[martinribelotta]

riscv-none-elf-gcc main.c mongoose.c vendor/system_ch32v30x.c vendor/startup_ch32v30x_D8C.S -W -Wall -Wextra -Wno-error -Wundef -Wshadow -Wdouble-promotion -Wformat-truncation -fno-common -Wconversion -Wno-sign-conversion -ffunction-sections -fdata-sections  -march=rv32imafc -mabi=ilp32f  -DSYSCLK_FREQ_144MHz_HSE -I. -Ivendor -g3 -Os  -T vendor/link.ld -nostartfiles --specs=nano.specs  -lc -lgcc -Wl,--gc-sections  -o firmware.elf
Cannot create temporary file in C:\Windows\: Permission denied
make: *** [Makefile:25: firmware.elf] Error 127

This is produced by the unset TMP variable (gcc use a temporary files to store intermediate compilation artifacts like preprocessed code and assembler files)

https://community.infineon.com/t5/Wi-Fi-Combo/Fatal-toolchain-error/td-p/104592

The correct way to solve this is add to environment variables a system-wide temporary directory like C:\temp

[tellurium]

tellurium thanks for sharing, Please add instruction on installing the compiler and debugger tool on win11 for ch32v307 in your website or here. :-

I'll start a separate topic for ch32v307 modbus console, to avoid polluting this topic.

[SiliconWizard]

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.)

[wilhe_jo]

Well, if you try to decode the chinglish you could come up with the theory, that part of the flash is the bootloader, and that this bootloader could be modified.

However, if you ask, you get told you can't...

Anyhow my feeling is, that this is just not supported, and that it may be similar to the ch32v003....

In praxis, this would be a really useful feature.

73

[mikeselectricstuff]

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.)

If flash is on a seperate die, chances are it's SPI, so you may see differences in startup time depending on the memory configuration selected

[SiliconWizard]

After digging up a bit, some info can be found in the DS and RM about the memory layout, although they're not very verbose about it all.

From what I gathered on github and these documents, it now seems more than likely that they do copy all code in RAM at startup. They call that the "R0WAIT" area. The use of RAM is as I described above.
The Flash memory is 480KB in total and the "non-zero-wait" area follows the zero-wait area (where code is located). In the RM (p. 15), we can see the memory layout.

- Code memory is remapped at address 0 in normal boot mode (once it's been copied into RAM), it's the remapped location of code in RAM.
- The start of the RAM data area is mapped at address 0x2000_0000. Its size is 320KB - (max code size as set in config bytes), as I explained earlier.
- It's apparently not possible to have any other configuration than the ones listed earlier.
- The Flash itself is still accessible at address 0x0800_0000. The area above the max code size (at least 192KB and up to 288KB) should be freely available as read/write - I'll have a look at their SDK code for accessing Flash and will do some testing.
- The bootloader is stored in "system Flash", it's an area separated from the Flash described above. It's not part of it. It's 28KB and its address is 0x1FFF_8000. Whether it can be user written, testing will tell. (With caution of course as we could bork the bootloader.) There is a way of writing to it as they do it in production (which is not silly compared to using pure ROM). But maybe it requires some test pin (not broken out) to be asserted. Or maybe not. WCH doesn't seem to want to talk about it (as can be seen in some discussions), but testing that should be easy. Reading the entire bootloader (if possible) and saving it before attempting to write to this area is probably a good idea, just in case.

This bootloader arrangement probably explains why , from the two identical dev boards I have, one works fine with the USB ISP mode, and the other has issues with it. It's most likely not the same version of the bootloader on both chips.

As to the internal Flash being SPI, I sincerely doubt it. It's probably parallel Flash. According to the DS, the typical start time (that's documented in the wake-up time from standby) for a 256K code setting, including LDO and HSI clock stabilization, is 8.9 ms. There's no way it could be achieved through SPI unless running at clock speeds much higher than the chip could reasonably handle, and certainly not from the HSI clock that runs at startup.

[tellurium]

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

The board I have, has 32/288 configuration. In other words, it uses the config with the minumum RAM of 32k.
There is a snippet in the WCH's linker script:


/* CH32V30x_D8C - CH32V307VC-CH32V307WC-CH32V307RC
   CH32V30x_D8 - CH32V303VC-CH32V303RC
   FLASH + RAM supports the following configuration
   FLASH-192K + RAM-128K
   FLASH-224K + RAM-96K
   FLASH-256K + RAM-64K 
   FLASH-288K + RAM-32K 
*/
   FLASH (rx) : ORIGIN = 0x00000000, LENGTH = 288K
   RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 32K
}


Which means that by default, they configure for this minimal RAM configuration.

For Ethernet networking, 32k is a bit low, so both user option bytes (documented at RM 32.4.6 and 32.6) and linker script has to be modified. I assume, 96/224 should suffice.

About the extra flash.. That extra can be used for persistent storage, maybe even LittleFS can be adopted, since the flash page size is small (256 bytes), so LittleFS should be quite efficient there. Where is that extra flash ? Is it contiguous with the documented one, or reside on a different address?

[SiliconWizard]

Yes, for the linker script that's provided with their SDK, I talked about it in an earlier post. They have set a 32K/288K layout in it, but there are comments. Adapt it to your own settings.
Have you checked that the MCU on your board is configured for 32K/288K? The RM doesn't mention what the factory value is. It's marked "xxb". On my dev boards (which are third party, not WCH), the MCU comes set with the 64K/256K option.
You need to check it using your programming tool.

I've read more of the RM about Flash, and it's now not as clear whether the MCU can't execute code directly from Flash. Maybe it can. What happens when they shadow (copy) part of the Flash to RAM is that the core can fetch instructions at full clock speed up to 144 MHz. But the Flash can be only read at up to 60 MHz according to the docs, and the Flash controller is configured by default for HCLK/2, meaning accesses are made at half speed of HCLK (which is why they mention to be careful with Flash operations if HCLK exceeds 120 MHz.)

I've tested that all Flash could be read directly with a memory access at its documented address. But it's only data access. While I haven't tested it yet, it's possible that the core may be able to execute code directly from Flash (thus in the non-zero-wait area), possibly at half clock speed depending on the Flash controller config. That's something interesting to test for sure. That would mean that one could have a smaller fraction of code placed in the shadow RAM for code that needs fast execution, and still be able to run code up to 480K. Unless they have explicitely restricted that, it should be possible, as the addresses are completely consecutive. Should be interesting.

The whole 480K are consecutive and can be accessed as a whole, both for read and write operations. (Write operations require specific handling of course, while read operations are just simple memory accesses.)
There are a couple examples in the SDK that show this, like the 'MSC_U-Disk' example.

[SiliconWizard]

Note that even if the MCU can't execute code in the non-zero-wait area, it can freely *read* data from it. So we can always write a linker script that will put all (or not, possibly just some specific data) your constant data in this upper area, leaving the lower area (RAM-shadowed) for *code* only, and not for "expensive" constant data (can be especially cool if you use a lot of initializers, such as graphics, or other).

Cool stuff.

[iMo]

Afaik the first CH32F103 was dual chip with mcu chip and the spi flash chip on top, there are great die shots discussed here in past. I would guess the bootloader is hardwired in an on-chip "rom" (not a "flash" technology") and the mcu has only sram on its chip (320kB in your case). The SPI flash chip sitting on the top of the mcu chip could be 640kB or 1Mbyte large, imho (they use standard flash chips, my bet).

PS: it could be they did not master the flash technology on the same chip with the mcu yet, or they have issues with the flash access accelerators (ie the ART STM is using), etc., and in order to achieve the same performance they have to run everything in sram. Moreover the company started as their major SPI flash chips manufacturer there, thus mcus was/is their secondary biz, afaik..

[wilhe_jo]

I'm not really sure about the bootloader being hard coded.

Just read the DS and RM... I bet it's located in the same flash as the rest. My guess is, however, that access to this area is somewhat difficult/impossible due some design decision.

My guess is that there's a procedure like the option-byte programming that would allow you to change the bootloader to something better suited for your needs (eg. Check updatefile in ext. Flash for signature/checksum and update on match).

Sadly, it's not documented...
Maybe they really "forgot" to enable this...  We'll never know...

73

[iMo]

When I can put 32kB of "flash" on the mcu chip, I can easily place another XXXkB of flash there as well. As I wrote in my previous post, I can remember on discussions in past (with the introduction of the CH32F103 and friends) the dual chip is because they have some issues with integrating their "flash technology" with the technology they use with their MCUs. It was some 10y back, perhaps they mastered that already, but I still doubt they do. The dual chip config is a big complication for their production, imho.

[brucehoult]

Afaik the first CH32F103 was dual chip with mcu chip and the spi flash chip on top, there are great die shots discussed here in past.

I think you're thinking of Gigadevice and the GD32VF103 and also Arm version.

Moreover the company started as their major SPI flash chips manufacturer there, thus mcus was/is their secondary biz, afaik..

That's Gigadevice.

WCH is/was a big supplier of 8051 clones. I don't think they've ever made flash memory.

Totally unrelated companies AFAIK.

[HwAoRrDk]

I'm not really sure about the bootloader being hard coded.

I think one indication that it is hard-coded (or, at least, read-only) is the lack of a FLASH_BOOT_MODEKEYR register on the CH32V30x. On other CH32V models, like for example the CH32V003, that register is used to unlock writing to the bootloader flash area. If you can't unlock it for writing, that would imply you can't write to it...

[wilhe_jo]

I'm not really sure about the bootloader being hard coded.

I think one indication that it is hard-coded (or, at least, read-only) is the lack of a FLASH_BOOT_MODEKEYR register on the CH32V30x. On other CH32V models, like for example the CH32V003, that register is used to unlock writing to the bootloader flash area. If you can't unlock it for writing, that would imply you can't write to it...

Well, non-documented does not mean non-existing, but may imply non-functional...

- The bootloader is stored in "system Flash", it's an area separated from the Flash described above. It's not part of it. It's 28KB and its address is 0x1FFF_8000. Whether it can be user written, testing will tell.

Back when I first discovered this IC and read the available docs, i came to the conculsion, that 480k+28k+some area for Option-bytes,... would fit 512k flash...
Whether or not, the address decoder etc. support manipulating it... we may never really find out.

As you pointed out, the register definitions and de ref-manual do not explain how you could do it, the chinglish text, however, suggests it could have been at least been on the feature list during development of this IC.

BTW: Support says it can't be done. That's why it's not on my priority list ATM... getting the products done is more important

73

[iMo]

Afaik the first CH32F103 was dual chip with mcu chip and the spi flash chip on top, there are great die shots discussed here in past.

I think you're thinking of Gigadevice and the GD32VF103 and also Arm version.

Yep, you are right..
Anyhow, simply send a chip to Noopy and we get more on the setup..