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 aI believe the best status anyone has encountered is: the BeagleBoard boots and OpenOCD sees the Flyswatter. There is no success in setting up the JTAGconfirmed status level.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. 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 0x00000002If 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 -> 0I still don't have the JRC documentation, so I've mainly been stabbing in the dark, 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
