| 03:03.47 | *** join/#openjtag ka6sox-away (n=ka6sox@204.16.19.246) |
| 03:13.01 | *** join/#openjtag rwhitby (n=nnnnnnrw@nslu2-linux/rwhitby) |
| 03:57.22 | *** join/#openjtag ka6sox-away (n=ka6sox@204.16.19.246) |
| 05:08.51 | *** join/#openjtag ka6sox-away (n=ka6sox@204.16.19.246) |
| 05:27.11 | *** join/#openjtag knoppix_ (n=knoppix@gimpelevich.san-francisco.ca.us) |
| 09:55.09 | *** join/#openjtag pleemans (n=peter@d51A5E76A.access.telenet.be) |
| 09:56.59 | *** join/#openjtag pleemans (n=peter@d51A5E76A.access.telenet.be) |
| 13:03.43 | sn9 | anybody around? |
| 13:04.15 | sn9 | i'm finally getting the chance to try openocd |
| 13:05.11 | drath | hey |
| 13:05.25 | sn9 | i'm getting this error: number of discovered devices in JTAG chain (51) doesn't match configuration (1) |
| 13:05.42 | sn9 | i think it's some reset protocol mismatch |
| 13:05.44 | drath | which JTAG interface do you use, which target, and which version of the openocd? |
| 13:07.03 | sn9 | wiggler, arm926ejs, 2007-07-31 19:00 CEST |
| 13:10.45 | sn9 | drath: any ideas? |
| 13:13.58 | drath | well, it's a very low-level commuication problem |
| 13:14.21 | drath | the OpenOCD scans a fixed bit pattern in, and reads out the IDCODEs |
| 13:14.33 | drath | in your case it's receiving somewhat random data |
| 13:14.45 | drath | which arm926ej-s exactly? |
| 13:14.58 | drath | is it a geniuine wiggler? |
| 13:16.11 | sn9 | it is not from macraigor |
| 13:16.22 | sn9 | the SoC is marvell |
| 13:16.30 | drath | then it's not a real arm926ej-s ;) |
| 13:16.54 | drath | it just identifies itself as one, but marvell has a license that allows them to modify the original ARM ip |
| 13:17.26 | drath | are you on windows or on linux? |
| 13:17.31 | sn9 | lin |
| 13:17.40 | drath | did you build with ppdev support? |
| 13:17.43 | sn9 | yes |
| 13:17.53 | drath | did you remove the "lp" module? |
| 13:18.20 | sn9 | whoops |
| 13:18.38 | drath | it's not strictly necessary, but I've seen all kinds of weird behaviour with parallel ports |
| 13:19.00 | drath | where did you get your wiggler from - something you've built yourself? |
| 13:19.07 | sn9 | nah |
| 13:19.41 | sn9 | ok, now the number changed from 51 to 20 |
| 13:19.53 | drath | heh, that's equally bad |
| 13:21.13 | sn9 | is srst parport pin 2 or trst? |
| 13:24.38 | sn9 | as far as the software is concerned, that is |
| 13:25.52 | drath | pin 2 |
| 13:26.00 | drath | and it should not be inverted |
| 13:26.11 | sn9 | then where is srst expected? |
| 13:28.44 | drath | pin 6, and it should be inverted |
| 13:30.29 | sn9 | pin 6 unused here, and pin 2 == RST, going to nTRST through a transistor |
| 13:30.39 | *** join/#openjtag prpplague (n=billybob@mail.americanmicrosystems.com) |
| 17:38.30 | sn9 | drath: still there? |
| 17:43.54 | *** join/#openjtag rd_ (n=rd@toi.yeu.phu.nu) |
| 17:48.46 | sn9 | rd_: hi |
| 18:27.20 | *** join/#openjtag Chocobo (n=swinchen@strongbad.eece.maine.edu) |
| 18:36.01 | *** join/#openjtag rd_ (n=rd@toi.yeu.phu.nu) |
| 19:02.25 | *** join/#openjtag ka6sox-away (n=ka6sox@204.16.19.246) |
| 19:03.40 | sn9 | drath: according to the source code, it's the other way around -- pin 2 is srst, and pin 6 is trst |
| 19:05.28 | sn9 | pin 6 is unused on my wiggler thing |
| 20:33.44 | drath | sn9: hey |
| 20:34.00 | drath | sn9: let me double check that |
| 20:34.09 | drath | sn9: in only had a brief look at some old drawings |
| 20:35.51 | sn9 | i'm trying different possible cable definitions atm |
| 20:37.11 | drath | you are right, the code has ntrst at pin 6, nsrst at pin 2 |
| 20:37.16 | drath | so that's the "genuine" wiggler layout |
| 20:39.16 | sn9 | i'm comparing three schematics: |
| 20:39.16 | sn9 | http://www.k9spud.com/jtag/schematic-1.0.php |
| 20:39.16 | sn9 | http://www.diygadget.com/images/jtag/wiggler/wiggler.buffer.jtag.fta.schematic.jpg |
| 20:39.16 | sn9 | http://wiki.dns323.info/_media/hardware:dns-323-jtag.pdf?id=hardware%3Ajtag&cache=cache |
| 20:39.39 | drath | there's a great deal of confusion |
| 20:40.01 | drath | the definition labeled "wiggler" in the OpenOCD source is known to work with original wigglers and the ARM-JTAG from Olimex |
| 20:40.24 | drath | it is also the one used by Amontec's chameleon in its Wiggler configuration, but only by the latest update |
| 20:40.35 | drath | I think this one is the "original" layout |
| 20:40.45 | drath | but you can easily add a layout of your own |
| 20:41.59 | sn9 | the board has the same jtag pinout as the dns323, i.e. only one type of reset line |
| 20:42.12 | sn9 | http://wiki.dns323.info/hardware:jtag |
| 20:42.30 | sn9 | the cable is the diygadget one |
| 20:43.48 | sn9 | according to the debug log, parport_reset() always gets called only once, to deassert both lines |
| 20:44.40 | sn9 | after that, "TRST asserted" always gets reported three times |
| 20:45.40 | sn9 | i did not use a resistor on the EN line -- plugged it straight into Vcc |
| 20:46.41 | sn9 | drath: any ideas? |
| 20:49.18 | sn9 | if i mark pin 2 as a non-inverted signal, the device stays in a halted state |
| 20:53.22 | drath | TRST asserted is also called when the TMS sequence that moves to Test-Logic-Reset executes |
| 20:54.02 | drath | you could try old_amt_wiggler |
| 20:54.26 | drath | that one has D0 (Pin2) as an inverted nTRST signal |
| 20:55.17 | drath | use "reset_config trst_only" in the .cfg file |
| 20:56.49 | sn9 | <PROTECTED> |
| 20:56.49 | sn9 | <PROTECTED> |
| 20:56.50 | *** join/#openjtag juanpaul (n=juan@189-20-46-108.asernet.com.br) |
| 20:57.06 | sn9 | those are what i'm trying now |
| 20:57.59 | sn9 | no luck so far |
| 20:59.01 | drath | well, that's the main problem with parallel ports - you never know why they fail |
| 20:59.27 | drath | have you been able to use this PC's parallel port with some other paralle port JTAG software? |
| 21:00.24 | sn9 | have not tried |
| 21:01.00 | sn9 | i know pin 2 is responsive, because if i don't invert it, the device stays in a halted state |
| 21:01.38 | *** join/#openjtag drath_ (i=vmaster@p5B07E72F.dip.t-dialin.net) |
| 21:02.01 | sn9 | i know pin 2 is responsive, because if i don't invert it, the device stays in a halted state |
| 21:03.31 | drath | did you try lowering the JTAG speed (higher jtag_speed divisor) |
| 21:03.53 | sn9 | i thought that was ignored for parport |
| 21:05.02 | drath | no, it's used to output the same pattern (jtag_speed+1) times, effectively diving the maximum frequency |
| 21:06.51 | sn9 | how much higher should i make the jtag_speed? |
| 21:07.27 | drath | 1 or 2 |
| 21:07.52 | drath | that results in a frequency of 100 kHz or so |
| 21:24.33 | sn9 | how do i tell whether to use push_pull or open_drain? |
| 21:24.55 | drath | in your case it doesn't matter |
| 21:25.04 | sn9 | because? |
| 21:25.05 | drath | that's for cables that allow the reset lines to be either of both |
| 21:25.36 | sn9 | how do i tell the difference between the reset line types? |
| 21:25.37 | drath | in your case the reset line is open-drain, which inverts it |
| 21:26.16 | sn9 | ah, ok |
| 21:48.20 | drath | i'm off for today, bye sn9 |
| 21:48.28 | sn9 | ok |
| 21:56.14 | *** join/#openjtag dwery (n=dwery@nslu2-linux/dwery) |
