JTAG explorer toy

From Electriki
Revision as of 18:23, 4 January 2009 by Michai (talk | contribs)
Jump to navigationJump to search
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's what I would like to see; I'd like to...

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

work in progress, tumdedum...