Hmm, this is quite squirrely. I had done a "make clean" then rebuilt before reporting the failures ... but a build which previously failed, has just started to work.
On Wednesday 13 May 2009, Øyvind Harboe wrote: > > Current GIT head no longer starts up correctly on dm355. > > It should find three TAPs: ICEpick, ARM926ejs, ETB11. > > But it only finds one. (Using an Olimex ft2232 adapter.) > > > > New symptoms compared to previous incarnations of this: > > > > (a) slowing JTAG clock doesn't help. > > (b) it sees the *second* device (ARM926ejs) not first. > > > > Bisection is futile since most of the intermediate checkins > > don't build on x86_64. > > JTAG enumeration is one of the things I *really* did not > expect to be affected by any recent work. Maybe it wasn't. I reported flakiness there before too. - One theory is that the build procedure sometimes leaves crap around. That wouldn't quite explain everything, but I see such goofs often enough to think this might be a contributing problem. - Another might be that the ft2232 or JTAG code isn't robustly initializing ... so it's inheriting some external state that it shouldn't, and getting confused. I think the second is most likely. I do remember poking at the device with "urjtag" to see if it could detect things properly ... yes. (And at 3 MHz, while OpenOCD can't go faster than 1.5 MHz.) Presumably it did some things differently. Maybe the "openocd -d3" did too. > Does 1606 work? > > Please provide details on how you invoke OpenOCD + > debug_level 3 logs. 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. - Dave _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
