Add support for WCH CH32V303 #87125

miggazElquez · 2025-03-14T14:52:14Z

This PR add support for the SoC CH32V303 from WCH, and for the board CH32V303EVT.

Depends on #85395 for the support of west flash.

zephyrbot · 2025-03-14T14:53:14Z

The following west manifest projects have changed revision in this Pull Request:

Name	Old Revision	New Revision	Diff
hal_wch	zephyrproject-rtos/hal_wch@`1de9d3e`	zephyrproject-rtos/hal_wch@`941f518` (`main`)	zephyrproject-rtos/[email protected]

✅ All manifest checks OK

Note: This message is automatically posted and updated by the Manifest GitHub Action.

miggazElquez · 2025-03-14T14:57:00Z

@VynDragon if you want to take a look, as this is based on your code for the ch32v208.

boards/wch/ch32v303evt/ch32v303evt-pinctrl.dtsi

nordicjm · 2025-03-14T15:10:47Z

boards/wch/ch32v303evt/ch32v303evt_defconfig

+CONFIG_CONSOLE=y
+CONFIG_UART_CONSOLE=y
+
+CONFIG_FLASH_BASE_ADDRESS=0x08000000


why is this here?

If I don't put that, CONFIG_FLASH_BASE_ADDRESS will be set to the address of the flash in the device tree (currently 0), and minichlink fail to flash at the address 0. But if I change the address in the device tree, I can flash but Zephyr then fails to boot, I don't really know why. @VynDragon you didn't have this issue on the 208 ?

What would be the way to solve this ? I saw that some boards did change CONFIG_FLASH_BASE_ADDRESS in their defconfig, so that's why I put it there, but maybe it should be in another place ?

Oh so that's why the west flash didnt work! Ill look into it, might be a matter of fixing the runner instead of this, otherwise figuring how to make it boot in non aliased space would make it easier to use the full flash so ill see for both issues.

Well it works for me when i set

flash0: flash@8000000 { compatible = "soc-nv-flash"; reg = <0x08000000 DT_SIZE_K(128)>; };

after udpating minichlink and using minichlink -w build/zephyr/zephyr.bin 0x0
But west flash still doenst work so no clue what's going on there

a it's the -b for the runner, need to disable reset for ch32v208

Edit:" which is easy to say but almost impossible to do, i'm on my second PR just to be able to pass --no-reset in the board args.

It might be a frequency issue, for some reason on CH32V208 it works at 144MHz, but they 'highly recommend' using 120M in the RM for the F/V20x/30x serie. You added the long jump code in the ASM right?
It's only for the linking mapping within that space, otherwise the space is accessible without booting into it. (eg if your address space in zephyr is 0x08000000 it will only run in non-aliased, but if it's 0x0 it will only run in aliased due to the long jump / short jump things)

For flashing

Me neither, it's supposed to flash to 0x08000000 so with dt-flash=y and the flash address set to that and the long jump code, or 0x0 with no long jump and 0x08000000 flash address still. I think it changed between old and new minichlink version?

So before answering to you I wanted to test it one last time and now it works, I don't know what I did wrong during my tests before... because I'm quite sure I tested with the long jump, but maybe I had changed something else, I don't know. Anyway it works now, so I modified my PR to include it, it seems cleaner to me than passing the flash address directly to minichlink.

I still don't really understand the point of the long jump, even if it's clearly necessary : if the address space in zephyr is at 0x08000000, why do we need the long jump to get into non-aliased mode ? Because when testing it seems like we boot in non-aliased mode with the address space at 0x08000000, but maybe the debuggers are just confused by all this aliasing and are lying to me. (I would like to add a comment explaining this long jump things but as I don't totally understand it yet...)

I still don't really understand the point of the long jump

It's so the pc is in the right zone when the short jumps happen, eg that the pc is in the area expected when it tries to do a short jump, there is also the matter of the gp pointer, and a couple other thing i believe break when operated in not the expected area. In practice it crashes if you run it without that long jump.

Also make sure to set frequency to 120 if you use the full flash! It might be your spurious issue

Because when testing it seems like we boot in non-aliased mode

It always boot in the aliased zone?

It always boot in the aliased zone?

I think that I was fooled by the debugger, I'm not sure about what is happening but with the debugger even without the longjump I'm in non aliased space (pc = 0x0800...). I think it's not really executing the first instructions, it seems like it's just jumping to __start directly ?

Weird, I dont know what could be going on

VynDragon · 2025-03-14T15:36:04Z

Looks perfect to me as far as I can tell beside the nordicjm remarks. Will do regression testing for CH32V003 and CH32V208 soon.
CONFIG_FLASH_BASE_ADDRESS shouldnt be set like this in there. I am not sure how to support the extended flash size in zephyr either.... In the meantime you can just set the address of the flash in memory space in the DTS if you dont want it to use the 0x0 address alias such as:

flash0: flash@8000000 {
		compatible = "soc-nv-flash";
		reg = <0x08000000 DT_SIZE_K(128)>;
};

i think

soc/wch/ch32v/qingke_v4f/vector.S

nzmichaelh

LGTM

boards/wch/ch32v303evt/doc/index.rst

nzmichaelh · 2025-03-17T06:06:55Z

west.yml

@@ -258,7 +258,7 @@ manifest:
      groups:
        - hal
    - name: hal_wch
-      revision: 1de9d3e406726702ce7cfc504509a02ecc463554
+      revision: pull/1/head


Is this correct?

I think, it's to indicate that this PR depend on the PR #1 on the hal_wch repository. The message from zephyrbot at the top of the PR looks good so I think it's correct.

VynDragon · 2025-03-19T15:37:49Z

I cant find the other comment so here the PR for fixing CH32V208 with the issue mentionned: #87345, inherently fixing it by adding the full flash feature

fkokosinski · 2025-03-21T13:19:49Z

soc/wch/ch32v/qingke_v4f/vector.S

+SECTION_FUNC(vectors, __start)
+	li 	a0, 0xf
+	csrw	mtvec, a0
+	j	__initialize


This file seems to be the same across all qingke socs. Let's de-duplicate it and use a single common one.

I think it's the same for the ch32v208 (Qingke V4C), but not for the ch32v003(Qingke V2A) (see #87125 (comment)).

Should I still de-duplicate it ?

Yea, this version is only relevant for CH32V208, and CH32V30x (unless i'm missing some)
Edit: and also CH32V203 but the amount of flash is different (224K), so between all Qingke V4?
This seems to be relevant only for all Qinke V4 CH32 of the 20x and 3xx serie. So currently CH32V208, CH32V303, not CH32V003.

@miggazElquez yeah, let's de-duplicate it :)

yeah, with the new PR introducing the v203 it seems even more logical.

As the new vector.S use the non-aliased space, it needs some changes in the devicetree of the 208 to use the new files, so I didn't remove it from here. These changes are in #87345, which updated the SoC to use the new version of vector.S.

Should i submit the deduplication with the 208 update? Should it be

-qingke_v4/ \ f \ c \ b

or stay

- qingke_v4f - qingke_v4c - qingke_v4 # common

?

The latter sounds better, and it replicates the convention used for other SoCs (stm, gd, silabs), but I'd rearrange it to something like this:

- chv32 (family) - qingke_v4 (series) - common - qingke_v4f (soc) - qingke_v4c (soc)

Should this be done in this pull request, or is it better to do it with the ch32v208 update ?

We can handle it in the update IMO

Ok will update that PR

SoftwareArchitekt · 2025-04-24T12:37:00Z

boards/wch/ch32v303evt/doc/index.rst

@@ -0,0 +1,59 @@
+.. zephyr:board:: ch32v303evt


Here it is not clear, which board is mentioned. WCH have several CH32V303-Boards. They differ in size of flash and if FSMC is there or not. So please specify more clear which type is described (VH32V303CBT6 or VH32V303VCT6 or VH32V303RCT6)

Ah I hadn't noticed that there are multiple development kit named CH32V303EVT. Mine is for the one with the CH32V303VCT6. I'm not sure about the best way to handle it : I can of course add it to the text of the documentation, but for the name of the board I'm not sure of the correct way t handle it (in this line of the documentation but also in general, the name of the board is used by west). Maybe this where I have to use board variant ? I'm not sure

I am actually working on the 308. There I have the same problem with different naming. Here I guess, we need to add the extension to the naming. I future there will then be 3 boards. If you look here https://www.wch-ic.com/products/CH32V303.html in part Product Selection Guide you can see a lot of diffenerces (number of adc, Uart SPI etc, Flashsize Ram-Size). So my proposale is to add to yout board name the processor extension like WCH to it at the order of dev-boards too.

Ah yes, on their ali express page the name is more complete, I hadn't noticed it. I will rename the board ch32v303vct6_evt.

thats looks fine from myside

I will look in the next days over all your files and compare it with my 308-files (so far i have them) to check their compatibility

miggazElquez · 2025-04-24T14:22:01Z

I modified the commit for the hal update, and renamed the board.

Please put a DNM tag on this PR, I'm still waiting for #87345 to be merged before I can rebase my code.

Edit: I also rebased on main to try to fix the errors on the CI.

Update hal_wch. As the hal upstream changed name, there is now a name conflict. Rename ch32fun.h to hal_ch32fun.h to fix this conflict. Signed-off-by: Miguel Gazquez <[email protected]>

All SoCs based on Qingke V4 processors need the same 'vector.S'. Adds a shared `qingke_v4_vector.S` file to avoid duplication across multiple SoCs. Signed-off-by: Miguel Gazquez <[email protected]>

Adds support for building an image for the ch32v303. Signed-off-by: Miguel Gazquez <[email protected]>

Adds support for the CH32V303EVT board, based on the CH32V303 soc. Signed-off-by: Miguel Gazquez <[email protected]>

SoftwareArchitekt · 2025-04-27T15:10:51Z

modules/hal_wch/hal_ch32fun.h

 #endif

 #if defined(CONFIG_SOC_SERIES_QINGKE_V4C)
 #define CH32V20x 1
-#include <ch32v003fun.h>


i am not happy with the filename starting with wch. I have a board using the Qingke-V4F and not from wch. I guess, that the filename should be change to qingkeCh32fun or something like this.

Sorry for confusion, I see now, that the chip is still from wch. So evrything can stay.

zephyrbot added area: UART Universal Asynchronous Receiver-Transmitter area: GPIO area: Timer Timer area: RISCV RISCV Architecture (32-bit & 64-bit) area: Pinctrl area: Clock Control area: Interrupt Controller labels Mar 14, 2025

zephyrbot requested review from andyross, carlocaione, edersondisouza, fkokosinski, gmarull, henrikbrixandersen, katsuster, kgugala, mgielda, nordic-krch, npitre, nzmichaelh, teburd, tgorochowik and ycsin March 14, 2025 14:53

zephyrbot assigned gmarull Mar 14, 2025

zephyrbot added manifest manifest-hal_wch DNM (manifest) This PR should not be merged (controlled by action-manifest) labels Mar 14, 2025

miggazElquez force-pushed the ch32v303 branch from 72fd986 to 8f9c0c2 Compare March 14, 2025 15:00

nordicjm reviewed Mar 14, 2025

View reviewed changes

miggazElquez force-pushed the ch32v303 branch from 8f9c0c2 to 4280d47 Compare March 14, 2025 16:24

VynDragon reviewed Mar 14, 2025

View reviewed changes

soc/wch/ch32v/qingke_v4f/vector.S Outdated Show resolved Hide resolved

nzmichaelh approved these changes Mar 17, 2025

View reviewed changes

miggazElquez force-pushed the ch32v303 branch from 4280d47 to 2b3728f Compare March 19, 2025 13:14

zephyrbot added the area: West West utility label Mar 19, 2025

miggazElquez force-pushed the ch32v303 branch from 2b3728f to 6758d68 Compare March 19, 2025 14:02

fkokosinski reviewed Mar 21, 2025

View reviewed changes

VynDragon mentioned this pull request Mar 21, 2025

Introduce CH32V203 and WeactStudio CH32V203 Blue Pill plus #87490

Open

miggazElquez force-pushed the ch32v303 branch 2 times, most recently from 275a2ee to 9995655 Compare March 24, 2025 10:00

nordicjm previously approved these changes Mar 24, 2025

View reviewed changes

fkokosinski previously approved these changes Mar 28, 2025

View reviewed changes

SoftwareArchitekt reviewed Apr 24, 2025

View reviewed changes

miggazElquez dismissed stale reviews from fkokosinski and nordicjm via 0f33c6d April 24, 2025 14:20

miggazElquez force-pushed the ch32v303 branch from 9995655 to 0f33c6d Compare April 24, 2025 14:20

github-actions bot added the platform: WinChipHead label Apr 24, 2025

miggazElquez added 4 commits April 24, 2025 16:23

modules: Update hal_wch

49411e5

Update hal_wch. As the hal upstream changed name, there is now a name conflict. Rename ch32fun.h to hal_ch32fun.h to fix this conflict. Signed-off-by: Miguel Gazquez <[email protected]>

soc: wch: Introduce shared qingke_v4_vector.S for deduplication

6fa1e97

All SoCs based on Qingke V4 processors need the same 'vector.S'. Adds a shared `qingke_v4_vector.S` file to avoid duplication across multiple SoCs. Signed-off-by: Miguel Gazquez <[email protected]>

soc: Add support for the WCH CH32V303

8d54364

Adds support for building an image for the ch32v303. Signed-off-by: Miguel Gazquez <[email protected]>

boards: Add support for the board CH32V303EVT

876fe8f

Adds support for the CH32V303EVT board, based on the CH32V303 soc. Signed-off-by: Miguel Gazquez <[email protected]>

miggazElquez force-pushed the ch32v303 branch from 0f33c6d to 876fe8f Compare April 24, 2025 14:23

github-actions bot removed the DNM (manifest) This PR should not be merged (controlled by action-manifest) label Apr 24, 2025

VynDragon added the DNM This PR should not be merged (Do Not Merge) label Apr 24, 2025

kartben assigned nzmichaelh and unassigned gmarull Apr 25, 2025

SoftwareArchitekt reviewed Apr 27, 2025

View reviewed changes

Add support for WCH CH32V303 #87125

Are you sure you want to change the base?

Add support for WCH CH32V303 #87125

Conversation

miggazElquez commented Mar 14, 2025

zephyrbot commented Mar 14, 2025 • edited by github-actions bot Loading

miggazElquez commented Mar 14, 2025

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

VynDragon Mar 14, 2025 • edited Loading

Choose a reason for hiding this comment

VynDragon Mar 14, 2025 • edited Loading

Choose a reason for hiding this comment

VynDragon Mar 19, 2025 • edited Loading

Choose a reason for hiding this comment

miggazElquez Mar 19, 2025 • edited Loading

Choose a reason for hiding this comment

VynDragon Mar 19, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

VynDragon commented Mar 14, 2025 • edited Loading

nzmichaelh left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

miggazElquez Mar 17, 2025 • edited Loading

Choose a reason for hiding this comment

VynDragon commented Mar 19, 2025

Choose a reason for hiding this comment

Choose a reason for hiding this comment

VynDragon Mar 21, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

miggazElquez Mar 24, 2025 • edited Loading

Choose a reason for hiding this comment

VynDragon Mar 24, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

miggazElquez Apr 24, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

miggazElquez commented Apr 24, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

zephyrbot commented Mar 14, 2025 •

edited by github-actions bot

Loading

VynDragon Mar 14, 2025 •

edited

Loading

VynDragon Mar 14, 2025 •

edited

Loading

VynDragon Mar 19, 2025 •

edited

Loading

miggazElquez Mar 19, 2025 •

edited

Loading

VynDragon Mar 19, 2025 •

edited

Loading

VynDragon commented Mar 14, 2025 •

edited

Loading

miggazElquez Mar 17, 2025 •

edited

Loading

VynDragon Mar 21, 2025 •

edited

Loading

miggazElquez Mar 24, 2025 •

edited

Loading

VynDragon Mar 24, 2025 •

edited

Loading

miggazElquez Apr 24, 2025 •

edited

Loading

miggazElquez commented Apr 24, 2025 •

edited

Loading