Would ARM-USB-TINY-H work with BeagleBone Black?

Started by spbnick, September 30, 2013, 09:35:10 PM

Previous topic - Next topic

spbnick

Hello,

Would ARM-USB-TINY-H work with gdb/OpenOCD and BeagleBone Black, provided the latter has the JTAG connector (Samtec FTR-110-03-G-D-06) installed? If not, does Olimex have a JTAG debugger that would?

Please pardon me if my question doesn't make much sense, I'm completely new to JTAG and low level debugging.

Thank you.

UPDATE: Would this help http://www.tincantools.com/JTAG/BeagleBone-Black-JTAG-Adapter-Kit.html ?

LubOlimex

Hey spbnick,

Generally there is nothing impossible.

The first step to take is to prepare the board on hardware level since the BeagleBone Black lacks the proper JTAG connector. The steps to follow are the same as the ones show here: http://www.tincantools.com/wiki/Flyswatter2_BeagleBone_Black_How_To.

The second thing is the software part of the things which would require libusb drivers and the knowledge to use OpenOCD/Telnet. There are many guides on how to use OpenOCD under Linux and Windows (even under Mac) - the tincantools wiki contains some good instructions for beginners. The important part is to use the latest OpenOCD version available and the good news is there are configuration files for BeagleBone Black microcontroller (...\scripts\target\am335x.cfg) and ARM-USB-TINY-H (...\scripts\interface\olimex-arm-usb-tiny-h.cfg).

Best regards,
Lub/OLIMEX
Technical support and documentation manager at Olimex

spbnick

#2
Hi Lub,

Thank you for the detailed answer. Acquiring OpenOCD knowledge shouldn't be a problem for me, neither the JTAG connector installation. The main question was if the board and the debugger are compatible, perhaps with the aid of an adapter. Although your reply doesn't directly confirm that, it seems to imply it. So, the original question is answered for me, thank you :)

Regarding Flyswatter 2, could you please describe its difference from ARM-USB-OCD-H, in a few short words, if possible?

Thank you very much.

LubOlimex

Hey spbnick,

We haven't had Flyswatter 2, and its design is neither public nor open hardware so I can't exactly compare it to our OCD-H.

Still since the design of OpenOCD debuggers is pretty much the same probably the difference isn't that big - different elements, different box, different cables BUT same interface signals on the connector, the same functionality and close speed.

Probably the big difference is between Flyswatter 1 and 2 (and respectively between OCD and OCD-H) -  the first ones feature the slower FT2232D chip and the respective second ones the faster FT2232H.

Best regards,
Lub/OLIMEX
Technical support and documentation manager at Olimex

spbnick

Thank you, Lub.

Then as soon as I'm able to get my hands on that adapter, I will consider buying either TINY-H or OCD-H as I would prefer open hardware, if only for the purposes of education.

LubOlimex

Hey spbnick,

Just to clarify Olimex TINY-H and OCD-H are also not considered open hardware designs. Olimex open-hardware boards have the typical logo next to the product name. For instance, check this open-hardware board: https://www.olimex.com/Products/ARM/ST/STM32-H407/open-source-hardware.

Best regards,
Lub/OLIMEX
Technical support and documentation manager at Olimex

spbnick

Thanks for clarifying that. I'll need to consider the differences more closely then.

spbnick

I've now ordered the aforementioned JTAG adapter kit for BeagleBone Black from Tin Can Tools along with an ARM-USB-OCD-H, via Watterott. They should arrive in three weeks. I'll leave a comment here whether I managed to make it work and how, if I did.

spbnick

Alright, it took some time for Waterott and Tin Can Tools to deliver the adapter (it looks like they needed to manufacture some more) and then I was hesitant to solder the connector in the middle of my other work in fear of damaging the board.

Still, I've soldered the connector, connected ARM-USB-OCD-H, set up OpenOCD and it seems working! At least I'm able to halt, reset the board and dump memory and CPU registers. Here is my Frankenstein monster of an openocd.cfg so far (20 minutes into testing):

source [find interface/olimex-arm-usb-ocd-h.cfg]

adapter_khz 16000

if { [info exists CHIPNAME] } {
   set _CHIPNAME $CHIPNAME
} else {
   set _CHIPNAME am335x
}

# This chip contains an IcePick-D JTAG router.  The IcePick-C configuration is almost
# compatible, but it doesn't work.  For now, we will just embed the IcePick-D
# routines here.
proc icepick_d_tapenable {jrc port} {
        # select router
        irscan $jrc 7 -endstate IRPAUSE
        drscan $jrc 8 0x89 -endstate DRPAUSE

        # set ip control
        irscan $jrc 2 -endstate IRPAUSE
        drscan $jrc 32 [expr 0xa0002108 + ($port << 24)] -endstate DRPAUSE

        # for icepick_D
        irscan $jrc 2 -endstate IRPAUSE
        drscan $jrc 32 0xe0002008 -endstate DRPAUSE

        irscan $jrc 0x3F -endstate RUN/IDLE
        runtest 10
}

#
# M3 DAP
#
if { [info exists M3_DAP_TAPID] } {
        set _M3_DAP_TAPID $M3_DAP_TAPID
} else {
        set _M3_DAP_TAPID 0x4b6b902f
}
jtag newtap $_CHIPNAME m3_dap -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id $_M3_DAP_TAPID -disable
jtag configure $_CHIPNAME.m3_dap -event tap-enable "icepick_d_tapenable $_CHIPNAME.jrc 11"

#
# Main DAP
#
if { [info exists DAP_TAPID] } {
   set _DAP_TAPID $DAP_TAPID
} else {
   set _DAP_TAPID 0x4b6b902f
}
jtag newtap $_CHIPNAME dap -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id $_DAP_TAPID -disable
jtag configure $_CHIPNAME.dap -event tap-enable "icepick_d_tapenable $_CHIPNAME.jrc 12"

#
# ICEpick-D (JTAG route controller)
#
if { [info exists JRC_TAPID] } {
   set _JRC_TAPID $JRC_TAPID
} else {
   set _JRC_TAPID 0x0b94402f
}
jtag newtap $_CHIPNAME jrc -irlen 6 -ircapture 0x1 -irmask 0x3f -expected-id $_JRC_TAPID -ignore-version
jtag configure $_CHIPNAME.jrc -event setup "jtag tapenable $_CHIPNAME.dap"
# some TCK tycles are required to activate the DEBUG power domain
jtag configure $_CHIPNAME.jrc -event post-reset "runtest 100"

#
# Cortex A8 target
#
set _TARGETNAME $_CHIPNAME.cpu
target create $_TARGETNAME cortex_a8 -chain-position $_CHIPNAME.dap -dbgbase 0x80001000

# SRAM: 64K at 0x4030.0000; use the first 16K
$_TARGETNAME configure -work-area-phys 0x40300000 -work-area-size 0x4000

$_TARGETNAME configure -event gdb-attach {
   cortex_a dbginit
   halt
}

reset_config trst_and_srst


There was no need to add any udev rules or anything on Debian Jessie ("testing" ATM), only to be in the "dialout" group. Using OpenOCD from repositories.

I'll now continue reading the OpenOCD docs and general info about JTAG to be able to utilize it fully.

t.szczyrba

@spbnick

I've tried Your script to connect USB-OCD-H JTAG adapter with BBB and the "success" is more or less the same scope like using OpenOCD git's scripts for am335x & olimex-usb-ocd-h board...

The "scope" looks like that:
1) I am able to debug u-boot or kernel early init without a problem it seems (during single stepping gdb sometimes hangs, but Ctrl-C gdb helps without resetting board)

2) When at comes to linux' setup_arch phase the communication is full of sticky errors - I suppose the working area (internal RAM) is already unmapped from MMU in the phase, but anyway debuggin kinda works

3) In some later booting phase initiated about linux' rest_init() func the communication openocd - BBB breaks.
The breakage looks like that:
Open On-Chip Debugger 0.8.0-dev-00350-g6c74255 (2014-02-23-23:48)
Licensed under GNU GPL v2
For bug reports, read
   http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
adapter speed: 16000 kHz
Warn : target name is deprecated use: 'cortex_a'
trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain connect_deassert_srst
Info : max TCK change to: 30000 kHz
Info : clock speed 15000 kHz
Info : JTAG tap: am335x.jrc tap/device found: 0x1b94402f (mfg: 0x017, part: 0xb944, ver: 0x1)
Info : JTAG tap: am335x.dap enabled
Error: JTAG-DP STICKY ERROR
Error: MEM_AP_CSW 0x800000c2, MEM_AP_TAR 0x80001080
Polling target am335x.cpu failed, GDB will be halted. Polling again in 100ms
( .... Polling endless loop ..... ).

What is interesting: in fully booted kernel TAP is always found by openocd, but polling doesn't work at all.

The log was done from kernel 3.13, openocd current git master snapshot and your openocd config script.
The same result I had with openocd 0.7 and scripts included in openocd distribution.

I haven't spent too much time to solve the problem yet, but only tried to estimate where  is the point when the communication openocd-bbb breaks...
I suppose that during BBB kernel mmu/iommu boot initialization something happends what prevents jtag tap working the way that is expected by openocd.

So essentialy debugging early init is not a problem for me, but debugging kernel module in the working kernel is not possible anymore.

Have you met such an error?

T.

spbnick

@t.szczyrba

No, I'm a JTAG newbie and haven't got to kernel debugging yet, so I can't help you, sorry. Maybe someone from OLIMEX can comment.

arre

@ t.szczyrba

I have a similar issue. I can debug bare metal it seems (uboot and stuff), but once linux boots, things go wrong.
My trace:

testbox@testbox-VirtualBox:~/openocd/openocd-code/tcl$ sudo ../src/openocd -f interface/ftdi/tumpa.cfg -f board/ti_beaglebone.cfg
Open On-Chip Debugger 0.10.0-dev-00322-g406f4d1 (2016-06-09-09:22)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
none separate
adapter speed: 16000 kHz
Info : auto-selecting first available session transport "jtag". To override use 'transport select <transport>'.
trst_and_srst separate srst_gates_jtag trst_push_pull srst_push_pull connect_deassert_srst
Info : ftdi: if you experience problems at higher adapter clocks, try the command "ftdi_tdo_sample_edge falling"
Info : clock speed 16000 kHz
Info : JTAG tap: am335x.jrc tap/device found: 0x2b94402f (mfg: 0x017 (Texas Instruments), part: 0xb944, ver: 0x2)
Info : JTAG tap: am335x.dap enabled
Info : am335x.cpu: hardware has 6 breakpoints, 2 watchpoints
Error: Timeout during WAIT recovery
Polling target am335x.cpu failed, trying to reexamine
Error: JTAG-DP STICKY ERROR
Error: Could not initialize the APB-AP
Examination failed, GDB will be halted. Polling again in 100ms
Error: JTAG-DP STICKY ERROR
Polling target am335x.cpu failed, trying to reexamine
Error: JTAG-DP STICKY ERROR


The wait recovery start when linux starts booting.
If I then shut down openocd and restart, the error looks like this:

testbox@testbox-VirtualBox:~/openocd/openocd-code/tcl$ sudo ../src/openocd -f interface/ftdi/tumpa.cfg -f board/ti_beaglebone.cfg
Open On-Chip Debugger 0.10.0-dev-00322-g406f4d1 (2016-06-09-09:22)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
none separate
adapter speed: 16000 kHz
Info : auto-selecting first available session transport "jtag". To override use 'transport select <transport>'.
trst_and_srst separate srst_gates_jtag trst_push_pull srst_push_pull connect_deassert_srst
Info : ftdi: if you experience problems at higher adapter clocks, try the command "ftdi_tdo_sample_edge falling"
Info : clock speed 16000 kHz
Info : JTAG tap: am335x.jrc tap/device found: 0x2b94402f (mfg: 0x017 (Texas Instruments), part: 0xb944, ver: 0x2)
Info : JTAG tap: am335x.dap enabled
Error: JTAG-DP STICKY ERROR
Error: Could not initialize the APB-AP


So any luck there?

Arnout

JohnS

I expect only the oocd ML or a BB place or AM mcu place will know or have much of an answer, if anywhere.

John

janicekinard

#13
Quote from: spbnick on October 03, 2013, 05:49:41 PMThank you, Lub.

Then as soon as I'm able to get my hands on that adapter, I will consider buying either TINY-H or OCD-H as I would prefer open hardware, if only for the purposes of education.

Open hardware would be the best but there are a lot of options for education related organizations to get a software for free or receive a discount.