On Wednesday 13 May 2009, Øyvind Harboe wrote:
> On Wed, May 13, 2009 at 11:01 PM, Nicolas Pitre <n...@cam.org> wrote:
> > On Wed, 13 May 2009, David Brownell wrote:
> >
> >> When I tried "-d 3" it suddenly worked, and has worked
> >> again since. Note -- this is with *NO* rebuild, and
> >> using an executable which previously failed.
> >
> > This is scary. Anyone with valgrind skills?
If my theory about external state not getting fully reset
is correct, valgrind wouldn't show anything relevant...
> I notice the "icepick". Is that one of the JTAG routing devices?
Yes, that's TI's name for those modules(*) ... I hear
there's some IEEE standard in this area, but don't know
if that standard matches what ICEpick implements.
> Could it be enabling/disabling devices in the chain?
No; it doesn't work like OMAP3. On the DaVinci chips,
if the EMU0/EMU1 signals are grounded they come up in
a "debug scan chain" where you don't need to poke the
ICEpick to make it include the ARM core. I've jumpered
those low, to avoid needing poke-the-ICEpick logic.
If the EMU0/EMU1 signals were pulled high, it comes up
like the OMAP3 on Beagleboard: ICEpick only, which you
make link in other things (Cortex-A8, C64x+ DSP, etc).
But that's not happening here; those signals pull low.
- Dave
(*) My understinding is that ICEpick v3 started out on
DaVinci, and was then later adopted in OMAP3 along
with the C64x+ DSP and some video hardware.
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
