RISCV: Add some quirks to be compatible with CH32V3x chips

[mean00]

Detailed description

• These patches enable breakpoints to work to some extent with the CH32V3x chips (maybe CH32V2x also)

• The first patch is simple enough, the CH32V3 chips make an unexpected reply when probing the isa width. Adding that error code to the list makes it being detected properly as RV32.

• The 2nd patch is a bit more quirky. When probing the triggers, the code is expected either to have a reply_ok and a value or an error and then it reads the value the alternate way. The WCH replies ok, but the reply is empty. The patch uses an empty reply as reason to switch to the alternate method.
  I'm really unsure this is the right thing to do and/or if this could have side effects.

With these two patches, breakpoints work to some extend with the CH32V3x.
To test it, you need to have a modified bmpa sw to support the WCH link (see perigoso work) and a board support package for the CH32V3x chip (i have a early development one if interested).

Your checklist for this pull request

• I've read the Code of Conduct
• [x ] I've read the guidelines for contributing to this repository
• [x ] It builds for hardware native (make PROBE_HOST=native)
• [x ] It builds as BMDA (make PROBE_HOST=hosted)
• [x ] I've tested it to the best of my ability
• [x ] My commit messages provide a useful short description of what the commits do

Closing issues

None, this is a part of CH32v3x support.

[dragonmux]

There's a small tweak can be made in riscv_heart_discover_triggers(), otherwise this looks good. When we get to the v2.0 cycle we'll aim to schedule this for merge with the WCH RISC-V debug PR from Perigoso.

[perigoso]

This change is now part of #1399

@dragonmux is it correct that you added the additional RISCV_HART_NOT_SUPP check on the feature/risc-v branch?

[dragonmux]

We'd have to double-check the code to answer that - could you link a reference to which check you're referring to?

[perigoso]

We'd have to double-check the code to answer that - could you link a reference to which check you're referring to?

Part of this PR was adding RISCV_HART_NOT_SUPP as a valid status here:

		/* If that failed, then find out why and instead try the next narrower width */
		if (hart->status != RISCV_HART_BUS_ERROR && hart->status != RISCV_HART_EXCEPTION)
		switch (hart->status) {
		case RISCV_HART_BUS_ERROR:
		case RISCV_HART_EXCEPTION:
		case RISCV_HART_NOT_SUPP: // WCH CH32Vx chips reply that
			break;
		default:
			return 0;
			break;
		}
		if (hart->access_width == 32U) {

But while cherry-picking this commit I noticed the base branch already had it:

		/* If that failed, then find out why and instead try the next narrower width */
		if (hart->status != RISCV_HART_BUS_ERROR && hart->status != RISCV_HART_EXCEPTION &&
			hart->status != RISCV_HART_NOT_SUPP)
			return 0;
		if (hart->access_width == 32U) {

I assumed this meant you added this as part of the last rebase, but wanted to confirm

[dragonmux]

Ahhh, yes, we'd done that when preparing the RV branch for handling more than the ESP32-C3, yes

[dragonmux]

Note to self: Cherry-pick the fixes on this branch into the ESP32-C3 branch having fubbed merging this to the RISC-V branch by accident.