On May 21, 2009, at 10:13 AM, Dirk Behme wrote:
Michael Bruck wrote:On Thu, May 21, 2009 at 1:39 PM, Dirk Behme <[email protected] > wrote:Did you issue any commands before that happened in addition to what isMichael Bruck wrote:Dirk, did this happen when you used the drscan/irscan commands?Not sure, but possible. Have a look to tap-enable event of http://svn.berlios.de/svnroot/repos/openocd/trunk/src/target/target/omap3530.cfgin the config files ? Can you send a log with debug_level 3 ? Does your system produce a .stackdump file during the assert/crash that you can send ? Does the assert happen if you disable the irscan/drscan commands in omap3530.cfg ?If you like you can try it your own: Configure recent trunk (1875) with --enable-dummy and thenopenocd -s lib/openocd/ -f interface/dummy.cfg -f board/ ti_beagleboard.cfgThis will result in -- cut -- Open On-Chip Debugger 0.2.0-in-development (2009-05-21-19:06) svn:1875 BUGS? Read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS $URL: svn://svn.berlios.de/openocd/trunk/src/openocd.c $ Warn : JTAG command queued, while TRST is low (TAP in reset) current endstate: RUN/IDLE Warn : Tap/Device does not have IDCODEError: JTAG tap: omap3.jrc got: 0x00000000 (mfg: 0x000, part: 0x0000, ver: 0x0) Error: JTAG tap: omap3.jrc expected 1 of 1: 0x0b7ae02f (mfg: 0x017, part: 0xb7ae, ver: 0x0)Error: trying to validate configured JTAG chain anyway...Error: Could not validate JTAG scan chain, IR mismatch, scan returned 0xFF. tap=omap3.jrc pos=0 expected 0x1 got 3Warn : Could not validate JTAG chain, continuing anyway...openocd: jtag.c:889: interface_jtag_add_dr_scan: Assertion `field == out_fields + scan->num_fields' failed.-- cut --Well, at least OpenOCD stopped here, so it might be more that 'only' anGiven that this is only an assertassert ;) As mentioned, with r1865 it still worked.The assert highlights that superfluous data was passed while older versions ignored that condition. This change was deliberate to track down errors like the one you seem to have. The problem is that theerrors can be both in the code and in user commands and for the latterassert() isn't informative enough and irscan/drscan should inspect their input data more closely.Would have been nice before making this change in public svn it would have been tested with all available configurations.Best regards Dirk
While I agree with the sentiment, there is a practical limit on this. No one owns all of the targets or has time to do that. Patches submitted to the list rarely get tested by more than 2 or 3 people. The only way we get full testing is by committing to trunk. With no real stable releases for users, this leads to a fair amount of frustration when trunk behaves badly (doesn't currently build on OSX, assertions firing to name a few as of right now). Once 0.2.0 is out the door, we'll be doing more frequent stable releases so that only developers of OpenOCD are living on trunk.
-- 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
