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) |