CH32V003 -J4 (SOP8) pins (UPDATE: how to brick your -J4)

[rhodges]

I was looking at the pins for the -J4 (SOP8) version of the CH32V003, and see that pins 1 and 8 seem to be "doubled-up" with other GPIO and alternate functions.

It appears that two  blocks share pin 1 and another two share  pin 8. Is this correct? Do I need to set the unused block to floating input?

Pin 1 can be GPIO PA1 or PD6. And pin 8 can be PD1 or PD5.

[rhodges]

After thinking about this today and looking again at the pin definitions, I think that pin 1 has two GPIO blocks attached to it, PA1 and PD6. And pin 8 has three GPIO blocks attached, PD4, PD5, and PD1.

I will have to test this, but it appears that WCH decided to have more GPIO blocks than pins, and overloaded pins 1 and 8 here. So as a user, I choose which blocks I want to be  active and set the unused blocks to floating input.

This does seem to make sense when it is easy to have the blocks there, but the pin count is limited.

[westfw]

I think that pin 1 has two GPIO blocks attached to it, PA1 and PD6.

I've considered doing things like that at the board level, for all those low-pin-count "Arduino-like" boards that uses a relatively high pin-count chip (say, like the ATmega4809 on a Nano Every.)  Instead of leaving pins simply un-connected, double (or more) them up to get functionality that might have been on the other chip pins brought out to board pins.  As long as the code doesn't enable both functions at the same time, it should work OK.  (alas, Arduino-class boards tend to be "opportunistically routed", so such pin interconnections tend not to work very well in practice.)

it appears that WCH decided to have more GPIO blocks than pins

Perhaps they're using the same chip that they have in their larger packages, and doing something similar?  Maybe I think it's clever, since I had a similar idea :-)

[rhodges]

It looks like I just bricked my first -J4 SOP8 piece.

I started with the WCH GPIO toggle code and my -F4 TSSOP20 on the evaluation board I bought on Aliexpress. After some time of trying to find the pins for LED1 and LED2, it turns out that you connect a jumper from the pin you want to use to the LED pin. Okay, that's fine. Then I changed the code a bit to verify that it was actually my code on the device.

The original code used GPIO D0 for the LED, but the -J4 does not have D0. So I changed it to C1 in the code and on the board. The LED flashes correctly.

Then I hooked up a -J4 that I had soldered onto a SOP8 to DIP8 breakout board and connected an LED and resistor to Vdd and C1. It programmed, but the LED was flashing slowly. Okay, the original code was set for HSE and 48mhz, and my board did not have a crystal. So it was running from the HSI (24mhz) after timing out in the HSE 48mhz setup. I changed the config to HSI 24mhz, and now it won't program. The IDE just gave me "board chip status error".

SWIO is on pin 8, but I am not using that as GPIO. I learned on STM32 to never configure the programming pin as GPIO.

It turns out the the WCH sample code uses the UART to send messages, and ...
The UART uses D5 as the UART TX alternate function. And D5 is on pin 8.

The -J4 chip does not have an external reset, so it looks like I just bricked my (ten-cent) chip.

If I want to use the UART TX, it looks like I can use D6 (pin 1) instead if I modify USART_Printf_Init().

Hope this helps someone!

[Sacodepatatas]

That's a typical situation that didn't happen to me yet but i've read about it a lot. The WCH-LinkUtility can erase the chip without using Reset, just let the programmer control the power lines.

[PCB.Wiz]

The WCH-LinkUtility can erase the chip without using Reset, just let the programmer control the power lines.

Hmm. How do they prevent accidental erase ?
Unless they mean it comes out of POR reset and spends a few milliseconds in BOOT ROM, allowing host to send an erase command ?

[brucehoult]

SWIO is on pin 8, but I am not using that as GPIO. I learned on STM32 to never configure the programming pin as GPIO.

I think that's ok, because programming can be done while holding reset low (or something). Using the SWIO pin as GPIO prevents debugging, but not programming, as long as the package brings out the reset signal (NRST) ... which the 8 pin package doesn't. Ahhh.

Yeah, might be best to debug code on a bigger package, if you want to use all the pins.

[rhodges]

The WCH-LinkUtility can erase the chip without using Reset, just let the programmer control the power lines.

Thanks for that, I will give it a try. I don't mind tossing a cheap part, but I did (and will) spend time soldering that part on the board.

[rhodges]

Yeah, might be best to debug code on a bigger package, if you want to use all the pins.

Yes, I agree. I just wanted to try the -J4 in real life action. Oops! I used the MFG sample code without thing through every detail. Yes, I did change the GPIO pin for the LED, but I did not see that the UART TX would change the programming pin. That is my fault. I hope others learn from my mistake.

[boreack]

I just get some J4M6 version of the CH32V003 to reduce pins to solder 
The option for erasing the chif if you use the UART is pretty easy and fast.
Just conect the WCH-LinkE as normal, and select "Clear All Code Flash-By Power Off". Works as a charm.

Greetings.

[DavidAlfa]

I usually leave a secret routine to erase the flash when I'm locking out the mcu access in a package without Boot0 pin (For example, detect a certain pin compination at boot, then wait for a pulse within 2s, or receiving a defined i2c sequence).
I you have it, you can just write a ram program to trigger a flash erase. This was my approach, should be easy to make something similar for ch32.