Corruption of register a0 during step-by-step debugging

[MikeSmith78]

MRS_Community_V160
OpenOCD 0.11.0+dev-02415-gfad123a16-dirty (2023-09-22-10:36)
WCH-LinkE-R0-1v3 (firmware v2.11)
Chip CH32V307VCT6

Problem: during step-by-step debugging, register a0 is overwritten with the value 0xE0000000, if debugging view "registers" is open, and registers ft0... are visible.
The debugger probably uses dscratch interface to read ft0..ftN (after next step, dscratch0/1 has same value, 0xE0000000), and does not restore contents of the a0 register.

This problem exists while mstatus is zero. At the end of startup code, value 0x6088 is written to the mstatus, and debugger starts working correctly.

[joelpmichael]

I'm seeing the same thing, even when doing instruction-level single-stepping, but I don't think mstatus has anything to do with it because I'm seeing it during normal program execution both inside an ISR and outside of any interrupt context.

MRS Community 1.70 (Linux)
Open On-Chip Debugger 0.11.0+dev-02415-gfad123a16-dirty (2024-02-19-14:11)
WCH-LinkE-R0-1v3 (firmware 2.12)
MCU is CH32V203C8T6

Instruction: andi a5,a0,17

Registers changed:
A0: 0x40006000 -> 0xe0000000 UNEXPECTED
A5: 0x40006000 -> 0x0 (expected)
PC: 0xd18 -> 0xd1c (expected)
DCSR: 0x40009043 -> 0x40009107 (expected)
DPC: 0xd18 -> 0xd1c (expected)

Other registers maybe of interest (unchanged)
mstatus: 0x1800
mscratch: 0x20004e00
mepc: 0x801123c
mcause: 0x8000000e
dscratch0: 0x0
dscratch1: 0xe0000000 (-536870912)
priv: 3