Re: [Openocd-development] openocd on ixp425 failing "load"

[Dominic R. <Dom...@gm...>]

Hello Greg,

On Friday 30 March 2007 08:27, Greg Ungerer wrote:
> Hi
>
> Dominic Rath wrote:
>  > I've merged the XScale support into mainline just yesterday.
>  > It would be nice if you could try again using the code from /trunk,
>  > as it contains several improvements to the generic code, including
>  > JTAG.
>
> Ok, tried this. It didn't go so well.
>
> First up openocd startup failed with:
>
>   Debug:   jtag.c:1335 jtag_init(): -
>   Debug:   ft2232.c:1246 ft2232_init(): 'ft2232' interface using libftdi
> with 'jtagkey' layout
>   Error:   ft2232.c:1352 ft2232_init(): unable to open ftdi device:
> device not found
>
> So I quickly edited the src/jtag/ft2232.c ftdi_init() call to make it
> the same as in the xscale branch. So changed the call to
> ftdi_usb_open_desc/ftdi_set_interface with just a call to ftdi_usb_open().
> It got further, but then I couldn't connect with gdb - it would just
> hang on the target connection.
>
> That was still using the libftdi driver...
>
The trunk code contains changes to the FT2232 initialization that improve 
stability - you shouldn't remove these. I guess the device wasn't found 
because of a problem with your cfg file - I'll have a look at it if you send 
it to me.

>  > Libftdi is a likely candidate for causing issues. I've seen problems
>  > with buffers growing too large for libftdi to handle - this might be the
>  > issue you're running into. You could try decreasing the size of
>  > #define FT2232_BUFFER_SIZE    131072
>  > at jtag.c:137.
>
> Changing FT2232_BUFFER_SIZE didn't seem to make any difference.
>
You'd probably have to reduce it to something like 4096 or 8192 to see a 
positive effect.

>  > If this doesn't help try the (binary only) FTD2XX driver from
>  > FTDI.
>
> Yep, that did it. It works with the ftd2xx driver.
>
Ok. While the binary only FTD2XX isn't an ideal solution it's the best option 
we've currently got.

> I went back and retried the trunk code again, now with the ftd2xx
> driver, and it still hangs when I try to "target" it from gdb.
> The last trace in the log file is:
>
>   Debug:   gdb_server.c:1347 gdb_init(): gdb service for target xscale
> at port 8888
>   Debug:   xscale.c:1178 xscale_halt(): target->state: reset
>   Debug:   xscale.c:1193 xscale_halt(): target->state == TARGET_RESET
>   Debug:   jtag.c:278 jtag_call_event_callbacks(): jtag event: SRST
> released Debug:   jtag.c:1126 jtag_reset_callback(): -
>   Debug:   xscale.c:1178 xscale_halt(): target->state: reset
>   Debug:   xscale.c:1193 xscale_halt(): target->state == TARGET_RESET
>   Debug:   jtag.c:278 jtag_call_event_callbacks(): jtag event: SRST
> released Debug:   jtag.c:1126 jtag_reset_callback(): -
>
I'll see if I can reproduce this here, but my PXA250 board (the only XScale 
device that I've got) seems to be less criticial then newer XScale devices.

> Now moving on some more :-)
>
> If I try to set the "PC" using strait gdb commands, say with
>
>     set $pc = 0x10000000
>
> then I get errors like:
>
>     Cannot access memory at address 0xe3a011fc
>
Could you send me an OpenOCD log file (run with -d -l <logfile>) and a dump 
from your GDB session?

> I can set it using "monitor reg pc 0x10000000", and that seems
> to work ok. Though if I try to single step code (using "monitor
> step") then I get errors like:
>
>      Reply contains invalid hex digit 84
>
You must never use commands that change the target state from running to halt 
(or vice versa) while a GDB session is connected. There's no way to inform 
the GDB about these state changes.

> Is this related to the xscale debug_handler?
> (Which I don't have set in my current config file).
>
The default setting should be fine.

> Regards
> Greg

Regards,

Dominic