OpenOCD increments dmi_busy_delay and idle_cycles too much during trigger examination

[taimur-silverliningeda]

OpenOCD going into trigger examination with a RISC-V based target initially has fewer DMI access delay and idle cycles but as the trigger examination proceeds, the dmi_busy_delay approaches ~1,000,000 cycles, causing the telnet terminal to be unresponsive to user and also causing command timeouts. The target has 8 triggers in total.

This behavior of incrementing 'dmi_busy_delay' to very high and impractical values is observed while using the breakpoint set command via OpenOCD telnet terminal 'bp PC 8 hw'. It is also observed when breakpoint is set using the abstract command method to set the trigger breakpoint registers and using 'resume' to resume the core.

OpenOCD log

By the time trigger examination completes, the dmi_busy_delay has been incremented to a high value of ~1,000,000 that the simple Debug Module dmstatus polling commands take so much time to respond that the terminal is rendered unusable and appears stuck to the user.

Target is being emulated and OpenOCD is communicating via jtag vpi port.
OpenOCD version: Open On-Chip Debugger 0.12.0+dev-04404-geb01c632a (2025-11-26-22:57)