How to evaluate if a JTAG chain works correctly?

Community Development Platforms
1

Hello,

I would like to know how to evaluate if a JTAG chain works correctly? Which methodologies might be used to evaluate it?

My JTAG chain is:

To test it, I try to flash a baremetal binary from TI StarterWare (http://software-dl.ti.com/dsps/dsps_pub … x_FDS.html) with OpenOCD.

This binary works well when it is launch with Uboot on a loadaddr 0x80000000.

But when I flash it across OpenOCD, it fails.

I don’t understand why. I am newbie with OpenOCD. I don’t understand how Openocd works. I do not know if my problem is due to a hardware incompatibility or if I apply a bad software configuration.

Someone can help me? Thank you in advance.

Logs:

Open On-Chip Debugger 0.10.0+dev-00567-gcea40152f (2018-11-03-20:42)
Licensed under GNU GPL v2
For bug reports, read
    	http://openocd.org/doc/doxygen/bugs.html
adapter speed: 1000 kHz
trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain connect_deassert_srst
Info : auto-selecting first available session transport "jtag". To override use 'transport select <transport>'.
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : clock speed 1000 kHz
Info : JTAG tap: am335x.jrc tap/device found: 0x2b94402f (mfg: 0x017 (Texas Instruments), part: 0xb944, ver: 0x2)
Info : JTAG tap: am335x.tap enabled
Info : am335x.cpu: hardware has 6 breakpoints, 2 watchpoints
Info : am335x.cpu rev 2, partnum c08, arch f, variant 3, implementor 41
Error: MPIDR not in multiprocessor format
Info : Listening on port 3333 for gdb connections
Info : Listening on port 3334 for gdb connections
Info : accepting 'telnet' connection on tcp/4444
Info : JTAG tap: am335x.jrc tap/device found: 0x2b94402f (mfg: 0x017 (Texas Instruments), part: 0xb944, ver: 0x2)
Info : JTAG tap: am335x.tap enabled
Error: Debug regions are unpowered, an unexpected reset might have happened
Error: JTAG-DP STICKY ERROR
Warn : am335x.cpu: ran after reset and before halt ...
Info : am335x.cpu rev 2, partnum c08, arch f, variant 3, implementor 41
target halted in Thumb state due to debug-request, current mode: Supervisor
cpsr: 0x400001b3 pc: 0x0002412a
MMU: disabled, D-Cache: disabled, I-Cache: disabled
Error: data abort at 0x80000000, dfsr = 0x00001808

init
reset init
halt
load_image /srv/tftp/uartEcho_ti.bin 0x80000000 bin
resume 0x80000000

I don’t understand also, why after each reset:

  • the CPU is in Thumb state?

  • when I am in GDB interface the CPU target is am335x.m3 (cortex_m, Trust Zone, isn’t it?) and when I am in telnet interface the CPU target is am335x.cpu (cortex_a)?

2

up

3

From the am335x TRM revP manual (27.1.1 Debug Resource Manager (DRM), P5082, https://www.ti.com/lit/ug/spruh73p/spruh73p.pdf), it seems JTAG signals EMU0 and EMU1 have to be pulled high on target board to enter JTAG mode after reset.

How to do enable them with OpenOCD and ARM-USB-TINY-H?

4

UP

5

OK I have made some progresses from last post.

The TI StarterWare bootloader is need if we do not use any other bootloader as for example uboot.

Now, after reading the TI StarterWare Manual, I know how to boot the “TI StarterWare bootloader” + “TI StarterWare Application” from the uSD or from UART of my BBB.

I do not understand why in the case of uSD, I need used boot_ti.bin and “app”_ti.bin, whereas the boot.bin and “app”.bin are enough when I boot from UART ?

So now, I have a clear base to work on the JTAG chain.

For the moment, I have not weld EMU0 or EMU1 pins of my ARM20cTI20 (https://web.archive.org/web/20150926030 … ematic.pdf) to enable Wait-In-Reset mode of the CPU.

From this article https://devel.rtems.org/wiki/Debugging/ … eBoneBlack I have launched the MLO with OpenOCD.

On telnet session connected to OpenOCD:

reset halt
bp 0x402f0400 4 hw
reset run
rbp 0x402f0400
load_image ./StarterWare/binary/armv7a/gcc/am335x/beaglebone/bootloader/Release_MMCSD/boot.bin 0x402f0400 bin
resume 0x402f0400

This launches the MLO. I can see the TI StarterWare message of the MLO on my UART terminal.

I can conclude to my JTAG chain works.

But above with OpenOCD, I launch only the MLO, when I try to launch the app binary on 0x8000_0000, I obtain this error “data abort at 0x00000000, dfsr = 0x00000808”. What does it mean? I do not understand why I can not load binary to 0x8000_0000 also I can load it to 0x402f0400

From TRM:

“SRAM internal 0x402F_0400 0x402F_FFFF 32-bit (Ex/R/W)”

“EMIF0 SDRAM 0x8000_0000 0xBFFF_FFFF 1GB 8-/16-bit External Memory (Ex/R/W)”

and

“The DDR2/3/mDDR memory controller will remain fully functional during emulation halts to allow emulation access to external memory.”

I do not found any restriction in the TRM documentation about the use of EMIF0 SDRAM. Why does it not works on the BBB DDR3 ? It do not seem any differences between these 2 kinds of RAMs, they are both in Ex/R/W.

Another point, launching the MLO with the telnet session is OK, but it is not the case with a GDB session connected to OpenOCD, I don’t understand the difference for the moment, I use the same OpenOCD commands (with “monitor” key before in GDB) but it give a different results:

"no flash patch comparator unit available for hardware breakpoint

can’t add breakpoint: resource not available

Failure setting breakpoint, the same address(IVA) is already used"