CH32v003 Info - Page 1
Forum section: electronics / general

author: keikai
author_rank: Contributor
timestamp: November 14, 2024, 04:25:28 pm
content: Some things i have found out about ch32v003A4M6 (Bare chips). Prolly mostly the same for other variants.1. PA1 and PA2 are by default External OSC pins. It means you must disable the OSC function to use it. Assumingyoure not using an external oscillator. The ch32v003 docs names the bit to remap PA1 & PA2 as PA12 which isconfusing at first because youd think its for pin named PA12. To do That in arduino:Code:AFIO->PCFR1 = AFIO->PCFR1 & 0xFFFF7FFF; //Sets PA1 & PA2 as I/O by clearing bit 152. To use PD7 as I/O you have to enable it in WCH Link Utility. its in dropdown textbox under "Enable Soft-Ctrl- iWDG." the option should say "Disable mul-func, PD7 used for IO function." When you have selected that option press ALT+F4 or look for the icon that says " Execute Checked Operation". By default the pin is used as NRST3. Serial.available() does not work, the timeout of Serial on ch32v003 is very high. It's 1000ms by default. SoCode:Serial.setTimeout(1);This should save you the trouble of pulling your hair. Serial.read() onlyworks the first time after that its pretty much just garbage or random. UseCode:Serial.readBytes(<buffer>,<size>);. if your data is shifted by 1 byte. For example if the first byte appears as 2nd then insert aSerial.read() before "Serial.readBytes"4. The swio pin can lock up randomly maybe because of code or delays. Im not sure why exactly. Im not evenusing the swio for anything. To see if its locking up then my advice is to wire/solder a led to a unused pin. Thencreate a function to blink led without using DELAY. You can do it with millis(). So when you do that you will beable to tell if the mcu is Alive but the swio is just misbehaving.To fix the swio pin lock up, assuming the mcu is alive. Use wch utility. Keep resetting the mcu with the tool thenquery info, then disable code-protect. If its still alive it will respond. Then erase the mcu. Though you mighthave to try a bunch of times. it helps if the swio wire or header youre using is closer to MCU.5. If you having problems programming flash with wch utility. Using the tool trying Resetting mcu, then Erase,then Read Flash then Program. If it doesnt work try Reading Flash then Erase , then Program. Make sure CodeProtect is not on when programing also.Will update this if I find any other problems/solutions etc.

author: HwAoRrDk
author_rank: Super Contributor
timestamp: November 14, 2024, 07:58:14 pm
content: Quote from: keikai on November 14, 2024, 04:25:28 pmAre you 100% sure about that? I have never had to do that for any CH32V003 chip I've ever used. I have a (bare-metal) codebase that uses both PA1 and PA2 pins as GPIO, and nowhere in the code do I ever touch AFIO->PCFR1.The datasheet indicates the default function of PA1 & 2 after reset are GPIO, and the default reset value of PCFR1.PA12_RM is 0 (pins used as GPIO). There are no non-volatile configuration options (e.g. option bytes) for that setting either. So all signs point to it being another issue, and not what you think it is.First of all, what kind of board I are you using the chips on? An off-the-shelf dev board, or a circuit of your own design? I ask because it brings to mindthis threadwhere the poster was having trouble using PA1 & PA2, but that was because the dev board being used had those pins wired by default to a crystal and not to header pins, and to use them as GPIO you needed to add jumper links to connect them to the header.Second, given that you mention Arduino, I presume you are using an Arduino board support package for CH32V003. Which? If this is layered upon the WCH HAL, and uses the WCH-provided startup assembly code, then it might end up calling one of theSetSysClockTo_*_HSE()HAL functions, because aSYSCLK_FREQ_*_HSEdefine is set somewhere. These functions do in fact set bit 15 of PCFR1 (AFIO->PCFR1 |= (1<<15);), because it thinks you want to use an external crystal.Edit:In fact, I now remember another thread where exactly the abovewas happening, and the poster thought the datasheet was in error exactly as you do.

author: keikai
author_rank: Contributor
timestamp: November 15, 2024, 01:46:17 am
content: Firstly I did infact say "To do That in arduino:" not mounriver studio or "baremetal codebase"and I didnt say it was a problem with the chip or that it was a "datasheet error". So please next time read the post carefully before answering.I tested PA1 and PA2 as IO before thats why i found out it wasnt working. Since you know now I was indeed correct saying that you need the code to enable PA1 and PA2 in arduino then i wont speak about it. Anyways instead of modifying the code in wch arduino core, it is better to do it in your sketch because when WCH decides to release an update you'd have do that modification again.also note i have ch32v003A4M6(16-pin) and ch32v003F4(20-pin) and ch32v203(48-pin) bare chips and i dont use osc with them. ch32v003A4M6 is different from ch32v003F4. I am not using any fancy dev board. Just bare adapter boards to make them compatible with pcb breadboardsMost people who buy these chips are using it in arduino ide. And i posted this to help those people who are just getting started

author: brucehoult
author_rank: Super Contributor
timestamp: November 15, 2024, 02:03:37 am
content: Quote from: keikai on November 15, 2024, 01:46:17 amOoooohh ... it is really great that WCH provide Arduino support for them ... but I'm not convinced that most people use it.Many people would I think use WCH's HAL and examples. And quite a lot ... in my circles maybe the majority ... use Charles Lohr's ch32v003fun, which adds some Arduino-like convenience to a HAL more similar to WCH's official one.

author: keikai
author_rank: Contributor
timestamp: November 15, 2024, 02:29:32 am
content: Pretty sure Arduino makes mcus more popular and throws more attention on them. So more people will buy them obviously. Hence why wch and other new chip brands make arduino cores for their sbc or mcus. People are more likely to buy chips that are easy to use and program. Ive seen some sbc and other mcus which can run linux but it doesnt have much appeal because linux itself aint easy to build nor get into. The milk v for example is much more appealing because you can have your cake and eat it too. Meaning it has support for linux and arduino. And i personally bought milk v because it supported arduino. The same can be said for esp32 series , stm32 and to a lesser extent raspberry pi,.Basically alot more people than you realize are using arduino or arduino like environments with those chips.

author: brucehoult
author_rank: Super Contributor
timestamp: November 15, 2024, 02:47:33 am
content: Quote from: keikai on November 15, 2024, 02:29:32 amI am a huge fan of what the Arduino IDE and library and ecosystem has allowed and I use it myself with Unos and Mega2650s and bare ATTiny85 chips and the Teensy 4 and the HiFive1 (the first ever RISC-V chip and board, Uno compatible, from 2016)I just think you are factually wrong about the CH32V003 specifically.

author: keikai
author_rank: Contributor
timestamp: November 15, 2024, 02:55:16 am
content: What is wrong? ch32v003 does have arduino support. And that alone bring alot more people to use those chips. Just because your group uses baremetal dont mean thats what its most used in. I have seen a bunch of people make arduino compatible cores for that chip even before wch made an official version. So you might just not know. I mean you didnt even know wch made an official core

author: brucehoult
author_rank: Super Contributor
timestamp: November 15, 2024, 03:54:36 am
content: Quote from: keikai on November 15, 2024, 02:55:16 amPerhaps you can stop with the personal abuse, and simply accept that we have a difference of opinion on something where the truth is unknowable?I've known about WCH's official Arduino port to their chips ever since they announced it in January:https://twitter.com/patrick_riscv/status/1742502427331616872I follow Patrick and he follows me (and I have talked to him on the phone), so of course I saw this.Here is me writing "Recently WCH has ported the Arduino library to their CH32V range of microcontrollers, including the $0.10 CH32V003" in a post FIVE MONTHS AGO.https://new.reddit.com/r/RISCV/comments/1dnzfgl/comment/lahvh5iSo, yeah, I am not uninformed.

author: HwAoRrDk
author_rank: Super Contributor
timestamp: November 15, 2024, 12:20:36 pm
content: Quote from: keikai on November 15, 2024, 01:46:17 amTo be fair, that sentence is the only,singleplace in the whole of your original post that contains the word "Arduino", and is easily missed. And it's not like you presented your post as explicitly for "Using CH32V003 With Arduino". One might assume, as I did, that much of what you wrote was for general usage, and not specific to the Arduino environment.Quote from: keikai on November 15, 2024, 01:46:17 amOkay, now we knowwhichArduino CH32V003 core you're using - the official WCH one - I can see what is going on there with the PA1 & PA2 issue. And it is exactly as I suspected. Yes, I admit you weren't assuming the datasheet was wrong, but instead you got fooled by an incorrect board configuration.The WCH Arduino core is based upon their HAL code, and so also uses their default startup code. You can seehere in system_ch32v00x.cthat there are a number ofSYSCLK_FREQ_*defines that control how the clocks are initialised. Whenever any of theSYSCLK_FREQ_*_HSEare defined, the correspondingSetSysClockTo_*_HSEfunction is called, which will set bit 15 of AFIO->PCFR1 to enable external crystal and disable PA1 & PA2 GPIO functionality.From what I can seehere in the core's boards.txtfile, you shouldn't need to use a piece of code to change AFIO->PCFR1 and re-enable PA1 & PA2 GPIO. It's simply a matter of having the wrong clock configuration selected in the Arduino IDE for your board. To put another way, it's enabling external crystal oscillator support because you're effectivelytelling it you want that, because you haven't specified that you want to use internal (HSI) clock.You just need to go into "Tools" -> "Clock Select" menu and choose an appropriate "Internal" clock option. Then it will, when compiling, set an appropriateSYSCLK_FREQ_*_HSIdefine, and you will be able to use PA1 & PA2 as GPIO without any special measures.Quote from: keikai on November 15, 2024, 01:46:17 amLike brucehoult, I would doubt that. When CH32V003 (and other WCH RISC-V chips) first started getting popular, Arduino support didn't even exist, and didn't come into being for quite a while. Maybe a lot of peoplenoware using the chips with Arduino, but I don't know.Anyway, such things are endlessly arguable without any concrete facts or evidence, so not worth talking about. But if you are trying to help people get started specifically with CH32V003 and Arduino, may I suggest in future you make it clear byputting that in the post title?

author: keikai
author_rank: Contributor
timestamp: November 15, 2024, 12:24:56 pm
content: @brucehoult Was just going off what you said no need for the personal attack. As i said before the post was for people new to the mcus. You should have just have left it at that.@HwAoRrDk bro did you even try wch's arduino core because if it had that option I would not have listed it as an issue. Like why do people on the forum just assume things. Also some things dont only pertain to arduino. The code yeh only for arduino but other stuff is not.Since people wont actually fact check here

author: HwAoRrDk
author_rank: Super Contributor
timestamp: November 15, 2024, 03:35:02 pm
content: Quote from: keikai on November 15, 2024, 12:24:56 pmAll I can say is that, going off the latestboards.txtfile in the WCH Arduino core GitHub repository, there is definitely a "Clock Select" menu entry defined which will allow a user to configure for HSI clock and free up PA1 & PA2 for GPIO use. Take a look, it'sright there.However, upon further investigation, it appears this "Clock Select" menu addition, even though it was implemented incommit 3c67f6bback on June 3, 2024, has not yet made it into a released package. The current (at time of writing) latest release, version 1.0.4 doesnotfeature that change. If that's what you're using, then yes, you don't have that optiontoday.But was it not unreasonable for me to think that a change made nearly6 months agohad been released? The PA1/2 GPIO problemwillcease to be an issue at some point in the near future, so I'm afraid to say your advice will probably become obsolete at that point. Now if WCH could just pull their finger out and actually cut a new release for the Arduino core package...And please, a little less bad attitude. You seem to have a chip on your shoulder and think that anyone who questions your assertions is being hostile. I don't believe that's anyone's intention. And I'm not pulling unfounded assumptions out of my arse; my responses have been based on my own experience, previous discussions on this forum, and evidential information that - while not ultimately giving the true picture - was at least not incorrect.

author: brucehoult
author_rank: Super Contributor
timestamp: November 15, 2024, 04:06:06 pm
content: Quote from: keikai on November 15, 2024, 12:24:56 pmI made no personal attack. On the other hand, every message of yours so far contains one or more assertions that the other person is stupid, lying, uninformed etc.You are on the fast track to being ignored. And I think not only by me.

author: keikai
author_rank: Contributor
timestamp: November 15, 2024, 06:14:58 pm
content: O.o where have I made anyone seem stupid.It was both of you that made me seem stupid for stating something thats was infact an issue. But instead of owning up to it one decided to glace over it and still say that he/she was technically correct so. One said i made an error and said i said the datasheet was in error. Then without actually opening arduino ide says the clock option is there and make it seem like i overlooked that option.I did infact know already that it was code in the arduino core causing that but i decided not to tamper with it because it will get updated anyway. I am fine with someone disagreeing with me. What im not fine with is people making it seem like i didnt put effort in doing research. Like one of you said i dont pull shit out my rear. And someone who is new to this stuff wont go into core files to modifying header or code files willy nilly.But anyway thanks anyway for replying to post. Do better. Only on this forum have i experienced people just making you seem dumb when you're just trying help others.