**** BEGIN LOGGING AT Sat Feb 28 02:59:58 2009 Feb 28 13:37:05 cosmetic openocd patch: http://pastebin.com/f69a3276f Feb 28 13:38:55 sn9: are you on the dev list? Feb 28 13:57:27 keesj: i don't remember offhand; if i am, it's set to nomail Feb 28 16:57:33 L_Deluxe: hi Feb 28 16:57:53 sn9: Um, hi. Feb 28 16:58:10 Bot? Feb 28 16:58:29 nope Feb 28 16:58:34 k Feb 28 17:01:12 Hello, I'm trying to get my olimex jtag arm usb to work with my custom lpc2129-based board using openOCD. I'm using openOCD 0.1.0 on windows. Feb 28 17:02:22 However after I specify the interface and target config file to openOCD, none of the ports (for gdb and telnet) are open. I checked that by trying to telnet and using netstat Feb 28 17:03:01 Any help to fix this issue will be appreciated! Anyone there!? Feb 28 17:55:46 to repeat: cosmetic openocd patch: http://pastebin.com/f69a3276f Feb 28 18:20:25 sn9: looks OK. Did you post it to the list? It's much more likely not to be missed than posting it here Feb 28 18:22:03 Has anyone successfully used openocd with an IXP4xx processor, with any adapter other than an Olimex? I seem to have the same fault on 2 boards, with two different adapters. Feb 28 18:32:38 noz: will post it in a couple of minutes Feb 28 18:50:36 you should post is as an attachment Feb 28 18:51:02 as in, repost? Feb 28 18:51:36 i would have thought everyone has wget Feb 28 18:51:45 well, i guess you could wait for reaction from a maintainer, but it's likely they will say that Feb 28 18:53:03 if you want it to be commited to svn, that is Feb 28 19:02:59 noz, roxfan: http://lists.berlios.de/pipermail/openocd-development/2009-February/004812.html Feb 28 19:05:27 noz: your issue might have something to do with a gcc warning compiling xscale.c Feb 28 19:06:28 i said attachment :) dunno why but their workflow seems to have problems with inlines Feb 28 19:07:09 * sn9 facepalms Feb 28 19:56:08 sn9: I'm at svn HEAD, and I don't get any warnings compiling xscale.c Feb 28 19:56:51 gcc (Debian 4.3.2-1.1) 4.3.2 Feb 28 19:58:37 oh. using 4.2.2 on ubuntu here Feb 28 22:22:13 Have pinpointed the point which differs between Olimex and J-Link adapters on resetting IXP422. Anyone want to help track down the cause? Feb 28 22:23:58 "the point" ? Feb 28 22:24:32 I have a trace (from johnrw) of his Olimex doing a reset on the IXP422 (which works) Feb 28 22:24:53 I have a trace of my J-Link doing the same reset (which doesn't work). Feb 28 22:25:02 do you have the same device? Feb 28 22:25:10 (target board) Feb 28 22:25:21 We think so - USR8200 with A0 step IXP422 Feb 28 22:26:18 do you have schematics for both adapters? Feb 28 22:26:38 Yep - same JTAG ID: 0x09277013 Feb 28 22:27:22 No schematics. The point is they get almost there, but fail after loading the MiniIC, and in trying to read the TX register Feb 28 22:27:26 well, different boards can still have the same jtag id Feb 28 22:27:46 Sure, but they are the same board as far as we can tell Feb 28 22:28:08 I know it would be preferable to do comparison on the same physical h/w, but this is second best Feb 28 22:28:23 i think i saw olimex schematics somewhere on the web Feb 28 22:29:26 I don't think it's a schematic-level thing. I think it's much deeper. Most of the JTAG interaction works, well beyond the point that it would fail if there was an adapter flaw in the h/w Feb 28 22:29:50 I think it's down to the openocd drivers for the different adapters. Feb 28 22:30:15 if you have schematics, they can be compared against what the driver does Feb 28 22:31:30 that's why it took me less than 10 minutes to perfect the flyswatter patch after getting the idea Feb 28 22:31:32 After reset, and loading the MiniIC, both successfully set DCSR, but then the Olimex reads TX, but the J-Link doesn't Feb 28 22:31:55 How so - this is about interaction with the processor internals? Feb 28 22:32:43 if the driver tells the adapter to reset in a manner inconsistent with its wiring, it can cause the symptom you describe Feb 28 22:35:30 Hmmm. Even though after reset, both adapters are doing several 10s of transfers correctly before they differ? Feb 28 22:36:04 oh? then it's likely cabling Feb 28 22:36:29 How so? Feb 28 22:37:08 The J-link works fine on other boards, and it's not the only adapter to have problems with the IXP422 Feb 28 22:37:26 is it the only xscale board you have? Feb 28 22:37:28 Maybe I should back up a bit, and explain what I've done so far? Feb 28 22:37:55 I have 2, both USR8200, one with IXP422 A0, one with IXP422 B0 stepping Feb 28 22:38:27 I have tried with both USBprog and J-Link adapters, with the same result Feb 28 22:38:47 does the B0 work? Feb 28 22:39:12 No. Feb 28 22:39:30 Identical JTAG behaviour Feb 28 22:39:55 are you wiring both reset signals to the board? Feb 28 22:39:59 Yes. Feb 28 22:40:12 using the same config as johnrw? Feb 28 22:40:51 Not quite. I suppose I could try to make the configs as similar as possible. I'm starting with a minimal config Feb 28 22:41:19 you might have different reset_config lines Feb 28 22:42:13 the work area setup may also make a difference Feb 28 22:43:02 Hang on - I'll check Feb 28 22:44:21 additionally, he has previously stated that he uses a pretty old revision of openocd and sees no reason to upgrade Feb 28 22:45:37 No - this test was with r1370, mine on HEAD (r1382) Feb 28 22:47:38 interesting -- the r1378 bugfix is his Feb 28 22:49:01 The diffs between our configs are: my nsrst_delay is 400, his 200. He has jtag_speed 16, I have none. I have a work area set, he doesn't. The rest of the diffs are irrelevant (I think) Feb 28 22:49:51 None of r1370-r1382 affect either adapter AFAICT Feb 28 22:50:37 I'll try with jtag_speed 16 and nsrst_delay = 200 if you like. Feb 28 22:50:38 try changing those three things in your config Feb 28 22:50:52 turn off the work area, too Feb 28 22:52:34 OK. Fails at exactly the same point. Feb 28 22:53:41 (Although the value read in is slightly different. The fields[0].in_value[3] was 5 before, now 0 Feb 28 22:56:29 I think the JTAG state sequence must be wrong, because the check is failing on the 3 trailing bits of reading TX, which should be hardwired as 0 1 x, and checked to be 2 after being masked by 6 Feb 28 22:56:48 sounds likely Feb 28 22:57:04 They are being read as 5 or 0, which is plain wrong, and couldn't happen if the same state sequence was being traversed Feb 28 23:02:08 http://www.padded-cell.net/noz/olimex-jlink.diff is the debug output around the place it differs Feb 28 23:02:53 I was just starting to try to work out the path through the code.... Feb 28 23:51:23 hi Feb 28 23:58:47 mwalle: hi Mar 01 00:01:25 i'm writing a openocd driver for the xilinx platform cable (usb) Mar 01 00:02:13 however, i own a starterkit 3e with a builtin dongle Mar 01 00:02:20 (not a real standalone xpc) Mar 01 00:03:10 that builtin dongle has neither srst not trst Mar 01 00:05:34 will openocd do a soft reset (that is sending five tms=1) if i set reset_config to none ? Mar 01 00:06:14 Intuition tells me yes, but I don't know for sure, so I'm hesitant to declare it. Mar 01 00:07:57 it will do a soft trst, but not a soft srst Mar 01 00:11:00 Ooh. Right. Mar 01 00:12:08 well srst is hardly possible without knowing how to reset it in software :) Mar 01 00:15:18 but should my driver implement the reset command by doing a soft reset, or is it intented to toggle the trst pin? Mar 01 00:16:03 i looked at the other dongle drivers, but all have support for hardware pins ;( Mar 01 00:17:32 Dongle drivers support hardware pins where they can. It is up to the rest of openocd to use those or shift out extra ones. Mar 01 00:18:19 ok Mar 01 00:28:32 yippie 2270210 shifts in 1s 363368us :) Mar 01 00:28:53 well.. is that fast? Mar 01 00:29:46 i can only compare it to my previous gpio driver, which took about 600s Mar 01 00:30:02 Well, then, in that comparison, it appears to be fast. Mar 01 00:30:10 ;) Mar 01 00:30:51 Simple math works out to 1.66 MHz. Mar 01 00:32:10 at least the average Mar 01 00:32:49 Well, yeah. Says nothing about peaks. Mar 01 00:34:37 do you know what tclk the usbprog can archieve? Mar 01 00:35:21 (without sampling tdo) Mar 01 00:37:47 btw openocd dont support flashes by toggling boundary scan capable pins, do it? Mar 01 00:40:10 I don't know about usbprog. The only dongle driver I've really had my head in is rlink. And ft2232 can do up to 6, I think. Mar 01 00:41:12 Flashing happens through debug unit in the target. Mar 01 00:41:23 Not by exercising boundary scan pins. Mar 01 00:41:44 ok thanks Mar 01 00:42:17 Though if you've got bare FLASH on the JTAG chain, it may be possible to do it that way. Mar 01 00:42:45 Not for internal FLASH in something like an STM32 or SAM. Mar 01 00:44:11 yeah, but for external flash. eeprom etc one would be independent of a specific chip Mar 01 00:45:01 though it is very slow Mar 01 00:45:47 Yes. I haven't done that. My work so far is just small embedded ARMs. Mar 01 00:45:56 With only the internal FLASH. Mar 01 00:49:40 urjtag can do flashing via boundary scan Mar 01 00:53:11 btw what is rtck? Mar 01 01:27:57 return tck Mar 01 01:34:05 hm? Mar 01 01:35:10 rtck Mar 01 01:35:31 yeah, but what means 'return tck' ? Mar 01 01:36:04 tck is fed to the device. the device feeds its receipt of the signal back Mar 01 01:37:15 it's used to detect framing errors Mar 01 01:37:24 ah ok Mar 01 01:38:20 have to go to bed, cya tomorrow **** ENDING LOGGING AT Sun Mar 01 02:59:57 2009