On Thu, May 7, 2009 at 6:38 PM, David Brownell <davi...@pacbell.net> wrote:
> One of the patches since the merge of the ti_dm355.cfg line-end
> update seems to have broken some aspect of scan chain discovery.
> See the openocd server startup transcript below, with "scan_chain"
> command debug output. (FWIW, using with an Olimex ft2232 adapter.)
>
> The recent TAP changes forced a slowdown from 3 MHz to 1.5 MHz;
> "why" is unclear to me, but the failure mode was similar: it
> found just the last of the three TAPs listed (i.e. the one that
> is hooked up right next to TDI on the SoC).
Indeed , specially when using the open ftdi driver the long scan chain
discovery 640 bits
does not succed. the problem is to be found in the ft2232.c (I think)
This part of the code does some strange assumptions about the timeout
. This timeout is also decreased every time and the ftdi_read_data
apparently doesn't wait long enough
for new data then the speed it to low
int retval;
int timeout = 100;
*bytes_read = 0;
while ( (*bytes_read < size) && timeout-- )
{
if ( ( retval = ftdi_read_data(&ftdic, buf +
*bytes_read, size - *bytes_read) ) < 0 )
{
*bytes_read = 0;
LOG_ERROR( "ftdi_read_data: %s",
ftdi_get_error_string(&ftdic) );
return ERROR_JTAG_DEVICE_ERROR;
}
*bytes_read += retval;
}
>
> Which suggested a potential workaround here: slow TCK down even
> more. Sure enough, at 750 KHz the startup doesn't fail...
>
> I'm hoping that this recent trend of needing to halve the clock
> rate after each "svn up" can be halted and then reversed. There
> would seem to be some hard limits coming up soon ... ;)
>
> - Dave
>
>
> ================
>
> Open On-Chip Debugger 0.2.0-in-development (2009-05-07-08:37) svn:1649
>
>
> BUGS? Read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS
>
>
> $URL: svn://svn.berlios.de/openocd/trunk/src/openocd.c $
> 1500 kHz
> use of EmbeddedICE dbgrq instead of breakpoint for target halt enabled
> fast memory access is enabled
> dcc downloads are enabled
> Info : JTAG tap: dm355.etb tap/device found: 0x0b73b02f (Manufacturer: 0x017,
> Part: 0xb73b, Version: 0x0)
> Error: JTAG tap: dm355.etb got: 0x0b73b02f (mfg: 0x017, part:
> 0xb73b, ver: 0x0)
> Error: JTAG tap: dm355.etb expected 1 of 1: 0x2b900f0f (mfg: 0x787, part:
> 0xb900, ver: 0x2)
> Error: trying to validate configured JTAG chain anyway...
> Error: Could not validate JTAG scan chain, IR mismatch, scan returned 0xFFC1.
> tap=dm355.arm pos=4 expected 0x1 got 0
> Warn : Could not validate JTAG chain, continuing anyway...
> Warn : TAP dm355.arm:
> Warn : value captured during scan didn't pass the requested check:
> Warn : captured: 0x0C check_value: 0x01 check_mask: 0x0F
> Warn : in_handler: w/o "in_value", mismatch in SIR
> Warn : TAP dm355.arm:
> Warn : value captured during scan didn't pass the requested check:
> Warn : captured: 0x0C check_value: 0x01 check_mask: 0x0F
> Warn : in_handler: w/o "in_value", mismatch in SIR
> Warn : no telnet port specified, using default port 4444
> Info : accepting 'telnet' connection from 0
> TapName | Enabled | IdCode Expected IrLen IrCap
> IrMask Instr
> ---|--------------------|---------|------------|------------|------|------|------|---------
> 0 | dm355.etb | Y | 0x0b73b02f | 0x2b900f0f | 0x04 | 0x01 |
> 0x0f | 0x0f
> 1 | dm355.arm | Y | 0x00000000 | 0x07926001 | 0x04 | 0x01 |
> 0x0f | 0x0c
> 2 | dm355.jrc | Y | 0x00000000 | 0x0b73b02f | 0x06 | 0x01 |
> 0x3f | 0x3f
> _______________________________________________
> Openocd-development mailing list
> Openocd-development@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/openocd-development
>
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
