**** BEGIN LOGGING AT Wed Nov 22 02:59:58 2006 Nov 22 11:43:14 hey [g2] Nov 22 11:43:29 00:12 < [g2]> vmaster I'm guessing flashing works right ? Nov 22 11:43:31 * [g2] hugs vmaster good moring ;) Nov 22 11:43:35 yes, flashing works fine Nov 22 11:43:56 <[g2]> s-w-e-e-t ! Nov 22 11:43:57 I've soldered a new 14->20 pin adapter, and this time I could connect to the EP93xx ok Nov 22 11:44:26 <[g2]> vmaster is such a S-T-U-D ! Nov 22 11:44:30 but it still behaves weird - it wont find the flash most of the time, with the GW dongle connected Nov 22 11:44:49 but that might be the boards fault Nov 22 11:44:52 <[g2]> I wonder if the timing is a little too tight Nov 22 11:45:17 the EP93xx specifies a TCK-low minimum time of 50ns, the GW dongle pulses it low for 60ns Nov 22 11:46:21 <[g2]> I'm guessing the TCK going low is based on a DPLL Nov 22 11:46:24 don't think that's the problem, though, cause even if the dongle is just connected, with no debugger running, it will blink the Green LED, signaling that it didn't find a valid signature in none of the flash banks Nov 22 11:47:02 more like a problem with Vcc and/or GND Nov 22 11:47:45 <[g2]> GND whould be fine, but pins 2 and 13 may need to bridged to GND Nov 22 11:48:16 <[g2]> could be a voltage issue on VCC Nov 22 11:48:51 <[g2]> what is the EP93XX supplying for VCC ? Nov 22 11:49:57 3.3V Nov 22 11:50:11 <[g2]> hmm... that should be ok Nov 22 11:52:22 hmm, pin2 might be a problem Nov 22 11:52:29 or /the/ problem Nov 22 11:52:44 <[g2]> nod that's why I mentioned them Nov 22 11:58:47 <[g2]> vmaster did you connect a resistor for the LPC test ? Nov 22 11:58:53 * [g2] is guessing yes Nov 22 11:59:20 <[g2]> or maybe your LPC board doesn't need it Nov 22 12:00:49 resistor? Nov 22 12:00:53 you mean to RTCK? Nov 22 12:00:58 that's already fitted on the board Nov 22 12:02:25 <[g2]> ok Nov 22 12:03:22 <[g2]> vmaster I'd like to try flashing and debugging on the XScale Nov 22 12:04:25 i have to get rid of one last problem with the reset lines Nov 22 12:04:31 these are crucial for the XScale Nov 22 12:04:42 <[g2]> Ok. that's super Nov 22 12:04:50 vmaster: hi Nov 22 12:04:52 well, I'm not completely sure if they are problems - could be the STR7, either Nov 22 12:04:54 nbd: hey Nov 22 12:04:57 vmaster: still want that hw porn of the wrv54g board? Nov 22 12:05:06 nbd: yeah, sure Nov 22 12:05:13 ok, i'll upload it now Nov 22 12:05:16 <[g2]> vmaster you've made tremendous progress :) Nov 22 12:05:19 nbd: cool, thanks Nov 22 12:07:14 ok, resets work fine when connected to the EP93xx, so I guess the reset problems i was seeing were related to the STR7 - many of the small arms deny debugging out of reset Nov 22 12:08:11 <[g2]> ah... so ppl can't just get control of the processor and pull out the code from flash ? Nov 22 12:08:32 yeah Nov 22 12:09:29 <[g2]> does the XScale have hw breakpoints ? Nov 22 12:09:37 two Nov 22 12:09:53 <[g2]> double the pleasure double the fun :) Nov 22 12:09:53 and one or two hw watchpoints, depending on how you use them Nov 22 12:10:12 <[g2]> and is there a tracebuffer ? Nov 22 12:11:05 I don't think so Nov 22 12:11:11 http://nbd.name/wrv/ - first one's up, second one still uploading... Nov 22 12:11:30 <[g2]> p2-mate there the performance monitor block Nov 22 12:11:32 i hope they're clear enough Nov 22 12:11:40 took me a few tries with my camera Nov 22 12:12:14 there is a tracebuffer Nov 22 12:12:24 256-byte deep Nov 22 12:12:31 not much, but definitely fun Nov 22 12:14:38 ok, second picture up Nov 22 12:18:45 great, thanks Nov 22 16:48:23 [g2]: i've just committed a new version to the XScale branch, including the GW16012 support Nov 22 16:48:50 let me know when you're ready to give it a try Nov 22 16:50:47 <[g2]> vmaster is ready :) Nov 22 16:51:14 <[g2]> vmaster I'll pull and build Nov 22 16:56:19 ./configure --enable-gw16012 (--enable-parport_ppdev if you want to use /dev/parportN instead of direct I/O w/ root privs) Nov 22 16:58:48 <[g2]> vmaster I've got -r 118 for xscale Nov 22 16:58:56 ok Nov 22 16:59:17 ah, you have to ./bootstrap before Nov 22 17:03:20 <[g2-build]> vmaster: Ok I've got r 118 of the xscale and I'm attempting to boostrap Nov 22 17:03:32 <[g2-build]> bootstrap Nov 22 17:06:35 <[g2-build]> src/jtag/Makefile.am:64: warning: automake does not support conditional definition of FT2232FILES in libjtag_a_SOURCES Nov 22 17:06:57 <[g2-build]> is there a specific version of automake ? Nov 22 17:07:40 mhh, not really, but it seems that i have to change the jtag/Makefile.am - so far, only some windoze boxes failed, but it seems this is a more general problem Nov 22 17:08:59 <[g2-build]> I'm not building for FT2232 so can i comment that out ? Nov 22 17:09:32 http://mmd.ath.cx/openocd/XScale_Makefile_am.patch Nov 22 17:09:36 <[g2-build]> but it is a "warning" and there's no "./configure" Nov 22 17:09:44 the wonders of autotools... Nov 22 17:11:53 <[g2-build]> vmaster: that completes Nov 22 17:12:08 <[g2-build]> so now ./configure --enable-gw01612 ? Nov 22 17:12:15 <[g2-build]> or gw16012 Nov 22 17:13:04 gw16012 Nov 22 17:13:41 <[g2-build]> Ok it built on the mac mini Nov 22 17:14:09 mhh, a Big-Endian mac-mini? Nov 22 17:14:29 <[g2-build]> little endian x86 Nov 22 17:14:32 ah, ok Nov 22 17:14:57 <[g2-build]> I've got to boot the celery that's got the parallel port Nov 22 17:15:18 <[g2-build]> brb back Nov 22 17:17:19 * [g2] boots celery with the parallel port Nov 22 17:28:29 <[g2]> http://mmd.ath.cx/openocd/XScale_Makefile_am.patch Nov 22 17:31:59 <[g2-jtag]> vmaster, Ok all built on the jtag machine Nov 22 17:34:42 <[g2-jtag]> vmaster, Ok hw all connected Nov 22 17:34:53 [g2-jtag]: http://mmd.ath.cx/openocd/ixp42x_gw.cfg Nov 22 17:34:58 that should work for your board Nov 22 17:35:06 you only have the IXP in the JTAG chain, right? Nov 22 17:35:12 <[g2-jtag]> vmaster, nod Nov 22 17:35:17 you'll have to adjust the "flash bank cfi" line to suit your flash Nov 22 17:35:29 ah, and what type of flash do you use? Nov 22 17:37:09 <[g2-jtag]> It's an Intel TE28F128 Nov 22 17:37:23 <[g2-jtag]> JC3120 Nov 22 17:37:38 ok, that should work Nov 22 17:37:42 <[g2-jtag]> that's just the chip rev / speed grade Nov 22 17:37:48 <[g2-jtag]> ok Nov 22 17:39:09 there could be all kinds of problems with your bigendian IXP, but nothing that can't be fixed with a few changes Nov 22 17:39:31 <[g2-jtag]> vmaster nod. I'm not worried :) Nov 22 17:39:44 <[g2-jtag]> this is a work-in-progres Nov 22 17:39:46 <[g2-jtag]> s Nov 22 17:39:51 ./openocd -f ixp42x_gw.cfg -d (-l ) Nov 22 17:40:46 <[g2-jtag]> Info: openocd.c:83 main(): Open On-Chip Debugger (XScale branch, 2006-11-22 14:00 CEST) Nov 22 17:40:58 did you run with -d? Nov 22 17:41:50 <[g2-jtag]> ./openocd -f ixp42x_gw.cfg -d -l log.txt Nov 22 17:41:50 <[g2-jtag]> Info: openocd.c:83 main(): Open On-Chip Debugger (XScale branch, 2006-11-22 14:00 CEST) Nov 22 17:41:55 ah, ok Nov 22 17:42:01 did it exit? Nov 22 17:42:04 <[g2-jtag]> yeah Nov 22 17:42:05 or is it still running? Nov 22 17:42:11 can you send me the log.txt? Nov 22 17:42:19 <[g2-jtag]> absolutely Nov 22 17:42:59 <[g2-jtag]> Error: configuration.c:121 parse_config_file(): couldn't open config file Nov 22 17:43:13 ah, hehehe Nov 22 17:43:22 <[g2-jtag]> I guess I need it in the doc dir Nov 22 17:43:24 the OpenOCD expects the .cfg in the current working directory Nov 22 17:44:07 <[g2-jtag]> ooh... blinky lights Nov 22 17:45:34 uhm, continously blinking? Nov 22 17:45:36 <[g2-jtag]> vmaster, do you care if I pastebin the log.txt file ? Nov 22 17:45:42 <[g2-jtag]> no stopped Nov 22 17:45:42 that's fine Nov 22 17:45:57 <[g2-jtag]> http://pastebin.ca/255147 Nov 22 17:46:06 * [g2-jtag] hugs vmaster :) Nov 22 17:48:50 could you try a few times to see if it stops at the same point? Nov 22 17:48:56 <[g2-jtag]> sure Nov 22 17:50:28 <[g2-jtag]> Ok I ran it 5 more times and 3 are the same but 2 are not Nov 22 17:51:10 <[g2-jtag]> > Debug: jtag.c:1032 jtag_read_buffer(): fields[0].in_value: 0x01ff Nov 22 17:51:10 <[g2-jtag]> > Error: jtag.c:1185 jtag_validate_chain(): Error validating JTAG scan chain, IR mismatch, scan returned 0x01ff Nov 22 17:51:25 <[g2-jtag]> the two that fail don't seem to get started Nov 22 17:52:49 ok, there's a very low-level communication problem Nov 22 17:53:34 <[g2-jtag]> ok Nov 22 17:54:01 [g2-jtag]: what jtag speed are you running at? Nov 22 17:54:13 [g2-jtag]: this a ft2232 based? Nov 22 17:54:17 prpplague: there's only one jtag_speed for the GW16012 Nov 22 17:54:30 ahh Nov 22 17:54:37 <[g2-jtag]> prpplague, it runs around 4Mhz Nov 22 17:55:09 <[g2-jtag]> but there are really two modes Nov 22 17:55:37 mhh, i measured 8.3MHz Nov 22 17:56:28 <[g2-jtag]> vmaster ok Nov 22 17:56:53 the chain validation uses single-bit accesses Nov 22 17:57:19 lennert's identify works fine with this device and your board? Nov 22 17:57:27 <[g2-jtag]> vmaster, yeah Nov 22 17:58:20 <[g2-jtag]> ./identify_devices Nov 22 17:58:20 <[g2-jtag]> found intel ixp4xx 533 MHz [IR = 7, TCK < 16000000 Hz] Nov 22 17:58:32 <[g2-jtag]> vmaster, that was just run Nov 22 17:58:45 does it work repeatedly? Nov 22 17:58:59 <[g2-jtag]> the identify devices ? Nov 22 17:59:04 yeah Nov 22 17:59:47 <[g2-jtag]> pretty repeatable Nov 22 17:59:58 <[g2-jtag]> I got like 1 or 2 errors in like 25 tries Nov 22 18:00:10 <[g2-jtag]> I think I'm using some older sw too Nov 22 18:00:16 <[g2-jtag]> it's at r 41 Nov 22 18:01:09 the dongle you sent me came with a rather long cable - 10 inches or so - do you happen to have a shorter one to test with? Nov 22 18:02:34 jtag_ntrst_delay 500 Nov 22 18:02:35 jtag_nsrst_delay 500 Nov 22 18:02:59 try adding these two lines to the .cfg - they allow the target to settle after a reset, just in case the reset lines remain asserted too long Nov 22 18:03:51 <[g2-jtag]> vmaster, ok Nov 22 18:04:34 <[g2-jtag]> vmaster, btw identify_devices works like about 98/99 out of 102 times in a row Nov 22 18:05:52 i'll grab something for dinner, be back in 10 minutes Nov 22 18:08:13 <[g2-jtag]> vmaster, ok. THX Nov 22 18:08:44 <[g2-jtag]> with the delays it's slightly different, but same ending result (I can tell the md5sum on log file is different) Nov 22 18:08:55 <[g2-jtag]> but the text initially looks the same Nov 22 18:09:07 <[g2-jtag]> even though I _know_ it's not :) Nov 22 18:09:49 <[g2-jtag]> ok may just a space Nov 22 18:10:22 <[g2-jtag]> 31a32 Nov 22 18:10:22 <[g2-jtag]> > Debug: gw16012.c:363 gw16012_execute_queue(): sleep Nov 22 18:10:22 <[g2-jtag]> 34a36 Nov 22 18:10:22 <[g2-jtag]> > Debug: gw16012.c:363 gw16012_execute_queue(): sleep Nov 22 18:10:28 <[g2-jtag]> two extra sleeps Nov 22 18:13:14 heh, yeah, these are for the two delays Nov 22 18:23:26 ok, there really isn't a lot that's happening up to this point: Nov 22 18:23:31 - both reset lines are pulled low Nov 22 18:23:37 s/low/high/ Nov 22 18:23:37 vmaster meant: - both reset lines are pulled high Nov 22 18:24:06 - 7 tck cycle with tms high are executed Nov 22 18:24:24 - the TAP is moved to Shift-IR Nov 22 18:25:20 - nine 1s are scanned in, expecting to see b110000001 Nov 22 18:25:29 - the TAP is moved back to TLR Nov 22 18:25:54 - both resets are asserted Nov 22 18:25:58 - nTRST is released Nov 22 18:26:26 - a new instruction is scanned in Nov 22 18:26:30 - a DR scan is executed Nov 22 18:27:03 if the validate chain fails you're not getting to the "both resets are asserted" Nov 22 18:27:23 all of these accesses are done with single-bit accesses Nov 22 18:29:02 <[g2-jtag]> vmaster, Ok Nov 22 18:30:27 <[g2-jtag]> vmaster, it sounds like the first TAP Shift-IR isn't working properly Nov 22 18:30:52 when the chain validate fails, yeah Nov 22 18:32:07 <[g2-jtag]> vmaster, so you expect the first Shift-IR to fail ? Nov 22 18:32:21 <[g2-jtag]> or it's ok that it fails ? Nov 22 18:32:40 no, it must not fail Nov 22 18:33:00 19:17 < [g2-jtag]> > Error: jtag.c:1185 jtag_validate_chain(): Error validating JTAG scan chain, IR mismatch, scan returned 0x01ff Nov 22 18:33:01 <[g2-jtag]> right it shouldn't be failing Nov 22 18:33:32 scanning in all 1s means that the TAP didn't reach Shift-IR Nov 22 18:33:43 <[g2-jtag]> ok Nov 22 18:34:01 TDO is High-Z unless the TAP is in Shift-I/DR, the external pull-up gets you all ones Nov 22 18:45:23 http://mmd.ath.cx/openocd/gw16012_debug.patch Nov 22 18:45:54 this adds debug output of every byte sent or received from the dongle Nov 22 18:49:49 <[g2]> Ok patched, built and executed... e-mail on the way Nov 22 18:50:27 thanks Nov 22 18:52:43 <[g2]> vmaster you're the one that needs the thanking :) Nov 22 18:52:48 <[g2]> you're doing all the work Nov 22 19:04:52 ok, everything looks perfectly fine Nov 22 19:05:34 this seems to be an electrical problem Nov 22 19:05:43 you don't happen to have a scope to look at the lines? Nov 22 19:09:15 <[g2-jtag]> unfortunately no :( Nov 22 19:10:12 <[g2-jtag]> there could be some kind of timing issue Nov 22 19:10:29 <[g2-jtag]> as I'm curios how lennerts identify works Nov 22 19:10:36 <[g2-jtag]> lennert's Nov 22 19:15:05 it scans tck with tms high five times (this moves the TAP to TLR no matter what state it was in) Nov 22 19:15:11 then moves to Shift-DR Nov 22 19:15:30 and continously shifts bits through Nov 22 19:16:00 it uses less cycles to move in the TAP, reducing the risk of a failure Nov 22 19:16:56 hey Nov 22 19:17:14 what are you discussing right now? sorry to crash in like that :) Nov 22 19:17:52 any new JTAG TAP developments? Nov 22 19:20:48 <[g2-jtag]> vmaster, Ok so there could be some low-level issues that aren't fully worked out Nov 22 19:21:17 <[g2-jtag]> what lennert is doing is forcing the tap back to a known state and operating from there, correct ? Nov 22 19:21:54 <[g2-jtag]> JMunakra, it's a JTAG dongle for an IXP4xx board Nov 22 19:22:35 [g2-jtag]: yeah, but the OpenOCD does exactly the same Nov 22 19:23:08 <[g2]> vmaster well something is different then :) Nov 22 19:24:05 <[g2]> vmaster the code all looks pretty straight forward Nov 22 19:38:55 I know am off topic but someone has an idea of if it possible ot compile a .exe with gcc (line mingw) but for pocketpc ? Nov 22 19:42:10 http://mmd.ath.cx/openocd/seven_bit_tck_tdi.png Nov 22 19:42:29 that's a capture of a 7-bit transfer using a 100MHz logic analyzer Nov 22 19:42:40 period is exactly 120ns Nov 22 19:42:50 with a 50/50 duty cycle Nov 22 19:43:33 the IXP422 specifies: Nov 22 19:43:41 Tbscl JTAG_TCK low time 50 ns Nov 22 19:43:52 Tbsch JTAG_TCK high time 50 ns Nov 22 19:44:03 Tbsis JTAG_TDI, JTAG_TMS setup time to rising edge of JTAG_TCK 10 ns Nov 22 19:44:44 Tbsih JTAG_TDI, JTAG_TMS hold time from rising edge of JTAG_TCK 10 ns Nov 22 19:45:08 the GW dongle might be pusing this to the limits Nov 22 19:52:55 <[g2-jtag]> vmaster nice capture! Nov 22 19:53:05 <[g2-jtag]> so you'd like to see a shorter cable ? Nov 22 19:54:00 that could help Nov 22 19:54:08 it did improve things here Nov 22 19:54:33 moving from 10 inches to about 4-5 Nov 22 20:08:40 <[g2]> vmaster I don't have any other 14-pin cables Nov 22 20:29:12 <[g2]> vmaster THX for all the help. I'll have to play around with the SW a little and look for a shorter cable or maybe buy one Nov 22 20:31:24 [g2]: I just noticed that even if you get past the comms problems you'll run into a bug. For XScale, I have to add support for the "pathmove" jtag command to the GW16012 - that's only a matter of a few minutes, but i completely forgot about it Nov 22 20:31:57 you'll get an "ERROR("BUG: unknown JTAG command type encountered");" when you hit this problem Nov 22 20:32:13 <[g2]> vmaster ok. thx for the heads-up Nov 22 20:32:28 i'm about to leave, but i'll add this first thing tomorrow Nov 22 20:32:54 <[g2]> that'll probably be before I get my cable/comms sorted out :) Nov 22 20:33:07 <[g2]> but THX for all the help and work! Nov 22 20:33:39 thanks for being patient enough to test thist stuff Nov 22 20:33:48 s/thist/this/ Nov 22 20:33:49 vmaster meant: thanks for being patient enough to test this stuff Nov 22 20:35:19 <[g2]> well I guess one needs to be careful what we ask for :) I wanted a high-speed JTAG device and now I've got one :) Nov 22 20:38:52 * nbd thinks this stuff is way cool Nov 22 20:42:04 <[g2]> nbd JTAG ? Nov 22 20:42:49 yes, and having decent free software to use it :) Nov 22 20:54:03 <[g2-build]> nod :) Nov 22 20:54:11 <[g2-build]> ~praise vmaster Nov 22 20:54:19 All hail vmaster! **** ENDING LOGGING AT Thu Nov 23 02:59:57 2006