-
Notifications
You must be signed in to change notification settings - Fork 58
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How is the flash programmed? #3
Comments
Unfortunately WCH_Link (SDI) and BOOT protocol is not open, WCH_Link (SDI) but not SWD is the only way to flash CH32V003. |
We are using OTP chips currently. I wanted to evaluate switching to this chip to allow updating of our code. But we can't achieve that without the larger host CPU having some way to reflash the chip while in-circuit. Manufacturing is also an issue, the host CPU needs to initially flash the chip. |
Apparently Mounriver has released the protocol. https://github.com/kprasadvnsi/riscv-openocd-wch |
A reverse inginering of WCH (ch32v) SWD protocol is made by @fxsheep here https://github.com/fxsheep/openocd_wchlink-rv/wiki/WCH-RVSWD-protocol @jonsmirl In my view, you have two ways to go:
|
This is for a commercial product, so we don't have the luxury of spending a lot of time on open source code development. If there is no simple solution to the host being able to flash the chip we'll just continue using Padauk OTP parts which are not upgradable. |
@jonsmirl So the product is 1. using a large host CPU is MCU to flash slave CH32V003, the host and slave MCU on the same PCB board. And you want to use host CPU loading programmer to CH32V003 by ETH , WIFI etc. at real time . |
That sound interesting... some plans to publish this with the regular HAL/Examples? |
An other cuestio: Is ok if I make a reverse engineering of the CH32V3xx and CH32V003xx SWD/SDI protocol? |
Here is another discussion with multiple engineers interested in an open-source tool-chain to program the chips: https://www.eevblog.com/forum/microcontrollers/wch-$0-10-risc-v-mcu/?all |
Is it possible to use another CH32V3xx made with serial communication firmware to record another CH32V3xx? |
WCH Link clones are $1.20. |
Since RVSWD is a synchronous protocol, I think it can be implemented as a custom transport+ bitbang driver in OpenOCD and reuse existing bitbang SWD hardware. This possibly reduces cost to 0. |
There is now a simple libusb program minichlink to flash it: |
Checkout https://github.com/ch32-rs/wlink 😝 |
It seems the recent commit contains an example implement of using the one-wire procotol: https://github.com/openwch/ch32v003/tree/main/CH32V003_1Line_Base_on_CH32F103 |
ooh that might be handy, I'm planning to implement this debug protocol in Black Magic Debug, see blackmagic-debug/blackmagic/pull/1399, though for now I'm only working on the undocumented RVSWD (see also https://perigoso.github.io/rins and https://github.com/perigoso/sigrok-rvswd for RVSWD related things) |
These are indeed cheap clones, but they are Link clones that cannot program the ch32v003 - you need LinkE for that |
FIY: https://github.com/aappleby/PicoRVD is an example of how to flash CH32V003 from an RP2040. The code is fully open-source and should theoretically be adaptable to other uses, such as a host MCU flashing a peripheral CH32V003. |
Any WCH-Link alternatives support debugging over openocd? |
I noticed that there is an USART_IAP program in EVT(CH32V003EVT\EVT\EXAM\USART_IAP).The program is placed in the BOOT area. We can use the USART port to write Flash. |
Update README: add libusb package
Does CH32V003 the on-chip boot code have the ability to flash the device, or is the only way to flash a new CH32V003 is via SWD? We would like to attach this chip to a larger CPU and allow that larger CPU to update the flash in the CH32V003.
The text was updated successfully, but these errors were encountered: