Consecutive dtmcs scans after a dmi scan should never result in a busy status

[wajahat-ali-khan-96]

I'm trying to debug a failure that's showing up in dmi_jtag, a file present in the riscv-dbg module in pulp-platform. The issue comes up when I run the following scenario.

Observed Behavior:
The reset action will be sent at the beginning to ensure that we have transitioned to the Test-Logic-Reset state. The JTAG-based DMI agent sends a request for a DMI WRITE transaction followed by two dtmcs instructions. Upon checking the dmistat field after the 1st dtmcs instruction, it showed a DTM_SUCCESS status. However, it became DTM_BUSY after the 2nd dtmcs instruction. After reviewing the waveform, I found that when we run a single DMI instruction, it reaches the DM in the update state. Then, when we run a dtmcs instruction, the status becomes DTM_BUSY during the update state. In the RTL, the state is in waitWriteValid as we dont get dmi_resp_valid and it does not go to Idle state, causing the status to be marked as DTM_BUSY.
The observed behavior of RTL is shown in waveform. We also display a log file in which the check failed due to the occurrence of a DTM_BUSY response in 2nd dmi instruction.

As can be clearly seen, when the update state is high and state_q is in waitWriteValid, error_dmi_busy goes high, and the DMI response becomes DMI_BUSY.

Expected Behavior:
If we run a single DMI transaction than no matter what is the situation, there should be no DTM_BUSY response in the dmistat field of the dtmcs instruction, regardless of how many times the dtmcs instruction is executed as DMI is currently dealing with only single dmi transaction.

Result of 1st dtmcs instruction:

dmistat with DMI_SUCCESS

Result of 2nd dtmcs instruction:

dmistat with DMI_BUSY

Note: The JTAG clock frequency is lower than the system's clock frequency.