RISC-V is the new hot thing. And so, there are some Chinese MCU manufacturers making RISC-V versions of their 32F103 clones.
GigaDevice has their GD32VF103 around since 2019, and WinChipHead introduced their CH32V103 last year.

Now, let’s have a look at these chips. These chips are basically, a RISC-V core attached to the 32F103 peripherals. These chips are pin compatible with their ARM counterparts. Unlike their ARM counterparts, they are not drop-in replacements for each other, when the firmware has been built against the manufacturers development libraries.

The GD32VF103 uses JTAG as debugger interface, and is supported by the RISC-V fork of OpenOCD and SEGGER J-Link. With OpenOCD’s support any JTAG probe can be used. However, the use of a full JTAG interface means there are 4 lines going to the debugger, rather then 2 lines of an SWD interface. This could pose a problem when intending to replace an STM32 in an existing design. The CH32V103 uses the RVSWD interface. Like normal SWD, this uses two lines, and thus can be used in a design which only exposes the SWD lines, however, this is not an industry standard interface. As there appears to be no documentation, it required a debugger probe from WCH, and a binary-only distribution of OpenOCD. Edit: It appears SEGGER might support it in the future.

While both chips implement the same peripherals as an STM32F103 (with one exception: USB), and the same RISC-V extentions (RV32IMAC), they differ in their interrupt implementation. The GigaDevice implements ECLIC. Enhanced CLIC. CLIC is a proposal at this time. I have not yet researched what this “enhanced” refers to, how ECLIC differs from CLIC. However, this is an additional mode to the interrupt handlings specified in the RISC-V specifications. For the FPIC implemented in the CH32V103, I haven’t been able to locate the appropriate documentation. Looking at the manufacturers source code, it appears to have a vector table according to the RISC-V specifications. Both chips should be able to use a standard RISC-V vector table, however, there is an offset in the interrupt numbers, therefore it would not be interchangeable. A firmware built against the sources intended for the CH32V103 would boot up to main on a GD32VF103, however, as soon as interrupts are used it will fail. Furthermore, the delay functions supplied by the CH32V103 sources fail on a GD32VF103, as they use functionality in the core which differs between the RISCV-3A and BumbleBee cores.

If we during boot are able to determine which core we are running on, and configure the interrupts accordingly, we should be able to bring the system up on both chips. Additionally, function calls to enable/disable interrupts could adjust for the offset between the cores. Therefore, I believe it would be technically possible to create firmware that would run on either. Furthermore, as the peripherals are STM32F103 compatible, it should be possible to use the STM32 peripheral libraries with no or minor adjustments. This would mean porting a firmware from STM32F103 to a RISC-V 32F103 chip would become nothing more then a recompile. The goal has been set.