Zach Welch wrote: > On Sat, 2009-04-18 at 06:31 -0500, Dick Hollenbeck wrote: > >> 1) >> I would like to see tap_set_state() called for ALL state changes, not >> just the end points of of a multi-state path move. This way when >> logging is compiled ON, we can see what each driver is doing (more >> exactly, what it thinks it is doing) to the taps. The importance of >> this comes into play when programming FPGAs and CPLDs and >> troubleshooting that process. >> > > It sounds like this could be accomplished as an independent patch, yes? >
Well, since this needs to be done for each driver, I think it could be a matter of getting a reference implementation in place, then the other drivers would have to sprinkle in the calls to tap_set_state() as needed. But there may be some jtag***() functions where this can be done in a common way, like the path move, etc. It will have to be looked into. > >> 2) >> Have a look at ft2232.c which I can get to seg fault and also to get >> into a mode from which it does not recover simply by disconnecting the >> cable. It is not robust. >> > > Have you posted a backtrace for the crash? I just looked back and was > unable to find one since Feb. > I never posted it. When the SVF and XSVF functions call the jtag routines, they can push those underlying jtag routines in directions that they don't normally travel. There was a case where if a bitcount exceeded some number, then ft2232.c would seg fault. I know where the bug is, and have been planning on dealing with it. That limit is not normally hit with the bulk of the code in OpenOCD. A hint as to the fix to the problem is in my add_clocks function ft2232.c. The overflow condition has to be checked for *within* the loop, basically. I'm not staring at the code now, but that's what I remember. Dick _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
