Difference between revisions of "JTAG explorer toy"
Line 136: | Line 136: | ||
For example, to write a specific register, the following must be done: | For example, to write a specific register, the following must be done: | ||
− | # navigate to state 'Shift-IR' by clocking in the right sequence of values from <tt>TMS</tt> | + | # navigate to state 'Shift-IR' by clocking in the right sequence of values from <tt>TMS</tt>, |
− | # clock in all instruction-bits | + | # clock in all instruction-bits (except the last one -- see below), |
− | # update the instruction-register by moving to state 'Update-IR' | + | # update the instruction-register by moving to state 'Update-IR' (while clocking in the last instruction-bit), |
− | # navigate to state 'Shift-DR' | + | # navigate to state 'Shift-DR', |
− | # clock in all data-bits | + | # clock in all data-bits. |
Some states 'do 1 thing, once', e.g. have the chip fill a parallel shift-register | Some states 'do 1 thing, once', e.g. have the chip fill a parallel shift-register |
Revision as of 23:12, 4 January 2009
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 this issue 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.
How JTAG works (as I understood it)
JTAG normally uses a single master/host to read/set states of one or more chips. There may be separate (JTAG) communication-channels between the host and each chip, or chips can be daisy-chained, so that the system's interface is kept simple and small.
Of course this is not complete; for more details, browse the lovely Internet.
Basic idea
Communication comes down to selecting which data to operate on, and then reading/writing that data.
Single-chip setup
In a 1-chip JTAG-setup, the chip contains an instruction-register and a number of task-specific data-registers. The host can shift bits into each register; when a bit is shifted in, a bit falls out at the other end. Shifting always occurs in the same direction.
The host selects which data-register is active by entering an instruction-code, and then operates on the corresponding data-register. Writing/reading of both instruction- and data-registers occurs in the same way, by shifting bits in/out.
Multiple-chip setup
This works like above, except the complete system (more chips together) can be viewed as a number of big registers (where different parts/offsets in a register may live on different chips).
Bus-description
A chip offers access to its JTAG-subsystem through a port (more about this in another section), consisting of 4 (or 5) I/O-lines:
- TCK (Test ClocK) will be used to clock bits in/out of the device, and initiate mode-change.
- TMS (Test Mode Select) is used to traverse through the TAP-controller's state-machine. It is sampled on rising edge of TCK. Values in the state-machine diagram indicate values for TMS.
- TDI (Test Data In) contains values to be shifted into the device. It is sampled on rising edge of TCK.
- TDO (Test Data out) will contain bits shifted out of the device. It changes on falling edge of TCK.
See Fig.5 for an idea about timing of these signal.
Daisy-chaining chips
The TDI- and TDO-lines may be used to daisy-chain chips together -- chip #1's TDO is connected to chip #2's TDI. The host then shifts bits into chip #1's TDI, and catches bits falling out of the TDO of the last chip in the chain.
In such a daisy-chain, all chips share the TCK- and TMS-lines. Although sharing a clock may be normal, the common TMS-line was quite surprising to yours truly. But it still makes sense!
TAP-controller
The TAP (Test Access Port) controller is part of every JTAG-enabed chip, and basically implements a state machine. The TMS-line navigates between states on each rising edge of TCK.
Instructions and data
As mentioned before, the TAP-controller has 1 (fixed-size) instruction-register and multiple, arbitrarily-sized data-registers. Although there are many data-registers, only one can be operated on at a time.
One of the beautiful things, IMHO, about JTAG is that the chip 'connects' one of its data-registers between TDI and TDO on request. Subsequent operations then take place on that DR. This is no different than address-/data-selection (in that order) elsewhere, but this 'connecting' actually makes the bit-path through the chip (from TDI to TDO shorter and longer on request!
State-machine
See Fig.4: each state leads to 2 states (one of which may be itself); the selection is done by the value of TMS at the next clock pulse.
For example, to write a specific register, the following must be done:
- navigate to state 'Shift-IR' by clocking in the right sequence of values from TMS,
- clock in all instruction-bits (except the last one -- see below),
- update the instruction-register by moving to state 'Update-IR' (while clocking in the last instruction-bit),
- navigate to state 'Shift-DR',
- clock in all data-bits.
Some states 'do 1 thing, once', e.g. have the chip fill a parallel shift-register to be subsequently shifted out on TDO, but other states 'keep on doing something' during multiple TCK-cycles. To keep them in that state, TMS must be set accordingly.
A state-transition takes place after the data shifted in at that clock-pulse, if relevant, is processed. In other words, bits shifted in always apply to the current state, not the possibly new one indicated by TMS at that clock-pulse. So, if N bits must be shifted in at a state, this is how it's done:
- enter the state by setting TMS and raising TCK,
- clock the 1st (N-1) bits in, keeping TMS so that the state is not left,
- set TMS to navigate to the next state, and clock the last bit in.
Analogously, for a positive clock pulse, the bit falling out out at TDO applies to the new state, if there was a state-change at the rising edge of TCK.
Boundary-scan chain
JTAG can be used to read/stimulate I/O at a chip's pins. The chip's core logic can be decoupled from its I/O-pins as well; see Fig.3 for an idea: 'boundary-scan cells' sit in between the chip's core logic and the actual pin.
A chain of these cells ('boundary-scan chain') may be selected to sit between TDI and TDO by issueing the proper instruction, so that current/new values to/from the outside world or the chip's core logic can be shifted in or out.
Together with daisy-chaining multiple chips, this can give the developer a system where chips ('inside the socket') and e.g. PCB-tracks (between sockets) can be tested, with only 4 pins dedicated for this purpose!
JTAG-toy hardware
So ok, enough about that -- time to solder! As mentioned before, the proto-board to play with all this technology will have 2 MCU's: a JTAG-slave and a JTAG-master. The PC initiates commands to either MCU through a serial link (at a whopping 1200 bps, plenty of time to handle commands -- CBA to write proper interrupt-handlers and do proper buffering ;-)
Wiring and MCU-overkill
The slave-MCU is a big ATmega32; although we will only use about 10 I/O pins, it was the only JTAG-capable Atmel MCU I had. So there. For master I used the wonderful ATtiny2313.
As can be seen in the schematics in Fig.6, for performing actual tests using boundary-scan chain, there are dedicated I/O-lines...
- 'AB', running from master ('A') to slave ('B'),
- 'PQ', running from slave ('P') to master ('Q'),
- 'XY', running from slave ('X') to itself ('Y').
These lines have LEDs so I can see what's going on. Apart from the 4 other lines to the slave's JTAG-port, the master also controls the slave's reset-line.
From an idea by MHL, both master and slave share the Tx- and Rx-lines to a MAX232 receiver/driver. Both always receive, but only one can/should transmit at a time.
Since communication between PC and board is done in a query/response fashion, the MCU for which a query was intended, enbles its transmitter from software; its Tx-line then changes from hi-Z to active, and it sends its reply. The master and slave have a totally disjunct command-set for this to work.
work in progress, tumdedum...