JTAG

Hello

I received the BeagleBoard and am very happy hacking on it. thanks!

I want to start playing with the JTAG interface on the BeagleBoard
using openocd.
The First step is to get some hello world out of the BeagleBoard. something like
being able to scan the chain.

I have a few questions.Tthe first on is related to EMU1 and EMU0. I
understand those lines are related to
enabling the JTAG interface. What should theire state be to enable JTAG?

On my board the optional P3 is missing so I can not pull down EMU0
using a jumper. Did somebody test
the JTAG interface?

Booth EMU0 and EMU1 are routed towards the JTAG interface (als pin 13 and 14)
and that really brings me to my next question. The pin numbers on
table 20 page 90 are missing. but on page
the pin-out looks like this

JTAG_nTRST 2 - - 1 JTAG_TMS
GND 4 - - 3 JTAG_TDI
KEY (empty) 6 X - 5 V ref? 1.8 v
GND 8 - - 7 JTAG_TDO
GND 10 - - 9 JTAG_RTCK
GND 12 - - 11 JTAG_TCK
JTAG_EMU1 14 - - 13 JTAG_EMU0

are those number the number of the pins on the header or am I making
the wrong assumptions?

The strange thing is that this does not look like any jtag connector
stated here http://www.amontec.com/pub/amt_ann003.pdf
The Flyswatter I planned to use has this pin layout. (This one follows
the standard 14 pins layout)
http://www.tincantools.com/assets/JTAG_pin_assignments.pdf

-/---VREF 1 - - 2 GND -----------\
  > JTAG_nTRST 3 - - 4 GND -----------|
  > JTAG_TDI 5 - - 6 GND -----------|
  > JTAG_TMS 7 - - 8 GND -----------|
  > JTAG_TCK 9 - - 10 GND -----------|

  > JTAG_TDO 11 - - 12 JTAG_SRST_N |
  \-- VREF 13 - - 14 GND------------/-

if the BeaglBoard 14 pins header would follow the "standrard" 14
inteface pin 14 (emu1) would be pulled to ground
and emu0 towards 1.8 vref.
Was it safe to put the Flyswatter on the BeagleBoard?

Greetings

Hello,

Thanks to Janson we now have a little more information. First of all
we know that the JTAG hardware really works as
the JTAG has been tested using Lauterbach (unknown model), Spectrum
Digital XDS510USB+, and TI XDS560 emulation pods.

We also know that the pin numbers are correct and do not match the
FlySwatter "standard ARM 14-pins". I tried connecting the
FlySwatter directly to the target and that indeed did not work. The
good news is that is did not fry my BeagleBoard either.

Next I tried to connect the FlySwatter using a Lauterbach
adapter[2] to convert from ARM 14 pins to 14-pins "TI". This gave us
a hello world

Open On-Chip Debugger 1.0 (2008-07-04-09:01) svn:738M
$URL: http://svn.berlios.de/svnroot/repos/openocd/trunk/src/openocd.c $
Info: options.c:50 configuration_output_handler(): jtag_speed: 1, 1
Info: jtag.c:1389 jtag_examine_chain(): JTAG device found:
0x0b7ae02f (Manufacturer: 0x017, Part: 0xb7ae, Version: 0x0)
Error: jtag.c:1399 jtag_examine_chain(): number of discovered
devices in JTAG chain (1) doesn't match configuration (0)
Error: jtag.c:1400 jtag_examine_chain(): check the config file and
ensure proper JTAG communication (connections, speed, ...)
Error: jtag.c:1556 jtag_init_inner(): trying to validate configured
JTAG chain anyway...
Error: jtag.c:1456 jtag_validate_chain(): Error validating JTAG scan
chain, IR mismatch, scan returned 0x01
..
...

I also just tried with the JTagkey and that also gives me some results
(but different)

Open On-Chip Debugger 1.0 (2008-07-04-09:01) svn:738M
$URL: http://svn.berlios.de/svnroot/repos/openocd/trunk/src/openocd.c $
Info: jtag.c:1389 jtag_examine_chain(): JTAG device found:
0x0b7ae02f (Manufacturer: 0x017, Part: 0xb7ae, Version: 0x0)
Error: jtag.c:1456 jtag_validate_chain(): Error validating JTAG scan
chain, IR mismatch, scan returned 0x41
Error: jtag.c:1456 jtag_validate_chain(): Error validating JTAG scan
chain, IR mismatch, scan returned 0x41
..
...

We now know that neither of them will work without as special adapter.
Note that this test was performed using an almost empty openocd.cfg
I will try to get some more information out of the Beagle but wanted
to share the "progress"

Greetings

[1] http://www.flickr.com/photos/51025379@N00/2647457198/ the
FlySwatter serving the Beagle
[2] http://www.flickr.com/photos/51025379@N00/2647457188/ The adapter

Kees Jongenburger wrote:

Hello,

Thanks to Janson we now have a little more information. First of all
we know that the JTAG hardware really works as
the JTAG has been tested using Lauterbach (unknown model), Spectrum
Digital XDS510USB+, and TI XDS560 emulation pods.

We also know that the pin numbers are correct and do not match the
FlySwatter "standard ARM 14-pins". I tried connecting the
FlySwatter directly to the target and that indeed did not work. The
good news is that is did not fry my BeagleBoard either.

Next I tried to connect the FlySwatter using a Lauterbach
adapter[2] to convert from ARM 14 pins to 14-pins "TI". This gave us
a hello world

Open On-Chip Debugger 1.0 (2008-07-04-09:01) svn:738M
$URL: http://svn.berlios.de/svnroot/repos/openocd/trunk/src/openocd.c $
Info: options.c:50 configuration_output_handler(): jtag_speed: 1, 1
Info: jtag.c:1389 jtag_examine_chain(): JTAG device found:
0x0b7ae02f (Manufacturer: 0x017, Part: 0xb7ae, Version: 0x0)
Error: jtag.c:1399 jtag_examine_chain(): number of discovered
devices in JTAG chain (1) doesn't match configuration (0)
Error: jtag.c:1400 jtag_examine_chain(): check the config file and
ensure proper JTAG communication (connections, speed, ...)
Error: jtag.c:1556 jtag_init_inner(): trying to validate configured
JTAG chain anyway...
Error: jtag.c:1456 jtag_validate_chain(): Error validating JTAG scan
chain, IR mismatch, scan returned 0x01
..
...

I also just tried with the JTagkey and that also gives me some results
(but different)

Open On-Chip Debugger 1.0 (2008-07-04-09:01) svn:738M
$URL: http://svn.berlios.de/svnroot/repos/openocd/trunk/src/openocd.c $
Info: jtag.c:1389 jtag_examine_chain(): JTAG device found:
0x0b7ae02f (Manufacturer: 0x017, Part: 0xb7ae, Version: 0x0)
Error: jtag.c:1456 jtag_validate_chain(): Error validating JTAG scan
chain, IR mismatch, scan returned 0x41
Error: jtag.c:1456 jtag_validate_chain(): Error validating JTAG scan
chain, IR mismatch, scan returned 0x41
..
...

We now know that neither of them will work without as special adapter.
Note that this test was performed using an almost empty openocd.cfg
I will try to get some more information out of the Beagle but wanted
to share the "progress"

Greetings

[1] http://www.flickr.com/photos/51025379@N00/2647457198/ the
FlySwatter serving the Beagle
[2] http://www.flickr.com/photos/51025379@N00/2647457188/ The adapter

Great!

I added something like this from IRC logs some minutes ago to

http://code.google.com/p/beagleboard/issues/detail?id=13

Dirk

Hello time for an update on the open-source JTAG progress.

Jason was kind enough to provide preliminary documentation about
connecting a debugger to the omap35xx SoC. The most useful
information to me was information about what to expect from
hardware depending on the EMU0 and EMU1 settings. Now somewhere
something is wrong. It can be the documentation, the hardware or
(and most probably) my understanding of the situation. From reading
the doc I understand that if I pull down booth EMU0 and EMU1 the
behaviour should be the same as described here on the DaVinci Olimex
dongle page[0]. There should be 3 element in the scan chain and we
should be able to do some real coding right away. However when
booth pins a pulled down, it looks like only a single tap is enabled
and the processor is in reset mode.

The document then explains how use the default TAP to add more element
to the scan chain. That is, if you don't pull down the EMU0 and EMU1.
and this isapparently what other debugger are doing. This also looks
very similar to what happens on the DaVinci BDI2000 debugger
page[1] and also BDI default configuration for the omap35xx.

SCANINIT t1:w1000:t0:w1000: ;toggle TRST,
SCANINIT ch10:w1000: ;clock TCK with TMS high and wait
SCANINIT i6=07:d8=89:i6=02: ;connect and select router
SCANINIT d32=81000080: ;IP control: KeepPowered
SCANINIT d32=a3002048: ;TAP3: DebugConnect, ForcePower, ForceActive
SCANINIT d32=81000081: ;IP control: KeepPowered, SysReset
SCANINIT d32=a3002148: ;enable TAP3
SCANINIT cl10:i10=ffff ;clock 10 times in RTI, scan bypass

In openocd this would translate to the following sequence.

irscan 0 7
drscan 0 8 0X89
irscan 0 2
drscan 0 32 0xA3002108
......
irscan 0 0x3F
sleep 10
jtag_device 4 0x1 0x0 0xe

This week-end I played with the concept of running commands on startup
of openocd but the later doesn't like it if you try to add elements to the
chain and is not playing nice(yet). For openocd adding tap's at startup
apparently is a new "feature" as there is no support for it[2].

Booth Nishanth and I created self made adapters[4] and [5] for the
FlySwatter and it "works"

The best news is that the tincantools guys created and adapters that
allows to connect a serial , JTAG and nRESET (system reset) to the
BeagleBoard (no null modem cable needed)[6]. When I see the
amount of mails related to getting the right serial adapter I guess that
just for that it makes sense to have such hardware ready made. I was
lucky enough to be able to test the adapter[7].

greetings

[0] http://wiki.davincidsp.com/index.php?title=Debugging_on_DaVinci_using_Olimex_dongle
[1] http://wiki.davincidsp.com/index.php?title=Debugging_on_DaVinci_using_BDI2000
[2] https://lists.berlios.de/pipermail/openocd-development/2008-August/003073.html
[4] http://nishanthmenon.blogspot.com/2008/08/low-cost-jtag-for-beagle.html
[5] http://www.flickr.com/photos/51025379@N00/2822556950/in/photostream/
[6] http://www.tincantools.com/product.php?productid=16144&cat=0&page=1&featured
[7] http://www.flickr.com/photos/51025379@N00/2821970903/in/photostream/

Yes, the JTAG has been tested and yes it works fine. The Flyswatter has the ability to set the EMU0 and EMU1 as needed on the Beagle adapter board. The EMU0/1 pins were removed from the Rev B boards as they are not needed from a OMAP3 JTAG standpoint to activate the JTAG. But, as I said, they are on the Flyswatter adapter so there is support to do whatever needs to be done.

You can refer to the Flyswatter adapter schematics or the schematics in the Reference Manual for the assignments of the JTAG pins and signals. The BeagleBoard has the standard TI 14 pin configuration. The Flyswatter adapter board makes the adjustments of the pin outs such that they match. The adapter board is needed to make the Flyswatter work with the Beagle Board.

Gerald

I have a full setup I can get you with the JTAG adapters and the Serial adapters form TinCan. I can bring them in tomorrow if you can work with them.

Gerald

Can you show me how i can use Beagle Board JTAG with Flyswatter +
OpenOCD.

Thanks,
Tinnt

Hi Kees,

About a months ago I spend at least two full days to figue out how to
connect TinCan & OpenOCD to beagle.
I used wires to connect the jtag signal (rather easy, only 7-8 wires)

BUT - OpenOCD needs to be rewritten to support omap3. And as I
understand, the documentation from TI regarding the scan chain are
confidential.
Omap3 DOES NOT have 3 seperate jtag devices inside, it has a single 6
tap IR front end, that somehow allows access to the 4 devices in it
Here is how the configuration looks like when using XDS510 and code
composer:
http://www.magniel.com/yuli/omap3_jtag.jpg

I think the only way to make it work, is to get this confidential
document from TI, and spend few days modifying OpenOCD.
I do not believe there is any other way around it.

There is also the issue of RTCK, which I believe, have to be
connected, and I'm not sure exactly how it is implemented with TinCan
today.

But, anyway, good luck!
Yuli

yuli wrote:

Hi Kees,

About a months ago I spend at least two full days to figue out how to
connect TinCan & OpenOCD to beagle.
I used wires to connect the jtag signal (rather easy, only 7-8 wires)

BUT - OpenOCD needs to be rewritten to support omap3. And as I
understand, the documentation from TI regarding the scan chain are
confidential.

IMHO this it not confidential. You can ask Jason and you will get a
doc. Some developers have it. They asked. As I heard Jason has a
document which is not in an "official TI" format to make it possible
to release it officially. So you have to ask for it.

Omap3 DOES NOT have 3 seperate jtag devices inside, it has a single 6
tap IR front end, that somehow allows access to the 4 devices in it
Here is how the configuration looks like when using XDS510 and code
composer:
http://www.magniel.com/yuli/omap3_jtag.jpg

I think the only way to make it work, is to get this confidential
document from TI, and spend few days modifying OpenOCD.

See IRC log from today, two developers are working (in their private
time) on it.

Hi all,

    Can I use a standard ARM JTAG (14 pinouts or 20 pinouts) + a
converter from ARM-14 or ARM-20 to use with TI JTAG of Beagle Board?
    Please help me to confirm and show all steps how i can do it.

Thanks,
Tin Nguyen.

yuli wrote:

Hi Kees,

About a months ago I spend at least two full days to figue out how to
connect TinCan & OpenOCD to beagle.
I used wires to connect the jtag signal (rather easy, only 7-8 wires)

BUT - OpenOCD needs to be rewritten to support omap3. And as I
understand, the documentation from TI regarding the scan chain are
confidential.

IMHO this it not confidential. You can ask Jason and you will get a
doc. Some developers have it. They asked. As I heard Jason has a
document which is not in an "official TI" format to make it possible
to release it officially. So you have to ask for it.

Information on putting the ARM into the scan chain is not
confidential. Documentation is not in ready-to-be-published shape, so
it would be helpful to have others summarize the information in the
meantime. I believe the most critical information has already been
summarized here.

Hi Yuli

Hi Yuli

There is also the issue of RTCK, which I believe, have to be
connected, and I'm not sure exactly how it is implemented with TinCan
today.

Do we have an official status on that ?

Do we NEED RTCK to get it working?

We shouldn't _need_ RTCK unless the JTAG clock domain is tied to the system clock domain and the system clock is changing. If it is a (relatively) fixed frequency or independent domain, then we just need to pick a reasonable JTAG clock speed.

My previous experiments have shown that we can talk to the JRC TAP without RTCK.

Hello time for an update on the open-source JTAG progress.

The focus lately(as ever) has been on enabling access to the DAP. The
OpenOCD people did some nice work that should have allowed us to simply
enable the DAP but this has clearly not yet payed of.

As developer I was not able the to determine who was to blame(was it a
problem between keyboard and chair,a problem in OpenOCD or a problem
of interpretation of the "document").

I got myself a logic analyzer[1] and looked at what happend between openocd
and the beagle. It became apparent that the OpenOCD IR and DR command
where not enough to exactly perform the transitions requested. One problem
being that I was not able to select a certain end state for the IR and DR scan.
The other was that state moves in OpenOCD where implemented in such a way
that they take exactly 7 steps[2] (clearly not what the TI guys must
be thinking
of when they say "shortest-path" as mentioned in "the document"[3] )

On more thing I learned what that apparently when the state machine passes
Test Logic Reset things then to go wrong.( This is kind of annoying as
it's the easy
way of getting IDCODES from items in the scan chain)

I then focused on getting the right sequence into the beagle using urjtag[4].
This required adding support for the flyswatter in urjtag. By the time this was
added I discovered that Flyswatter support was already in the SVN version of
urjtag. This was a nice waste of time :stuck_out_tongue:

After my initial ICEPICK mail on urjtag the list[5] I rewrote the
sequence to use the
SVF format. I think it now matches the sequence described on the
elinux wiki[3] "bit for bit"
However I think that the scan chain is still only contains the
ICEPICK(ir scan is still 6 bits)

So what next?
I believe we are very close to "stage 2" but honestly don't know what
else I can try.
I think I need a second opinion to determine if the sequence performed is right.
this can be done in many ways.
-You can download the scripts[6] to compare the command I did with the wiki[3].
-I created a log of the data being sent between the beagle and the
flyswatter and created
a visualizer for the data. Can you compare the sequence shown with the
wiki[3] and find errors?
-You can try to implement the BDI sequence and see if that works better
-You can find me some documentation about this ICEPICK. why can't we
get decent docs about this???
-You can send me a analyzer trace of a working setup (or better hardware :p)

Greetings

[1] http://www.flickr.com/photos/51025379@N00/3241380842/
[2] https://lists.berlios.de/pipermail/openocd-development/2009-February/004625.html
[3] http://elinux.org/OMAP3530_ICEPICK
[4] http://urjtag.org/
[5] http://sourceforge.net/mailarchive/forum.php?thread_name=e5e16330902091450t2138127dj40bd7e69388f72c0%40mail.gmail.com&forum_name=urjtag-development
[6] http://box.mmapps.net/urjtag_beagle.zip
[7] http://box.mmapps.net/analyzer.zip
[8]http://elinux.org/BeagleBoardJTAG#BDI_config

Hello time for an update on the open-source JTAG progress.

The focus lately(as ever) has been on enabling access to the DAP. The
OpenOCD people did some nice work that should have allowed us to simply
enable the DAP but this has clearly not yet payed of.

As developer I was not able the to determine who was to blame(was it a
problem between keyboard and chair,a problem in OpenOCD or a problem
of interpretation of the "document").

I got myself a logic analyzer[1] and looked at what happend between openocd
and the beagle. It became apparent that the OpenOCD IR and DR command
where not enough to exactly perform the transitions requested. One problem
being that I was not able to select a certain end state for the IR and DR scan.
The other was that state moves in OpenOCD where implemented in such a way
that they take exactly 7 steps[2] (clearly not what the TI guys must
be thinking
of when they say "shortest-path" as mentioned in "the document"[3] )

On more thing I learned what that apparently when the state machine passes
Test Logic Reset things then to go wrong.( This is kind of annoying as
it's the easy
way of getting IDCODES from items in the scan chain)

Can you write up the problems you encountered with OpenOCD? There are a few people on the OpenOCD development list who are actively working on fixing up the JTAG layer. If we could get some data as to what isn't working and what is needed, we can start working on the necessary improvements.

Hello Rick,

Can you write up the problems you encountered with OpenOCD? There are a few
people on the OpenOCD development list who are actively working on fixing up
the JTAG layer. If we could get some data as to what isn't working and what
is needed, we can start working on the necessary improvements.

There are currently problems that possibly prevent the OpenOCD from adding
the DAP.

1) When performing ir/dr scans the default end state is Run Test Idle.
This does not match
what the ICEPICK wants. I don't know it this is a problem or not

2) The tap_move that allows moving between "stable" tap states does
not follow "shortest pad"
but always takes 7 steps, possibly passing via test logic reset. I
mailed about it
https://lists.berlios.de/pipermail/openocd-development/2009-February/004625.html

3) There is no support for generating clock pulses in the IDLE state.
but this is required

4) I had some trouble implementing the sequence because of the problems
mentioned above. Those changes where not trivial for me to implement
so I decided to focus
on getting the sequence done by using urjtag. My plan is still to use
OpenOCD for "stage 2"
because of its good GDB support. But then at least I know what needs
fixing in OpenOCD.

Greetings

Hello Rick,

Can you write up the problems you encountered with OpenOCD? There are a few
people on the OpenOCD development list who are actively working on fixing up
the JTAG layer. If we could get some data as to what isn't working and what
is needed, we can start working on the necessary improvements.

There are currently problems that possibly prevent the OpenOCD from adding
the DAP.

1) When performing ir/dr scans the default end state is Run Test Idle.
This does not match
what the ICEPICK wants. I don't know it this is a problem or not

I know that the JTAG internals in OpenOCD can support this. It may be as simple as allowing an extra argument to the irscan and drscan commands in the TCL layer.

2) The tap_move that allows moving between "stable" tap states does
not follow "shortest pad"
but always takes 7 steps, possibly passing via test logic reset. I
mailed about it
https://lists.berlios.de/pipermail/openocd-development/2009-February/004625.html

Yes. I remember seeing the query about this, but I didn't realize it was a limiting issue for ICEPICK.

3) There is no support for generating clock pulses in the IDLE state.
but this is required

The internals have support for this as it was needed for SVF support. Again, it may just need to be exposed at the TCL layer.

Kees Jongenburger wrote:

I then focused on getting the right sequence into the beagle using urjtag[4].
This required adding support for the flyswatter in urjtag. By the time this was
added I discovered that Flyswatter support was already in the SVN version of
urjtag. This was a nice waste of time :stuck_out_tongue:

After my initial ICEPICK mail on urjtag the list[5] I rewrote the
sequence to use the
SVF format. I think it now matches the sequence described on the
elinux wiki[3] "bit for bit"
However I think that the scan chain is still only contains the
ICEPICK(ir scan is still 6 bits)

Taking Kees's idea to first start with urjtag as it is more hackable, I switched to urjtag, too.

But instead of working with SVF files, I try to hack something like a "OMAP3 init" command directly in urjtag's C code.

The recent status of this is

http://sourceforge.net/mailarchive/forum.php?thread_name=499DC3CE.7060907%40googlemail.com&forum_name=urjtag-development

So no luck (and some confusion like with Kees), too.

Best regards

Dirk

I support what Rick is saying.

I think we can work through it. With diligent usage of tap_set_state()
when its full logging is enabled, this can be tracked down. There is
currently not diligent usage of tap_set_state() in effect in any cable
driver. But that is on my to do list when I get back to this.

My vision is that any state transition must be reported to
tap_set_state(). This way problems like this become easier to diagnose.

Dick