[openocd:tickets] #432 Issues with Agilex 5 board with ADIv6 and integrated USB Blaster II interface

[Tomas V. <to...@us...>]

> It seems like a lot of transactions return a WAIT condition, and the code says it's slowing down and resending, but I don't actually see how it's slowing down.

The transactions previously send at once to the adapter are replayed one by one with immediate checking of returned ack. The log shows that the slow transactions replay works even with ADIv6. But this mechanism is intended to solve occasional problems with the access slower than usual, should not trigger on each memory access.

The problem is in configuration. The target memory seems too be slow, perhaps due to disabled cache. Check **dap memaccess** setting and increase it enough to get rid of WAITs
Also slowing down **adapter speed** may help at cost of slowing all, not only AP transactions.



---

**[tickets:#432] Issues with Agilex 5 board with ADIv6 and integrated USB Blaster II interface**

**Status:** new
**Milestone:** 0.11.0
**Created:** Thu Sep 05, 2024 02:49 AM UTC by Bill Paul
**Last Updated:** Thu Sep 05, 2024 02:49 AM UTC
**Owner:** nobody


Hi all:

Recently I was called on to work on an Intel/Altera Agilex 5 FPGA E-Series 065B Development board, which has an ARM processor subsystem with four Cortex-A76 cores. I wanted to be able to use OpenOCD to debug it, and it did eventually help solve the problem I ran into, but something is not quite right.

The main issue is that the Cortex-A76 processors use the Arm CoreSight 600 debug architecture, which uses ADIv6 debug interface protocol rather than ADIv5. This is actually the first time I've run across a target board that needs ADIv6, and I'm afraid I may be on the bleeding edge of something here.

Debugging the Agilex 5 can be done in a couple of ways:

1) via direct JTAG connection to the Arm cores (using a header connector I don't recognize)
2) using an external USB Blaster II debugger
3) using on-board USB debug (which looks just like a USB blaster II, as it turns out)

Intel provides the Quartus development software, which includes, among other things, a jtagd server which is designed to interface with the Altera Jtag Interface software client library. You can actually find this library here:

 https://github.com/intel/aji_openocd.git
 
 The Quartus software also comes with a pre-built version of OpenOCD which is designed to use the AJI library as an interface type. You can find the source for it here:
 
 https://github.com/intel/aji_openocd.git
 
 Initially I tried using the OpenOCD supplied with Quartus, but it doesn't work because it's an old version which doesn't have ADIv6 support. And of course the most recent official version of OpenOCD does have ADIv6 support, but it doesn't support the AJI client library as an interface.
 
 Originally, the board being debugged was in a remote location and I had limited access to it, so I decided to take the AJI client library support from Intel's aji_openocd repo and shoehorn it into the latest version. I actually got this to work well enough to scan the ROM tables from the SoC and put together a working config file, but I ran into a problem: very often, I would see messages of the form "Info : DAP transaction stalled (WAIT) - slowing down and resending".
 
 Now, at first I thought this was just due to me not integrating the AJI client library code into OpenOCD correctly, however just this week I finally gained access to another board, and I figured out that I could use the Altera USB Blaster II interface that OpenOCD supports and directly talk to the target through its USB port instead of using the jtagd server from Quartus and the AJI client library. (I did need Quartus software to get to the USB Blaster II firmware file though.) I find that I see exactly the same problem with this configuration though.
 
Bear in mind, I tend to use OpenOCD with GDB, and a lot of things worked fine. I was able to stop the processor, set breakpoints and inspect the CPU registers. However what did not work was disassembling the code. I observed two things:
 
 1) The disassembly would be gibberish
 2) I would see a lot of messages from OpenOCD of the form: "Info : DAP transaction stalled (WAIT) - slowing down and resending"

If I use the telnet command interface and do "aarch64 disassemble 0x00000000ffd5751c 16" then I get a correct disassembly, but I see a lot of "transaction stalled" errors and it takes a while for it to finish.
 
 Note that here, 0x00000000ffd5751c is an address inside the text of the U-Boot image currently running on Arm core 0. The target is just sitting at the boot prompt.
 
 The problem seems to have something to do with reading memory from the target. Reading small amounts of memory seems to work (albeit with stalls), but not larger chunks. For example, here I'm using the telnet command interface on OpenOCD and trying to display memory:
 
 > mdw 0x00000000ffd5751c  
DAP transaction stalled (WAIT) - slowing down and resending
DAP transaction stalled (WAIT) - slowing down and resending
DAP transaction stalled (WAIT) - slowing down and resending
DAP transaction stalled (WAIT) - slowing down and resending
0xffd5751c: d5033fbf 
> mdw 0x00000000ffd57520
DAP transaction stalled (WAIT) - slowing down and resending
DAP transaction stalled (WAIT) - slowing down and resending
DAP transaction stalled (WAIT) - slowing down and resending
DAP transaction stalled (WAIT) - slowing down and resending
0xffd57520: a8c17bfd 
> mdw 0x00000000ffd57524
DAP transaction stalled (WAIT) - slowing down and resending
DAP transaction stalled (WAIT) - slowing down and resending
DAP transaction stalled (WAIT) - slowing down and resending
DAP transaction stalled (WAIT) - slowing down and resending
0xffd57524: 2a2003e0 
> mdw 0x00000000ffd57528
DAP transaction stalled (WAIT) - slowing down and resending
DAP transaction stalled (WAIT) - slowing down and resending
DAP transaction stalled (WAIT) - slowing down and resending
DAP transaction stalled (WAIT) - slowing down and resending
0xffd57528: 17ffffbd 
> mdw 0x00000000ffd5752C
DAP transaction stalled (WAIT) - slowing down and resending
DAP transaction stalled (WAIT) - slowing down and resending
DAP transaction stalled (WAIT) - slowing down and resending
DAP transaction stalled (WAIT) - slowing down and resending
0xffd5752c: a9be7bfd 

Here each individual 32-bit word is displayed correctly, but it takes several stalls before it works.

Now if I try to read 5 32-bit words at once, I get this:

> mdw 0x00000000ffd5751c 5
DAP transaction stalled (WAIT) - slowing down and resending
DAP transaction stalled (WAIT) - slowing down and resending
DAP transaction stalled (WAIT) - slowing down and resending
DAP transaction stalled (WAIT) - slowing down and resending
DAP transaction stalled (WAIT) - slowing down and resending
0xffd5751c: d5033fbf 00000000 00000000 17ffffbd a9be7bfd 

Here, the second and third 32-bit words are wrong.

I found that the adi_v5_jtag.c module had some debug instrumentation that was conditionally compiled using a DEBUG_WAIT macro, and I turned it on. This is what I see for the above command:

Debug: 1201 7870 command.c:153 script_debug(): command - mdw 0x00000000ffd5751c 5
Debug: 1202 7875 adi_v5_jtag.c:159 log_dap_cmd(): LOG: DP SELECT WRITE 0x00003d00 0x00000000 OK
Debug: 1203 7875 adi_v5_jtag.c:159 log_dap_cmd(): LOG: AP    TAR WRITE 0x00410080 0x00000000 OK
Debug: 1204 7875 adi_v5_jtag.c:159 log_dap_cmd(): LOG: DP SELECT WRITE 0x00003d10 0x00000011 OK
Debug: 1205 7875 adi_v5_jtag.c:159 log_dap_cmd(): LOG: AP    BD0 WRITE 0x30c51835 0x00000000 OK
Debug: 1206 7875 adi_v5_jtag.c:159 log_dap_cmd(): REP: AP    BD3 WRITE 0x00000000 0x00000011 WAIT
Debug: 1207 7875 adi_v5_jtag.c:159 log_dap_cmd(): REP: AP    BD1 WRITE 0xd5330400 0x00000011 FAULT
Debug: 1208 7875 adi_v5_jtag.c:159 log_dap_cmd(): REP: AP    BD2  READ 0x00000000 0x00000011 FAULT
Debug: 1209 7875 adi_v5_jtag.c:159 log_dap_cmd(): REP: DP RDBUFF  READ 0x00000000 0x00000011 FAULT
Info : 1210 7875 adi_v5_jtag.c:569 jtagdp_overrun_check(): DAP transaction stalled (WAIT) - slowing down and resending
Debug: 1211 7876 adi_v5_jtag.c:159 log_dap_cmd(): REC: DP SELECT WRITE 0x00003d10 0x00000000 OK
Debug: 1212 7877 adi_v5_jtag.c:159 log_dap_cmd(): REC: AP    BD3 WRITE 0x00000000 0x00000000 OK
Debug: 1213 7877 adi_v5_jtag.c:159 log_dap_cmd(): REC: AP    BD1 WRITE 0xd5330400 0x00000011 WAIT
Debug: 1214 7877 adi_v5_jtag.c:617 jtagdp_overrun_check(): DAP transaction stalled during replay (WAIT) - resending
Debug: 1215 7879 adi_v5_jtag.c:159 log_dap_cmd(): REC: AP    BD1 WRITE 0xd5330400 0x00000000 OK
Debug: 1216 7880 adi_v5_jtag.c:159 log_dap_cmd(): REC: AP    BD2  READ 0x00000000 0x00000011 WAIT
Debug: 1217 7880 adi_v5_jtag.c:617 jtagdp_overrun_check(): DAP transaction stalled during replay (WAIT) - resending
Debug: 1218 7881 adi_v5_jtag.c:159 log_dap_cmd(): REC: AP    BD2  READ 0x00000000 0x00000000 OK
Debug: 1219 7882 adi_v5_jtag.c:159 log_dap_cmd(): REC: DP RDBUFF  READ 0x00000000 0x03047213 OK
Debug: 1220 7884 adi_v5_jtag.c:159 log_dap_cmd(): LOG: AP    BD1 WRITE 0xd51c1000 0x00000000 OK
Debug: 1221 7885 adi_v5_jtag.c:159 log_dap_cmd(): REP: AP    BD2  READ 0x00000000 0x03047213 WAIT
Debug: 1222 7885 adi_v5_jtag.c:159 log_dap_cmd(): REP: DP RDBUFF  READ 0x00000000 0x03047213 FAULT
Info : 1223 7885 adi_v5_jtag.c:569 jtagdp_overrun_check(): DAP transaction stalled (WAIT) - slowing down and resending
Debug: 1224 7886 adi_v5_jtag.c:159 log_dap_cmd(): REC: DP SELECT WRITE 0x00003d10 0x00000000 OK
Debug: 1225 7886 adi_v5_jtag.c:159 log_dap_cmd(): REC: AP    BD2  READ 0x00000000 0x00000000 OK
Debug: 1226 7887 adi_v5_jtag.c:159 log_dap_cmd(): REC: DP RDBUFF  READ 0x00000000 0x03047213 OK
Debug: 1227 7889 aarch64.c:2406 aarch64_read_cpu_memory(): Reading CPU memory address 0x00000000ffd5751c size 4 count 5
Debug: 1228 7890 adi_v5_jtag.c:159 log_dap_cmd(): LOG: AP    BD2  READ 0x00000000 0x00000000 OK
Debug: 1229 7890 adi_v5_jtag.c:159 log_dap_cmd(): LOG: DP RDBUFF  READ 0x00000000 0x03047213 OK
Debug: 1230 7893 adi_v5_jtag.c:159 log_dap_cmd(): LOG: AP    BD2 WRITE 0x03047213 0x00000000 OK
Debug: 1231 7900 adi_v5_jtag.c:159 log_dap_cmd(): LOG: AP    BD0 WRITE 0xffd5751c 0x00000000 OK
Debug: 1232 7900 adi_v5_jtag.c:159 log_dap_cmd(): REP: AP    BD3 WRITE 0x00000000 0x03047213 WAIT
Debug: 1233 7900 adi_v5_jtag.c:159 log_dap_cmd(): REP: AP    BD1 WRITE 0xd5330400 0x03047213 FAULT
Debug: 1234 7901 adi_v5_jtag.c:159 log_dap_cmd(): REP: AP    BD2  READ 0x00000000 0x03047213 FAULT
Debug: 1235 7901 adi_v5_jtag.c:159 log_dap_cmd(): REP: DP RDBUFF  READ 0x00000000 0x03047213 FAULT
Info : 1236 7901 adi_v5_jtag.c:569 jtagdp_overrun_check(): DAP transaction stalled (WAIT) - slowing down and resending
Debug: 1237 7902 adi_v5_jtag.c:159 log_dap_cmd(): REC: DP SELECT WRITE 0x00003d10 0x00000000 OK
Debug: 1238 7903 adi_v5_jtag.c:159 log_dap_cmd(): REC: AP    BD3 WRITE 0x00000000 0x00000000 OK
Debug: 1239 7904 adi_v5_jtag.c:159 log_dap_cmd(): REC: AP    BD1 WRITE 0xd5330400 0x03047213 WAIT
Debug: 1240 7904 adi_v5_jtag.c:617 jtagdp_overrun_check(): DAP transaction stalled during replay (WAIT) - resending
Debug: 1241 7906 adi_v5_jtag.c:159 log_dap_cmd(): REC: AP    BD1 WRITE 0xd5330400 0x00000000 OK
Debug: 1242 7907 adi_v5_jtag.c:159 log_dap_cmd(): REC: AP    BD2  READ 0x00000000 0x03047213 WAIT
Debug: 1243 7907 adi_v5_jtag.c:617 jtagdp_overrun_check(): DAP transaction stalled during replay (WAIT) - resending
Debug: 1244 7908 adi_v5_jtag.c:159 log_dap_cmd(): REC: AP    BD2  READ 0x00000000 0x00000000 OK
Debug: 1245 7909 adi_v5_jtag.c:159 log_dap_cmd(): REC: DP RDBUFF  READ 0x00000000 0x03047213 OK
Debug: 1246 7912 adi_v5_jtag.c:159 log_dap_cmd(): LOG: AP    BD1 WRITE 0xd5130400 0x00000000 OK
Debug: 1247 7912 adi_v5_jtag.c:159 log_dap_cmd(): REP: AP    BD2  READ 0x00000000 0x03047213 WAIT
Debug: 1248 7912 adi_v5_jtag.c:159 log_dap_cmd(): REP: DP RDBUFF  READ 0x00000000 0x03047213 FAULT
Info : 1249 7912 adi_v5_jtag.c:569 jtagdp_overrun_check(): DAP transaction stalled (WAIT) - slowing down and resending
Debug: 1250 7913 adi_v5_jtag.c:159 log_dap_cmd(): REC: DP SELECT WRITE 0x00003d10 0x00000000 OK
Debug: 1251 7914 adi_v5_jtag.c:159 log_dap_cmd(): REC: AP    BD2  READ 0x00000000 0x00000000 OK
Debug: 1252 7914 adi_v5_jtag.c:159 log_dap_cmd(): REC: DP RDBUFF  READ 0x00000000 0x23047213 OK
Debug: 1253 7917 adi_v5_jtag.c:159 log_dap_cmd(): LOG: AP    BD2 WRITE 0x03147213 0x00000000 OK
Debug: 1254 7919 adi_v5_jtag.c:159 log_dap_cmd(): LOG: AP    BD3  READ 0x00000000 0x00000000 OK
Debug: 1255 7919 adi_v5_jtag.c:159 log_dap_cmd(): LOG: DP RDBUFF  READ 0x00000000 0xffd5751c OK
Debug: 1256 7924 adi_v5_jtag.c:159 log_dap_cmd(): LOG: DP SELECT WRITE 0x00003d00 0x00000000 OK
Debug: 1257 7924 adi_v5_jtag.c:159 log_dap_cmd(): LOG: AP    TAR WRITE 0x0041008c 0x00000000 OK
Debug: 1258 7924 adi_v5_jtag.c:159 log_dap_cmd(): LOG: AP    DRW  READ 0x00000000 0xffd5751c OK
Debug: 1259 7924 adi_v5_jtag.c:159 log_dap_cmd(): PND: AP    DRW  READ 0x00000000 0xffd5751c OK
Debug: 1260 7924 adi_v5_jtag.c:159 log_dap_cmd(): FND: AP    DRW  READ 0x00000000 0xd5033fbf FAULT
Debug: 1261 7924 adi_v5_jtag.c:159 log_dap_cmd(): REP: AP    DRW  READ 0x00000000 0x00000000 WAIT
Debug: 1262 7924 adi_v5_jtag.c:159 log_dap_cmd(): REP: AP    DRW  READ 0x00000000 0xd5033fbf FAULT
Debug: 1263 7924 adi_v5_jtag.c:159 log_dap_cmd(): REP: AP    DRW  READ 0x00000000 0xd5033fbf FAULT
Debug: 1264 7924 adi_v5_jtag.c:159 log_dap_cmd(): REP: DP RDBUFF  READ 0x00000000 0xd5033fbf FAULT
Info : 1265 7924 adi_v5_jtag.c:569 jtagdp_overrun_check(): DAP transaction stalled (WAIT) - slowing down and resending
Debug: 1266 7925 adi_v5_jtag.c:159 log_dap_cmd(): REC: DP SELECT WRITE 0x00003d00 0x00000000 OK
Debug: 1267 7926 adi_v5_jtag.c:159 log_dap_cmd(): REC: AP    DRW  READ 0x00000000 0x00000000 OK
Debug: 1268 7926 adi_v5_jtag.c:159 log_dap_cmd(): REC: AP    DRW  READ 0x00000000 0xd5033fbf WAIT
Debug: 1269 7926 adi_v5_jtag.c:617 jtagdp_overrun_check(): DAP transaction stalled during replay (WAIT) - resending
Debug: 1270 7928 adi_v5_jtag.c:159 log_dap_cmd(): REC: AP    DRW  READ 0x00000000 0x00000000 OK
Debug: 1271 7929 adi_v5_jtag.c:159 log_dap_cmd(): REC: AP    DRW  READ 0x00000000 0xa8c17bfd WAIT
Debug: 1272 7929 adi_v5_jtag.c:617 jtagdp_overrun_check(): DAP transaction stalled during replay (WAIT) - resending
Debug: 1273 7930 adi_v5_jtag.c:159 log_dap_cmd(): REC: AP    DRW  READ 0x00000000 0x00000000 OK
Debug: 1274 7930 adi_v5_jtag.c:159 log_dap_cmd(): REC: DP RDBUFF  READ 0x00000000 0x17ffffbd OK
Debug: 1275 7933 adi_v5_jtag.c:159 log_dap_cmd(): LOG: AP    TAR WRITE 0x00410080 0x00000000 OK
Debug: 1276 7933 adi_v5_jtag.c:159 log_dap_cmd(): LOG: DP SELECT WRITE 0x00003d10 0x17ffffbd OK
Debug: 1277 7933 adi_v5_jtag.c:159 log_dap_cmd(): LOG: AP    BD2 WRITE 0x03047213 0x00000000 OK
Debug: 1278 7936 adi_v5_jtag.c:159 log_dap_cmd(): LOG: AP    BD3  READ 0x00000000 0x00000000 OK
Debug: 1279 7936 adi_v5_jtag.c:159 log_dap_cmd(): LOG: DP RDBUFF  READ 0x00000000 0xa9be7bfd OK
Debug: 1280 7938 adi_v5_jtag.c:159 log_dap_cmd(): LOG: AP    BD2  READ 0x00000000 0x00000000 OK
Debug: 1281 7938 adi_v5_jtag.c:159 log_dap_cmd(): LOG: DP RDBUFF  READ 0x00000000 0x03047213 OK
Debug: 1282 7945 adi_v5_jtag.c:159 log_dap_cmd(): LOG: DP SELECT WRITE 0x00003d00 0x00000000 OK
Debug: 1283 7945 adi_v5_jtag.c:159 log_dap_cmd(): LOG: AP    TAR WRITE 0x00410310 0x00000000 OK
Debug: 1284 7945 adi_v5_jtag.c:159 log_dap_cmd(): LOG: DP SELECT WRITE 0x00003d10 0x03047213 OK
Debug: 1285 7945 adi_v5_jtag.c:159 log_dap_cmd(): LOG: AP    BD1  READ 0x00000000 0x00000000 OK
Debug: 1286 7945 adi_v5_jtag.c:159 log_dap_cmd(): LOG: DP RDBUFF  READ 0x00000000 0x00000011 OK
Debug: 1287 8042 adi_v5_jtag.c:159 log_dap_cmd(): LOG: AP    BD1  READ 0x00000000 0x00000000 OK
Debug: 1288 8043 adi_v5_jtag.c:159 log_dap_cmd(): LOG: DP RDBUFF  READ 0x00000000 0x00000011 OK
Debug: 1289 8143 adi_v5_jtag.c:159 log_dap_cmd(): LOG: AP    BD1  READ 0x00000000 0x00000000 OK
Debug: 1290 8143 adi_v5_jtag.c:159 log_dap_cmd(): LOG: DP RDBUFF  READ 0x00000000 0x00000011 OK
[...]

My suspicion is that whether I'm using the AJI client library or the official USB Blaster II interface, this problem has something to do with the USB Blaster II hardware behavior. Unfortunately I don't have a standalone USB Blaster II device so it's hard to confirm this. It seems like a lot of transactions return a WAIT condition, and the code says it's slowing down and resending, but I don't actually see how it's slowing down.

Does anyone have any idea how to possibly fix or mitigate this? Inquiring minds want to know.

-Bill


---

Sent from sourceforge.net because ope...@li... is subscribed to https://sourceforge.net/p/openocd/tickets/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/openocd/admin/tickets/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.