Michael Bruck wrote: > On Thu, May 21, 2009 at 1:39 PM, Dirk Behme <[email protected]> wrote: >> Michael 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.cfg > > Did you issue any commands before that happened in addition to what is > in 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 then openocd -s lib/openocd/ -f interface/dummy.cfg -f board/ti_beagleboard.cfg This 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 IDCODE Error: 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 3 Warn : 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 -- >>> Given that this is only an assert >> Well, at least OpenOCD stopped here, so it might be more that 'only' an >> assert ;) 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 the > errors can be both in the code and in user commands and for the latter > assert() 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 _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
