Activity for vitocichen
-
vitocichen posted a comment on ticket #445
HI, Are there any new findings on this question? Has anyone had this problem before?
-
HI， A piece of good news： I changed a line of code and now bit31 works! ! in src/target/adi_v5_jtag.c/jtag_dp_run(), I remove "retval2 = jtagdp_overrun_check(dap);" modify to "retval2 = ERROR_OK;" I don't know how it works, but here's how I discovered it: You mentioned above that my xt-ocd and JLINKEXE are both 4000KHZ, and then openocd is the default, which is 100KHZ. But when I increase the speed of openocd, say 1000 2000 3000 4000KHZ.Keep reminding me of an infinite message ** ”DAP transaction...
-
HI， Add an important test!!!! In previous tests, I always used xt-ocd or openocd, which made it impossible to tell whether it was a tool problem or an RTL problem. I now use the JLinkExe tool directly and do not use any ocd tools to connect. As you can see from the image and Log,JLINKEXE can correctly read APB_ID or AXI_ID。 （xt-ocd can also read correctly） But openocd's read is always wrong, bit31=1. Through this TEST, it can be proved that there is no problem with my JLINK device, and there is no...
-
HI, I've changed my cmd to the same as yours,Like this: "openocd -s tcl -d3 -f tcl/interface/jlink.cfg -c "set CPUTAPID 0x3ba00477" -f tcl/board/xtensa-kc705-ext-dap.cfg -f xtcfgfiles/xtensa-core-DCD330HiFi.cfg" "openocd -s tcl -d3 -f tcl/interface/jlink.cfg -c "set CPUTAPID 0x6ba00477" -f tcl/board/my.cfg -f xtcfgfiles/xtensa-core-lx7.cfg" "command - xtensa.cpu configure -event reset-assert-post softresethalt" Also in our Log, reference "319 2 command.c:153 scriptdebug(): command - plmp.smcu configure...
-
this is my new_log for the lastest openocd.
-
-
HI， I looked at your test log, so I also adjusted the test environment. First of all, in order to keep the environment consistent with you, I used only one core; Second, your target creat did not specify ap_num, and I modified it to be consistent with you. LIKE： “target create $_TARGETNAME_0 xtensa -dap $_CHIPNAME.dap -dbgbase 0x80108000” Finally, I updated openocd to the latest version But the bit31 problem remains, and there are two things in my Log that are different from yours: Mine: <debug:...
-
HI： Debug: 594 79 arm_adi_v5.c:826 mem_ap_init(): MEM_AP Packed Transfers: disabled. That's another difference
-
HI， I compared your log with mine, and I found something wrong. First of all, in order to keep the environment consistent with you, I used only one core; Second, your target creat did not specify ap_num, and I modified it to be consistent with you. LIKE： “target create $_TARGETNAME_0 xtensa -dap $_CHIPNAME.dap -dbgbase 0x0108000” Finally, I deleted a lot of the printout I added myself to be consistent with yours. It turns out I have an extra "xtensa_chip_jim_configure/ jim_newtap_cmd" in my log....
-
HI, Add a test that might help you.I wanted to read APB_AP's registers, such as IDCODE, so I added function reads in mem_ap_init(). But I found that my first read was always wrong and only the second start was correct. ALWAYS BIT31=1,BIT30=0. I wonder if this finding has anything to do with XDM's register reading exception? So far, we have found a total of XDM and APB_AP register reading problems, are related to bit31 and bit30. While the APB_AP register reads normally the second time（use dap_queue_ap_read()...
-
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);...
-
HI, Add some new findings： I guessed that the above phenomenon might have something to do with DAP's APB-AP, so I looked at the mem_ap_init function and added some tests.(Refer to the attached picture) Then I found that all the APB-AP read values were 0, which was not normal. But when I use the xt-ocd tool, APB-AP is able to read the correct value. Like this: " 0: Powering up the DAP Successful. 0: dap600_sel: 0x0, dap_ap_sel: 0x0 0: AP_CSW (0x0) < ... 0: Old bank/sel: -1/-1. New bank/sel: 0/0 0:...
-
HI, Add some new findings： "Debug: 1090 283 xtensa.c:2068 xtensa_poll(): [plmp.smcu] PWRSTAT: read 0x10011111, clear 0x10010000, reread 0x80001111" "Debug: 1199 346 xtensa.c:2068 xtensa_poll(): [plmp.pmcu] PWRSTAT: read 0x90011111, clear 0x10010000, reread 0x80001111" It seems that all APB writes will be problematic, as in the PWRSTAT register above, the default read =0x10011111 is correct.But when written, bit31 becomes 1 again.
-
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.</load></info> 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 previous file is not complete, please use this latest one
-
Hi， File is -d log information, I added some ddr_test in the code, log can also see. I keep reading and writing XT_SR_DDR incorrectly 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_exec_ins(xtensa,XT_INS_WSR(xtensa, XT_SR_DDR, XT_REG_A3)); // xtensa_queue_dbg_reg_read(xtensa, XDMREG_DDR,a3_buf); // LOG_DEBUG("A3[0]=%X",a3_buf[0]); // LOG_DEBUG("A3[3]=%X",a3_buf[3]); xtensa_queue_dbg_reg_write(xtensa,...
-
openocd with xtensa core problem(about debug data reg)
-
openocd with xtensa core problem(about debug data reg)
1
