Very strange!

Finding MEM-AP is the generic ARM ADI stuff and is used mainly for all ARM 
Cortex cores.
If that part of OpenOCD were so wrong to screw up some bits of MEM-AP 
read/write then no Cortex core could be debugged!

Please start over with **clean** OpenOCD and libjaylink.

Make your best to use the same conditions for both OpenOCD and jlink.exe (e.g. 
JTAG clock 100kHz on OpenOCD versus 4MHz on jlink.exe)

Try the low level OpenOCD commands to investigate DP and AP registers manually:
    $dap_name dpreg reg [value]
    $dap_name apreg ap_num reg [value]
 
 Also worth to try
    $dap_name memaccess [value]

and pay attention to proper setting of
    $dap_name apcsw [value [mask]]
    
 - OpenOCD uses CWS default suitable for ARM cores, your SoC may need different 
settings


---

**[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:** Thu Dec 12, 2024 06:51 AM 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