> 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 openocd-devel@lists.sourceforge.net 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.
