Help getting it to work on a CH32F103C8T6 board

[rocwhite168]

I have a CMSIS-DAP dongle from Aliexpress. It's based on CH32F103C8T6, supposedly a drop-in replacement of STM32F103C8T6, so I've been trying to adapt the bluepill and the stlinkv2-dongle for building a working dap42 firmware for it. The firmware gets recognized by my Windows 11 laptop, but I cannot get it to work with openocd:

$ openocd.exe -f interface/interface-dap42.cfg -f target/stm32f1x.cfg

...
Info : CMSIS-DAP: SWD supported
Info : CMSIS-DAP: Atomic commands supported
Info : CMSIS-DAP: Test domain timer supported
Info : CMSIS-DAP: UART via USB COM port supported
Info : CMSIS-DAP: FW Version = 2.1.0
Info : CMSIS-DAP: Serial# = 0F4100202EBC6B23CDAB70BB
Info : CMSIS-DAP: Interface Initialised (SWD)
Info : SWCLK/TCK = 1 SWDIO/TMS = 1 TDI = 0 TDO = 0 nTRST = 0 nRESET = 0
Info : CMSIS-DAP: Interface ready
Info : clock speed 1000 kHz
Error: Error connecting DP: cannot read IDR

I was able to use the stock firmware the dongle came with (which is now erased), so I assume my laptop, openocd install, and the dongle hardware are all fine. I made the following pin changes in DAP/CMSIS_DAP_config.h. Are there perhaps other changes needed for a new board?

#define SWCLK_GPIO_PORT         GPIOB
#define SWCLK_GPIO_PIN          GPIO10
#define SWDIO_GPIO_PORT         GPIOB
#define SWDIO_GPIO_PIN          GPIO11

As a side, is the pin mapping correct for ST-Link v2? I saw it's identical as for blue pill, but it's different from what's stated here, which agrees with my own tracing.

For reference, the CH32F103C8T6 has the following header/pin mapping:

TX: PA9
RX: PA10
TCK/CK: PB10
TMX/IO: PB11
DIO: PA13/SWDIO
CLK: PA14/SWCLK
GND: V_SS
3.3V: VDD
5V: USB VCC

[devanlai]

I was able to use the stock firmware the dongle came with (which is now erased), so I assume my laptop, openocd install, and the dongle hardware are all fine. I made the following pin changes in DAP/CMSIS_DAP_config.h. Are there perhaps other changes needed for a new board?

#define SWCLK_GPIO_PORT         GPIOB
#define SWCLK_GPIO_PIN          GPIO10
#define SWDIO_GPIO_PORT         GPIOB
#define SWDIO_GPIO_PIN          GPIO11

In theory, that should be pretty much all that's needed.

As a side, is the pin mapping correct for ST-Link v2? I saw it's identical as for blue pill, but it's different from what's stated here, which agrees with my own tracing.

In the schematics I've seen, generally both PB14 and PA5 are connected to SWCLK.
I wasn't aware that some clones used PB0 instead of PB6 for reset (though in general the reset line that's exposed is the SWIM reset pin, which is why the stock STLink firmware doesn't use it for SWD / JTAG).

For reference, the CH32F103C8T6 has the following header/pin mapping:

TX: PA9
RX: PA10
TCK/CK: PB10
TMX/IO: PB11
DIO: PA13/SWDIO
CLK: PA14/SWCLK
GND: V_SS
3.3V: VDD
5V: USB VCC

It's possible it could be something trivial like the pins needing extra configuration and not actually toggling, or it could be something more complex like the bit-bang delay timing being different / wrong for the CH32. If you could hook up a logic analyzer, that would help narrow down the issue.

[rocwhite168]

That's unfortunately outside my area of knowledge, and I'd hate to make this into a hand-holding learning session :) But if you can give some high-level pointers what pins to measure and what types of signals to expect, I can read up on this and explore a bit more myself. I only have a handheld-type oscilloscope.

[devanlai]

Sorry it took me a while to look at this closer, I've been busy at work.

I ordered a similar looking dongle from AliExpress that has the same pinout. Unfortunately, it came with a real STM32, so I can't directly test your setup. Since I tested on it, I realized that I forgot that you also need to set another definition in cmsis_dap_config.h to facilitate the SWDIO direction switching:

#define SWDIO_GPIO_PIN_NUM 11

Hopefully adding that definition will fix the issue.
I can provide logic analyzer traces if it's still not working for you.

Also, since I traced the pins anyways, the two red LEDs are active high and attached to PA2 and PA3.

[rocwhite168]

Wow, thank you so much for taking on this much trouble to help!! It looks like the single addition may have solved the problem. I'm seeing some other errors and will look more into it and report back.

[rocwhite168]

With the change #define SWDIO_GPIO_PIN_NUM 11, the probe was able to connect to the target (another identical board). But for some reason, when I flashed the firmware using openocd flash-dap42.cfg, it failed after the reset halt step. A previous Black Magic firmware still loads when the board is connected to USB, but I cannot connect to it using DAP42 (or ST-Link). Do you have any ideas what might have caused the board to lose SWD?

[devanlai]

With the change #define SWDIO_GPIO_PIN_NUM 11, the probe was able to connect to the target (another identical board). But for some reason, when I flashed the firmware using openocd flash-dap42.cfg, it failed after the reset halt step. A previous Black Magic firmware still loads when the board is connected to USB, but I cannot connect to it using DAP42 (or ST-Link). Do you have any ideas what might have caused the board to lose SWD?

Is this specific to flashing Black Magic firmware? It could be remapping the SWD pins. Can you try flashing some other firmware like a blinky program?

[rocwhite168]

The DAP42 (or ST-Link-v2) was no longer able to connect to the dongle at all. It was able to before I tried to flash the second dongle with openocd. The flashing failed before the flash write_image step, and the previous firmware still loads, just the SWD was somehow disabled..

[devanlai]

I'm still not quite able to follow the sequence of events here, maybe because of the self-referential nature of using one debug probe to flash another debug probe.

In case it helps, I've pushed my branch that I'm using here, and I'm attaching a copy of the image that I built.

DAP103-AliExpress-NoBootloader.zip

[rocwhite168]

What happened is the following:

1. I have two Aliexpress CMSIS-DAP dongles, call them A & B. B was previously flashed with Black Magic Probe.
2. I flashed A with DAP42 after making your suggested change #define SWDIO_GPIO_PIN_NUM 11. A was now able to connect to B. As a (badly chosen) test, I then tried to use A to flash DAP42 to B. The command I used was openocd -f interface-dap42.cfg -f flash-dap42.cfg (with suitable changes to source [find target/stm32f1x.cfg]).
3. The process failed after the reset halt step. At this point, neither A or another ST-Link v2 clone I had can connect to B anymore.
4. However, if B was connected to PC with a USB cable, it was still correctly recognized and showing the BMP firmware and COM port etc.

This might not be a DAP42 issue at all, but I don't have extra spare boards to test at the moment, so please feel free to close this issue. I do sincerely appreciate your effort to help!!