Difference between revisions of "JTAG explorer toy"

From Electriki
Jump to navigationJump to search
Line 11: Line 11:
 
[[Image:michai_015_board.jpg|thumb|'''Fig.6: 'after'.''' Finished toy-board. The funny thing is that when it's finished and toying has been done, it'll totally useless.]]
 
[[Image:michai_015_board.jpg|thumb|'''Fig.6: 'after'.''' Finished toy-board. The funny thing is that when it's finished and toying has been done, it'll totally useless.]]
  
== LALALA ==
+
== What is this, and, why..? ==
  
la.
+
I heard a lot about '''JTAG''', but never got to do anything with it,
 +
mainly because I CBA, and I didn't actually ''had to'' do anything with it.
 +
 
 +
This is of course bad, because...
 +
<blockquote>
 +
''JTAG is '''THE SHIT''' - like [[:Image:Batman.jpg|Batman]]!''
 +
</blockquote>
 +
...or well, it's nice anyway.
 +
 
 +
=== Disclaimer ===
 +
 
 +
I interpreted the ATmega32-datasheet and (quite) some on-line docs as best as
 +
I could; however, if there's a bug/flaw somewhere, let me know please. Note that
 +
this thing is '''totally useless''', so questions/comments regarding will be
 +
ignored. Xmas season, too much time, so there :-)
 +
 
 +
=== Overview/summary ===
 +
 
 +
The idea for me was to make a simple [[:Image:Michai_015_board.jpg|toy-board]]
 +
with 2 MCU's on it -- one acting as JTAG host/master, and the other being
 +
JTAG-victim. The PC talks to the master and slave through a serial protocol,
 +
to read/set pins, and so initiate JTAG-actions; master talks to slave only through
 +
its JTAG-port. The master itself is not JTAG-enabled, but drives/reads the slave's
 +
JTAG-port I/O-pins.
 +
 
 +
=== What I would like to see ===
 +
 
 +
As I understood, JTAG offers a nice 'backdoor' into a (slave-)chip's state, and so that'
 +
what I would like to see; I'd like to...
 +
* put it in, and take it out of reset (reset/suspend/resume)
 +
* read/set I/O pins, and decouple core logic from I/O pins (and drive them from [[:Image
 +
* and some more, basically '''toy with it'''.
 +
 
 +
----
 +
work in progress, tumdedum...

Revision as of 18:05, 4 January 2009

Fig.1: batman. Holy mackerel Batman! JTAG really is THE SHIT!!1
Fig.2: toy-board schematics. The only slightly interesting bits are the 4 TAP-lines going between the MCU's, and the fact they share mutually-exclusive use of the serial Tx-line (the Rx-line is always shared).
Fig.3: JTAG boundary-scan chain. A host talks to the TAP (Test Access Port) controller using 4 lines, shifting data in and out.
Fig.4: 2 JTAG boundary-scan cells. One cell sits between core logic and an input pin, and the other sits between core logic and an output pin.
Fig.5: 'before'. The big MCU there (ATmega32) is horribly oversized both in size and ability for this application, but ok, was all I had.
Fig.6: 'after'. Finished toy-board. The funny thing is that when it's finished and toying has been done, it'll totally useless.

What is this, and, why..?

I heard a lot about JTAG, but never got to do anything with it, mainly because I CBA, and I didn't actually had to do anything with it.

This is of course bad, because...

JTAG is THE SHIT - like Batman!

...or well, it's nice anyway.

Disclaimer

I interpreted the ATmega32-datasheet and (quite) some on-line docs as best as I could; however, if there's a bug/flaw somewhere, let me know please. Note that this thing is totally useless, so questions/comments regarding will be ignored. Xmas season, too much time, so there :-)

Overview/summary

The idea for me was to make a simple toy-board with 2 MCU's on it -- one acting as JTAG host/master, and the other being JTAG-victim. The PC talks to the master and slave through a serial protocol, to read/set pins, and so initiate JTAG-actions; master talks to slave only through its JTAG-port. The master itself is not JTAG-enabled, but drives/reads the slave's JTAG-port I/O-pins.

What I would like to see

As I understood, JTAG offers a nice 'backdoor' into a (slave-)chip's state, and so that' what I would like to see; I'd like to...

  • put it in, and take it out of reset (reset/suspend/resume)
  • read/set I/O pins, and decouple core logic from I/O pins (and drive them from [[:Image
  • and some more, basically toy with it.

work in progress, tumdedum...