Difference between revisions of "JTAG explorer toy"
| Line 18: | Line 18: | ||
This is of course bad, because... | This is of course bad, because... | ||
<blockquote> | <blockquote> | ||
| − | ''JTAG is '''THE SHIT''' - like [[:Image:Batman.jpg|Batman]]!'' | + | ''JTAG is '''THE SHIT''' -- like [[:Image:Batman.jpg|Batman]]!'' |
</blockquote> | </blockquote> | ||
...or well, it's nice anyway. | ...or well, it's nice anyway. | ||
| Line 25: | Line 25: | ||
I interpreted the ATmega32-datasheet and (quite) some on-line docs as best as | 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 | + | 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 | this thing is '''totally useless''', so questions/comments regarding will be | ||
ignored. Xmas season, too much time, so there :-) | ignored. Xmas season, too much time, so there :-) | ||
| Line 33: | Line 35: | ||
The idea for me was to make a simple [[:Image:Michai_015_board.jpg|toy-board]] | 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 | 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, | + | 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 | 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 | + | its JTAG-port. |
| + | |||
| + | The master itself is not JTAG-enabled, but drives/reads the slave's | ||
JTAG-port I/O-pins. | JTAG-port I/O-pins. | ||
| Line 43: | Line 49: | ||
and so that's what I would like to see; I'd like to... | 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) | * put it in, and take it out of reset (reset/suspend/resume) | ||
* decouple core logic from I/O pins, and read/set them from [[:Image:Michai_015_bsc.jpg|boundary cells]] instead | * decouple core logic from I/O pins, and read/set them from [[:Image:Michai_015_bsc.jpg|boundary cells]] instead | ||
Revision as of 18:23, 4 January 2009
Contents
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...
