HI,
<Info : 103551 58863 adi_v5_jtag.c:558 jtagdp_overrun_check(): DAP transaction
stalled (WAIT) - slowing down and resending>
I looked at this Log is generated after I xt-gdb sent the <load> command, this
time is downloading the program. But the fact that the DDR and DSR registers
are abnormal has already been generated before this.
I tried to slow down jlink using the <adper speed> command, but it didn't
seem to work, so I suspect it wasn't the speed
In fact, I used other ocd tools, such as <xt-ocd> which is ocd software
made by xtensa specifically for their chips. I use <xt-ocd+xt-gdb> is able to
debug normally, no problem.
However, because our SOC is connected to many cores through the APB_AP of
DAP, including xtensa, arm and risc-v architectures, we want to use <openocd>
for debugging, and <xt-ocd> can only support xtensa core.
So I can succeed with xt-ocd, which means my jlink and DAP systems are
fine, but I don't understand why using openocd keeps causing DDR and DSR
register exceptions.
By the way, I can use <openocd> to connect to <xt-gdb> normally, and also
<load> and <run> commands, but because of the abnormal read and write of DDR
and DSR registers, all the kernel registers a0-a15,pc,sp, etc., and bit31 are 1
after my program is run, I can't perform breakpoints and other functions.
Based on the above features, I suspect that my openocd.cfg file is not
configured correctly, or something else? Before this, has anyone used
openocd+xtensa+DAP to debug successfully?
---
**[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:** Fri Dec 06, 2024 03:32 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.
