Rick Altherr wrote: > > On Dec 18, 2008, at 12:32 PM, Kees Jongenburger wrote: > >> On Wed, Dec 17, 2008 at 6:49 PM, Rick Altherr <[email protected]> wrote: >> >>> On Dec 17, 2008, at 9:06 AM, Dirk Behme wrote: >>> >>>> Before I can think about further testing or help, I'd like to be on a >>>> confirmed status level. >>> >>> I believe the best status anyone has encountered is: the BeagleBoard >>> boots >>> and OpenOCD sees the Flyswatter. There is no success in setting up >>> the JTAG >>> chain. >> >> >> I believe the current svn version simply has some problems with the >> flyswatter. but >> the status is/was a follow. >> > > I do not know of any issues with the Flyswatter in SVN trunk. I will > validate it against a known target just to be sure. > >> We where able to at least connect to the jrc (using booth the >> flyswatter and jtagkey-tiny). >> Dave apparently has had more luck hacking and was able to enabled the >> DAP as some point. >> >> >> ke...@ijssijs:~/projects/beagle/openocd$ make >> sudo openocd >> Open On-Chip Debugger 1.0 (2008-07-04-09:01) svn:738M >> $URL: http://svn.berlios.de/svnroot/repos/openocd/trunk/src/ openocd.c $ >> Info: options.c:50 configuration_output_handler(): jtag_speed: 1, 1 >> Info: jtag.c:1389 jtag_examine_chain(): JTAG device found: >> 0x0b7ae02f (Manufacturer: 0x017, Part: 0xb7ae, Version: 0x0) > > I can get this far too, but it doesn't make me very excited.
Rick: How do you get this? Do you like to share the details with people being a little more excited about this? I.e. me ;) > My > attempts to interact with the JRC via the irscan and drscan commands > have been less than stellar. I have determined that when the omap3530 > is reset, the JRC is the only tap in the JTAG chain. It appears that > from a reset, irscan and drscan have some rather odd behavior. > > Specifically, openocd sets the endstate to RESET by default so a reset > of the board should leave the JTAG interface in the same state the > OpenOCD is expecting. The first JTAG scan, either ir or dr, after a > board reset always returns all 1s. Subsequent scans _appear_ to work > correctly, but the returned values are odd. For example: > > - Board reset > - irscan 0 1 -> fails the capture check as the returned value is all 1s > - irscan 0 1 -> succeeds > - drscan 0 32 0 -> returns 0x00000000 > - drscan 0 32 1 -> returns 0x00000002 > > If IR capture for ID is really 0x1, this doesn't make any sense. I > also have no idea why any other drscan to irscan 1 just returns the > supplied value shifted left one place. Another example: > > - Board reset > - irscan 0 1 -> fails the capture check with all 1s > - drscan 0 32 0 -> 0x0b7ae02f > - irscan 0 1 -> success > - drscan 0 32 0 -> 0 > > > I still don't have the JRC documentation, so I've mainly been stabbing > in the dark, Jason: Sorry, but I will not stop CCing you until we have this working ;) Best regards Dirk > but so far I'm just _really_ confused. I would really > appreciate if anyone who has said document could forward it along. > I'll attempt to verify that my flyswatter does work against a LM3S6959 > target tomorrow just to make sure I'm not running into an interface > related bug but my investigations in that direction have turned up > nothing. If it comes down to it, I'll dig out the logic analyzer and > see what is being sent back and forth. > > -- > Rick Altherr > [email protected] > > "He said he hadn't had a byte in three days. I had a short, so I split > it with him." > -- Unsigned > > > _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
