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.


Reply via email to