| 01:26.43 | *** join/#openjtag brolin (n=brolin@190.157.14.3) |
| 02:56.04 | *** join/#openjtag rogan (n=rogan@dsl-246-39-181.telkomadsl.co.za) |
| 03:49.28 | *** join/#openjtag rje`mac (n=rje`mac@c-67-185-128-239.hsd1.wa.comcast.net) |
| 04:01.01 | *** join/#openjtag rje`mac (n=rje`mac@c-67-185-128-239.hsd1.wa.comcast.net) |
| 05:57.18 | *** join/#openjtag pleemans (n=toi@d54C2AAB7.access.telenet.be) |
| 05:59.51 | *** join/#openjtag |val| (n=kvirc@AFontenayssB-151-1-47-168.w82-121.abo.wanadoo.fr) |
| 06:02.01 | |val| | Hi again, in the case where we have several tap controllers, if we ask for the IDCODE for the first one tap (via TDI), TDO will return the IDCODE to the second tap controller. There is some thing I don't understand, how the IDCODE of the first tap controller will arrived to the TDO at the end of TAP chain (is the second the second tap controller has to be set in bypass mode ?)? |
| 06:02.09 | |val| | where can I get some informations about the serial communication from the question to the answer ? |
| 06:24.24 | keesj | hi |
| 06:25.16 | keesj | its a very nice trick overall (how jtag works). |
| 06:26.47 | keesj | you have to looks at it in two ways. first the jtag state machine, this state machine is controlled using the clock + the tms and all the taps will always be in the same "state" as they are in parralel |
| 06:28.34 | keesj | but for reading/writing data this process is serial and the taps are attached ot eachother. for example all the taps are set to "instruction scan" and new data it put in the registers |
| 06:29.03 | *** join/#openjtag pocek (i=pock@77-253-48-233.adsl.inetia.pl) |
| 06:29.33 | keesj | so If I have two taps and there instrcution register lenthg are 3 and 4 I will need to program booth at the same time (3 + 7 bits) data |
| 06:30.34 | keesj | after a reset "by default" all the taps are in "IDCODE" mode, add you really have to do is to put all state machines in DRSCAN and push the data out |
| 06:31.43 | rogan | hi folks. I am trying to find out whether a JTAG adapter that claims support for ARM chips is likely to support a MIPS EJTAG interface as well |
| 06:31.44 | keesj | what happens on every clock tick is that the data is shifted (you need to provide one bit and all the last bit from the first tap is shifted to the second tap , and the last bit from the last tap is shifted out to the TDO |
| 06:31.48 | rogan | i.e. would the http://www.olimex.com/dev/arm-usb-tiny.html be able to access devices such as the WRT54G, etc? |
| 06:31.50 | rogan | that or this one: http://www.amontec.com/jtagkey-tiny.shtml |
| 06:32.30 | keesj | |val|: are you stil with me? |
| 06:32.58 | rogan | obviously I'd need a suitable header cable, since that ARM pin out and the EJTAG pinouts are different (20 vs 12 pins to start with) |
| 06:34.06 | keesj | rogan: I don't think is really matters , it's the software that matters . I personally really like the jtagkey's and the flyswatter |
| 06:34.28 | rogan | flyswatter? |
| 06:35.21 | keesj | http://www.tincantools.com/product.php?productid=16134 |
| 06:36.42 | keesj | they also have a converted for for 14 pins MIPS http://www.tincantools.com/product.php?productid=16145&cat=251&page=1 |
| 06:36.59 | keesj | but the hardware is very hackable because of it's size |
| 06:37.14 | keesj | and you get the serial |
| 06:37.23 | rogan | sweet, thanks |
| 06:43.15 | rogan | would be nice if the serial port was switchable to 3.3V, too |
| 06:43.21 | rogan | but not a train smash either way |
| 06:54.22 | |val| | keesj: yes |
| 06:54.27 | keesj | apparently it does (lookup the sp2343 datasheet) |
| 06:55.33 | keesj | but I am no electrical engineer... |
| 06:56.30 | keesj | |val|: so you understand now? |
| 06:59.51 | keesj | with most normal jtag operation people will try to put all the other taps in bypass but specialy for the IDCODE the thing they do is to reset the board and push data in the scan chain |
| 07:04.45 | *** part/#openjtag rogan (n=rogan@dsl-246-39-181.telkomadsl.co.za) |
| 07:22.36 | |val| | keesj: it's very interesting...just let me time to understand, thanks a lot |
| 08:07.34 | |val| | keesj: in your case, the two taps are controlled is the same time, to send instructions we need 3 + 4 = 7 bits, 7 clocks ? |
| 08:10.19 | |val| | I think I understand now, in IDCODE mode (all taps are in this state), the answer are send in serial one after the other very simply |
| 10:25.34 | *** join/#openjtag pirho (i=pirho@gateway/gpg-tor/key-0x2CEEC9CB) |
| 10:52.27 | *** join/#openjtag |val| (n=kvirc@AFontenayssB-151-1-47-168.w82-121.abo.wanadoo.fr) |
| 12:28.42 | keesj | |val|: indeed , so most of the time when setting the instruction of a specific tap you will set all other taps in bypass , so what when you read your data you have less clock clycle to do |
| 16:21.07 | *** join/#openjtag pleemans (n=toi@d54C2AAB7.access.telenet.be) |
| 17:34.10 | *** join/#openjtag dirk2 (n=dirk@p5B040F88.dip0.t-ipconnect.de) |
| 18:30.03 | *** join/#openjtag jeez__ (n=jeez@200.184.118.130) |
| 19:52.19 | *** join/#openjtag starkmjolk- (n=starkmjo@h-91-88.A163.priv.bahnhof.se) |
| 20:10.59 | *** join/#openjtag pleemans (n=toi@d54C2AAB7.access.telenet.be) |
| 21:25.13 | *** join/#openjtag brolin (n=brolin@nat50.udea.edu.co) |