Rick Altherr wrote: > > > Sent from my iPhone > > On Dec 22, 2008, at 11:57 AM, Dirk Behme <[email protected]> > wrote: > >> Rick Altherr wrote: >> >>> On Dec 19, 2008, at 12:25 PM, Dirk Behme wrote: >>> >>>> * Thanks to Dave, Rick and I got the "TI doc" now. >>>> >>> And it has raised more questions. >>> >>>> * I now get >>>> >>>> -- cut -- >>>> > openocd -s lib/openocd/ >>>> Open On-Chip Debugger 1.0 (2008-12-19-17:38) svn:1261 >>>> >>>> BUGS? Read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS >>>> >>>> $URL: svn://svn.berlios.de/openocd/trunk/src/openocd.c $ >>>> jtag_speed: 1 >>>> Info: JTAG tap: omap3530.jrc tap/device found: 0x0b7ae02f >>>> (Manufacturer: 0x017, Part: 0xb7ae, Version: 0x0) >>>> Info: JTAG Tap/device matched >>>> Warning:no gdb ports allocated as no target has been specified >>>> Warning:no tcl port specified, using default port 6666 >>>> -- cut -- >>>> >>>> This is with Flyswatter, TinCanTools' adapter and BeagleBoard. I >>>> think this shows that recent svn works with Flyswatter :) >>>> >>> At least one piece of the puzzle is filled in. After a reset, the >>> JRC needs 10 TCK pulses to wake up the JTAG power domain. So, the >>> first DRSCAN returning 0xffffffff and the first IRSCAN seemingly >>> having no effect after a reset is because the hardware turns on >>> partway through the state machine. I think we can address this in >>> the config fairly easily. >> >> >> Does this "waiting 10 TCK fairly easily" mean there is already a >> command to wait 10 TCK or does this mean it can easily implemented/ >> added? >> > > I believe it can be added. Things like runtest attempt to move in the > state machine which cannot be done until the power domain is up. We > need a way to force 10 TCK ticks with no other pin changes or internal > state moves.
So we need a "10 TCK ticks with no other pin changes or internal state moves" replacement command for "runtest 10" in script below? This has to be written, and the link https://lists.berlios.de/pipermail/openocd-development/2008-December/004161.html Øyvind gave could help with this? >> I'm thinking about adding something like >> >> jtag_reset >> wait 10 TCK >> >> to omap3530.cfg script. E.g. >> >> jtag configure $_CHIPNAME.cpu -event tap-enable { >> puts "Enabling Cortex-A8 @ OMAP3" >> => jtag_reset >> => wait 10 TCK >> irscan omap3530.jrc 7 >> drscan omap3530.jrc 8 0x89 >> irscan omap3530.jrc 2 >> drscan omap3530.jrc 32 0x81000080 >> drscan omap3530.jrc 32 0xa3002048 >> drscan omap3530.jrc 32 0x81002148 Is this a copy/paste error and it should be 0x81000081 instead? >>> The good news is that we can _possibly_ bring up the DAP and not >>> attempt a second chain examination. It means the output of >>> scan_chain will be wrong in some ways, but at the very least, we >>> should be able to manually query the DAP. If nothing else, being >>> able to talk to the DAP means that development on Cortex-A8 target >>> support can start even if the JRC isn't behaving perfectly. >> >> >> How would I do "we should be able to manually query the DAP"? I.e. >> how would I verify that I can talk to the DAP if second scan_chain >> "doesn't work"? >> > > scan_chain only shows OpenOCDs internal knowledge of the chain. ok. > In this > case, it knows that the DAP is enabled, but it did not retrieve the > idcode. Manually running irscan and drscan to retreive the idcode would > prove the DAP is enabled. Could you give some irscan and drscan commands to do this? Additionally, giving the irscan and drscan (?) commands to read JRC IdCode shown by scan_chain would help to better understand/learn. >> Currently, I get >> >> -- cut -- >> > scan_chain >> TapName | Enabled | IdCode Expected IrLen >> IrCap IrMask Instr >> --- |-- --- --- --- --- --- >> ---|---------|------------|------------|------|------|------|--------- >> 0 | omap3530.jrc | Y | 0x0b7ae02f | 0x0b7ae02f | 0x06 | >> 0x01 | 0x0f | 0x3f >> 1 | omap3530.cpu | n | 0x00000000 | 0xffffffff | 0x04 | >> 0x01 | 0x00 | 0x0f Many thanks and best regards Dirk Btw.: Anybody sometimes at #openjtag IRC to discuss stuff like this? _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
