HI, Sorry, correct the information, I wrote the above test wrong, APB-AP read is correct, because I put LOG_DEBUG in front of dap_run, resulting in not correct reading. However, the error reading xtensa debug register bit31 still exists, as before.
I didn't add the tests to the mem_ap_init() function myself, openocd executes the mem_ap_init() function itself during startup, so I added some tests here. The calling relationship is: src/target/xtensa/xtensa_debug_module.c/xtensa_dm_examine()----->mem_ap_init(dm->debug_ap); For the XOCD tool, I used the "ap_sel" option, and in OPENOCD, I used the -ap-num option.When using XOCD, there are no WAIT errors, and APB_AP can read and write normally. "ap-sel (APB only, SoC-400 only). Specifies the DAP access port (a MEM-AP, e.g. APBAP, AHB-AP, AXI-AP) to which XDM is attached. APB-AP is the access port “1”, and is the only AP verified to work with XOCD."----------- see the Xtensa Debug Guide, section 7.7.4. Finally, I read the xtensa-kc705-ext-dap.cfg you suggested. I compared my cfg files, but I didn't seem to find the difference between them. The version I am using is openocd v0.12.0, is it related to the version or openocd configure? BTY,fromXtensa Debug Guide, section 2.1.1,The bit31 of the address should be equal to 1 when accessed externally, but I see that the dbg_base of xtensa-kc705-ext-dap.cfg =0x10000, bit31=0.In my cfg, my addresses 0x108000 and 0x80108000 I have tested and both have the above problem. Attached is the openocd configuration file and log. In addition, I also provided the xocd configuration file and log. I still don't understand why xocd works and openocd's bit31 is always wrong. Attachments: - [=openocd_log.txt](https://sourceforge.net/p/openocd/tickets/_discuss/thread/ce8bb4132e/4951/attachment/%3Dopenocd_log.txt) (102.4 kB; text/plain) - [openocd.cfg](https://sourceforge.net/p/openocd/tickets/_discuss/thread/ce8bb4132e/4951/attachment/openocd.cfg) (1.2 kB; application/octet-stream) - [openocd.png](https://sourceforge.net/p/openocd/tickets/_discuss/thread/ce8bb4132e/4951/attachment/openocd.png) (306.0 kB; image/png) - [xocd.xml](https://sourceforge.net/p/openocd/tickets/_discuss/thread/ce8bb4132e/4951/attachment/xocd.xml) (2.3 kB; text/xml) - [xocd_log.txt](https://sourceforge.net/p/openocd/tickets/_discuss/thread/ce8bb4132e/4951/attachment/xocd_log.txt) (2.9 MB; text/plain) --- **[tickets:#445] openocd with xtensa core problem(about debug data reg)** **Status:** new **Milestone:** 0.11.0 **Created:** Fri Dec 06, 2024 05:30 AM UTC by vitocichen **Last Updated:** Mon Dec 09, 2024 03:28 PM UTC **Owner:** nobody HI, I am debugging xtensa core using openocd tool. The connection relationship of my system is as follows: << jlink--->coresight dap--->APB_AP(ap_num=0)----->xtensa core0/1/2 >> The gdb tool I use is xt-gdb, but I find that the values of my pc registers, a0-a15,ar0-ar15, etc. are strange during reuse, their highest bit bit31 is always 1, bit30 is always 0, but this value is wrong. I finally found that openocd had a problem when reading and writing the DDR (debug data reg) register, in order to better explain the phenomenon. I've added a test function in openocd source, in the SRC/target/xtensa/xtensa. C I added a test function, the code is as follows: /************************************************************************************/ void ddr_test(struct target target) { struct xtensa xtensa = target_to_xtensa(target); uint8_t a3_buf[4]={0}; LOG_DEBUG("***ddr test******"); xtensa_queue_dbg_reg_write(xtensa, XDMREG_DDR, 0x12345678); xtensa_queue_dbg_reg_read(xtensa, XDMREG_DDR,a3_buf); LOG_DEBUG("A3[0]=%X",a3_buf[0]); LOG_DEBUG("A3[1]=%X",a3_buf[1]); LOG_DEBUG("A3[2]=%X",a3_buf[2]); LOG_DEBUG("A3[3]=%X",a3_buf[3]); xtensa_queue_dbg_reg_write(xtensa, XDMREG_DDR, 0); xtensa_queue_dbg_reg_read(xtensa, XDMREG_DDR,a3_buf); LOG_DEBUG("A3[0]=%X",a3_buf[0]); LOG_DEBUG("A3[1]=%X",a3_buf[1]); LOG_DEBUG("A3[2]=%X",a3_buf[2]); LOG_DEBUG("A3[3]=%X",a3_buf[3]); xtensa_queue_dbg_reg_write(xtensa, XDMREG_DDR, 0x5a5a8080); xtensa_queue_dbg_reg_read(xtensa, XDMREG_DDR,a3_buf); LOG_DEBUG("A3[0]=%X",a3_buf[0]); LOG_DEBUG("A3[1]=%X",a3_buf[1]); LOG_DEBUG("A3[2]=%X",a3_buf[2]); LOG_DEBUG("A3[3]=%X",a3_buf[3]); } /************************************************************************************/ I put the above test function in a lot of event locations like xtensa_halt/xtensa_resume/xtensa_prepare_resume and other places. Then I found that the DDR test always fails, bit31 is always 1, bit30 is always 0, such as the above result: 0x12345678----->0x82345678 0x0---->0x8000000 0x5a5a8080--->9a5a8080 I tried to modify the speed of jlink can not improve this, below is my cfg file, can you help me find out the reason? Here is my cfg file: /************************************xxxx.cfg************************************************/ adapter driver jlink adapter serial 601012352 transport select jtag gdb_port 20005 bindto 0.0.0.0 source [find mem_helper.tcl] set _CHIPNAME plmp set _CPU0NAME smcu set _CPU1NAME pmcu set _TARGETNAME_0 $_CHIPNAME.$_CPU0NAME set _TARGETNAME_1 $_CHIPNAME.$_CPU1NAME set _CPUTAPID 0x6ba00477 source [find target/swj-dp.tcl] swj_newdap $_CHIPNAME tap -irlen 4 -expected-id $_CPUTAPID dap create $_CHIPNAME.dap -chain-position $_CHIPNAME.tap target create $_CHIPNAME.axi mem_ap -dap $_CHIPNAME.dap -ap-num 1 target create $_TARGETNAME_0 xtensa -dap $_CHIPNAME.dap -ap-num 0 -coreid 1 -dbgbase 0x0108000 source [find target/xtensa-core-lx7.cfg] target create $_TARGETNAME_1 xtensa -dap $_CHIPNAME.dap -ap-num 0 -coreid 2 -dbgbase 0x010c000 source [find target/xtensa-core-lx7.cfg] --- 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.