CH32V307 CH32V317 issues collection thread

[Xyphro]

Hi!

As mentioned here: https://www.eevblog.com/forum/microcontrollers/the-ch32v317-has-appeared-but-not-much-about-it-yet/
.. I program CH32V317 extensively and noticed some issues.

And communication with WCH is limited to short answers (if an answer comes at all) and not looking deeply into things or  issue reports or Errata sheets.

So I wanted to start a thread to collect issues / potential workarounds.

Let me start:
- CH32V317 integrated PHY which is actually the CH182 PHY DIE does not report autonegotiated duplex mode properly when 100MBit Half-duplex is aligned. In 50% of the cases it reports correctly half-duplex, in 50% full-duplex. I checked the Link status words during an issue case and saw that the 2 PHYs correctly agree always on half-duplex, however the register interface does after auto-negotiation completeness report sometimes the wrong duplex mode.
My workaround for now: So far none, I enabled the possibility to set the duplex mode and speed mode without auto-negotiation. Will take that up at a later stage and report it in this thread.
Note: 10 MBit Full and Half duplex and 100 MBit Full duplex is detected consistently correct. Only 100 MBit half-duplex fails every now and then.

- CH32V317 "hardened" factory bootloader allows readout of read protected code. While the bootloader is designed relatively secure, there are some cases where stack/array index overflow techniques can be applied. Or the fact that global variables are used for 3 bootloading interfaces can be used. But there is also a case where it allows without sophisticated stack/RAM analysis to readout the data - proven in practice to work.
Why I looked into this: I wanted to stimulate WCH to open up information on replacing or turning off the factory bootloader, however they were not interested/replying. So just want to make you aware that flash readout IS possible due to the presence of the factory bootloader, no matter if you turn jTag off or do other things - there's no official way to work arround this unless you look into this: https://github.com/robots/wch-ch32v20x-flash
(which only allows replacement of the factory bootloader during an active debug session and not when the code is ran without debugger).
Of course knowing that the flash in CH32V2/3xx is just an SPI flash enables also taking out the DIE and contacting and reading it, so that read protection flaw is not that strong, but still it limits the risk a bit more as less people have the right tools available to do so.

- High speed enumeration, also of the factory boot loader and the official development board is on the edge, especially when using USB3 Hubs / ports. Sometimes it fails to enumerate while other High speed devices enumerate with the same cable / USB Hub chain. An Eye diagram measurement is outstanding - waiting for High speed scope access, though I have the right Diffprobes at home [somebody wants to spend me an old >= 2.5GHz speed scope? :-)]
The High speed chirp is correct in terms of timing and DC voltage levels, but still it sometimes it fails to enumerate and get into an endless renumeration loop state. The PC assumes it enumerated as High speed device, the Device behaves as if it falls back to full speed. The PC sends several SOF packets / get descriptor requests and the device never gets any interrupt. My workaround so far: Detect that situation by monitoring the count of "USB busresets per second" and enforcing full speed mode on the CH32V317 side. The USB HSD IP has some undocumented registers btw... No time yet to play with them as such things turn out in multiple days of effort.

I had a few more, will add once they pop up again :-)

I like the device, but the information politics of WCH make it hard to work with them. On the simple CH32V003 they share openess and once you are into that vendor they close the gate.
I can live with a "NO, because" as answer, but not getting any answer and being forced into reverse engineering and workaround finding loops on something which is likely known already to them is not nice.

Best regards,

Kai
Edit: Of course I can also always be wrong with my "findings" - nobodies perfect, but as it would have helped me knowing if somebody has ran into similar issues before would have helped me speeding up finding a solution or to know on which area to focus in searching/debug.

[SiliconWizard]

Regarding USB, not sure I fully understand what the problem you found exactly is? Is it only when using the bootloader?

I have used USB HS quite extensively on the CH32V307 and have never found any enumeration problem. But in my own firmware. I don't use the bootloader in USB mode.

Can you elaborate?

[n1kt0]

Thanks for sharing! I bought a few chips a while back because they have the integrated Ethernet PHY and MAC. I thought it would be an interesting learning exercise to roll my own embedded network stack on one of these. Sounds like troubleshooting the hardware will add additional obstacles.

[spostma]

sometimes good information snippets can be found on the Chinese WCH forum (via google translate):
https://www-wch-cn.translate.goog/bbs/forum-101-3.html?_x_tr_sl=auto&_x_tr_tl=en&_x_tr_hl=en-US&_x_tr_pto=wapp

Alternatively one can browse the site in Chinese, and copy-and-paste text to google translate, which is cumbersome.

however, I did not manage to register there as user because my phone number was not recognized as valid.

[exzenter]

I use the CH32V series quite a bit, from the 003's up to the 317. For most embedded use cases, they hit the spot on bang-for-buck for me, especially because I do like Ethernet a lot.

For the PHY integrated into the 317, the RM references a CH182DS2 datasheet, but last I checked they only provided a DS1, which upon perusal seems rather limited. Particularly, the example eth_driver for the 317 supplied by WCH futzes around with some undocumented (so far) registers on the PHY, so I would be most interested in having at least some information on what that's all about.

Additionally, I'd like to know whether any kind of interrupt mechanism is hooked up for the PHY. I don't really like polling for link-state. For the internal 10M PHY on the 307, you can just register for the interrupt, though it is somewhat buried in the Peripheral implementation headers.

[spostma]

the Chinese website has a CH182DS3 link
https://www.wch.cn/downloads/CH182DS3_PDF.html

that contains the CH182DS3.pdf V1.2 file in Chinese.

I attached this file and the Google translation of it for your convenience.

[exzenter]

Thank you for finding that, good thinking!

However it seems to have even less info than the DS1, seeing that it only has the Pinout (Section 1) Pin descriptions (Section 2) and Package information (Section 3).

DS1 includes at least a description of the standard PHY registers and the Interrupt mask