search

ch32-rs / wlink

An open source WCH-Link library/command line tool written in Rust.
Apache License 2.0
157 stars 26 forks source link

Error: DM Abstract comand error: Parity on CH32V307V-R1-1v0 board (CH32V307 VCT6) #16

Closed lennyerik closed 1 year ago

lennyerik commented 1 year ago

I have a CH32V307V-R1-1v0 devboard (second revision of the CH32V307 evaluation board) running WCH-Link 2.9 and am trying to flash it using wlink.

All operations supported by wlink (flashing, reading and writing registers, resetting, ...) seem to work fine on the first run after power-cycling the board. However, subsequent runs of the same command (especially when executing the same command multiple times in quick succession) sometimes result in the error Error: DM Abstract comand error: Parity.

This issue occurs with all subcommands and I managed to track it down to this check in operations.rs. As I am not very familiar with the WCH-Link protocol, I'm not sure on what exactly could be causing this problem, although it looks to me like read_reg is called on chip initialisation somewhere and fails sometimes because ensure_mcu_halt caused an abstractcs cmd error somehow.

I added a temporary fix in my own fork of the repo which just clears the abstractcs cmderror queue on each call to ensure_mcu_halt. This seems to have fixed the issue, but I'm hesitant to open a PR, since I'm unsure whether this is actually a fix for the root cause of the issue and or just a workaround. I'd appreciate it if someone more familiar with WCH-Link could have a look at the fix first.

Full log of wlink -v regs from when this issue occurs:

16:56:10 [INFO] WCH-Link v2.9 (WCH-Link-CH549)
16:56:10 [INFO] Attached chip: CH32V30x(0x30700518)
16:56:10 [DEBUG] (1) wlink::commands: TODO: cannot read chip id
16:56:10 [DEBUG] (1) wlink::operations: Chip UID: 00-00-00-00-00-00-00-00
16:56:10 [DEBUG] (1) wlink::operations: Flash protected: false
16:56:10 [DEBUG] (1) wlink::operations: SRAM CODE mode: 2
Error: DM Abstract comand error: Parity

Note that the cannot read chip id log is most likely unrelated to this issue as it happens with this board regardless of whether the Abstract command error occurs.

Schildkroet commented 1 year ago

I also ran into this problem. For me it happens when i send alot data through serialport on debugger. Unplugging the debugger clears the issue.

lennyerik commented 1 year ago

Curiously, based on my testing, the proprietary WCHLink-OpenOCD binary does not seem to have this issue at all. Perhaps they ignore the error or clear the cmderror queue too at some point?

andelf commented 1 year ago

Thanks for the report. I'll check this on my CH32V307 board later.

andelf commented 1 year ago

Resolved. "QingKeV2 Microprocessor Debug Manual" didn't mention a step used in openocd code to clear cmderr state.

andelf commented 1 year ago

@lennyerik Could you try the fixed version? It should be ready when nightly build released.

lennyerik commented 1 year ago

The fix also works on my board. :+1: Thanks for taking the time to look into this issue!