X-Git-Url: https://review.openocd.org/gitweb?a=blobdiff_plain;f=src%2Ftarget%2Fadi_v5_jtag.c;h=48b4a7b8a0c2debb597fcb457a0ac1504b8d765c;hb=e03f45f6996ca9b646c228cad8431dea73054818;hp=0a374bea82d500d9134141d718ca3fd9881bf5ef;hpb=dcba0709580cd8b0d2869894d2f7e22195b7e3d7;p=openocd.git diff --git a/src/target/adi_v5_jtag.c b/src/target/adi_v5_jtag.c index 0a374bea82..48b4a7b8a0 100644 --- a/src/target/adi_v5_jtag.c +++ b/src/target/adi_v5_jtag.c @@ -86,8 +86,11 @@ int adi_jtag_dp_scan(struct adiv5_dap *dap, struct arm_jtag *jtag_info = dap->jtag_info; struct scan_field fields[2]; uint8_t out_addr_buf; + int retval; - arm_jtag_set_instr(jtag_info, instr, NULL, TAP_IDLE); + retval = arm_jtag_set_instr(jtag_info, instr, NULL, TAP_IDLE); + if (retval != ERROR_OK) + return retval; /* Scan out a read or write operation using some DP or AP register. * For APACC access with any sticky error flag set, this is discarded. @@ -188,28 +191,38 @@ static int jtagdp_transaction_endcheck(struct adiv5_dap *dap) /* too expensive to call keep_alive() here */ -#if 0 - /* Danger!!!! BROKEN!!!! */ - adi_jtag_scan_inout_check_u32(dap, JTAG_DP_DPACC, - DP_CTRL_STAT, DPAP_READ, 0, &ctrlstat); - /* Danger!!!! BROKEN!!!! Why will jtag_execute_queue() fail here???? - R956 introduced the check on return value here and now Michael Schwingen reports - that this code no longer works.... - - https://lists.berlios.de/pipermail/openocd-development/2008-September/003107.html - */ - if ((retval = jtag_execute_queue()) != ERROR_OK) - { - LOG_ERROR("BUG: Why does this fail the first time????"); - } - /* Why??? second time it works??? */ -#endif + /* Here be dragons! + * + * It is easy to be in a JTAG clock range where the target + * is not operating in a stable fashion. This happens + * for a few reasons: + * + * - the user may construct a simple test case to try to see + * if a higher JTAG clock works to eke out more performance. + * This simple case may pass, but more complex situations can + * fail. + * + * - The mostly works JTAG clock rate and the complete failure + * JTAG clock rate may be as much as 2-4x apart. This seems + * to be especially true on RC oscillator driven parts. + * + * So: even if calling adi_jtag_scan_inout_check_u32() multiple + * times here seems to "make things better here", it is just + * hiding problems with too high a JTAG clock. + * + * Note that even if some parts have RCLK/RTCK, that doesn't + * mean that RCLK/RTCK is the *correct* rate to run the JTAG + * interface at, i.e. RCLK/RTCK rates can be "too high", especially + * before the RC oscillator phase is not yet complete. + */ /* Post CTRL/STAT read; discard any previous posted read value * but collect its ACK status. */ - adi_jtag_scan_inout_check_u32(dap, JTAG_DP_DPACC, + retval = adi_jtag_scan_inout_check_u32(dap, JTAG_DP_DPACC, DP_CTRL_STAT, DPAP_READ, 0, &ctrlstat); + if (retval != ERROR_OK) + return retval; if ((retval = jtag_execute_queue()) != ERROR_OK) return retval; @@ -243,8 +256,10 @@ static int jtagdp_transaction_endcheck(struct adiv5_dap *dap) return ERROR_JTAG_DEVICE_ERROR; } - adi_jtag_scan_inout_check_u32(dap, JTAG_DP_DPACC, + retval = adi_jtag_scan_inout_check_u32(dap, JTAG_DP_DPACC, DP_CTRL_STAT, DPAP_READ, 0, &ctrlstat); + if (retval != ERROR_OK) + return retval; if ((retval = dap_run(dap)) != ERROR_OK) return retval; dap->ack = dap->ack & 0x7; @@ -289,12 +304,16 @@ static int jtagdp_transaction_endcheck(struct adiv5_dap *dap) LOG_ERROR("JTAG-DP STICKY ERROR"); /* Clear Sticky Error Bits */ - adi_jtag_scan_inout_check_u32(dap, JTAG_DP_DPACC, + retval = adi_jtag_scan_inout_check_u32(dap, JTAG_DP_DPACC, DP_CTRL_STAT, DPAP_WRITE, dap->dp_ctrl_stat | SSTICKYORUN | SSTICKYERR, NULL); - adi_jtag_scan_inout_check_u32(dap, JTAG_DP_DPACC, + if (retval != ERROR_OK) + return retval; + retval = adi_jtag_scan_inout_check_u32(dap, JTAG_DP_DPACC, DP_CTRL_STAT, DPAP_READ, 0, &ctrlstat); + if (retval != ERROR_OK) + return retval; if ((retval = dap_run(dap)) != ERROR_OK) return retval;