On Sat, Apr 17, 2010 at 9:40 AM, Øyvind Harboe <oyvind.har...@zylin.com> wrote: > You have found an interesting case here indeed. > > As a principle it should be possible to connect via GDB regardless > of the target state. > > Since that state, in general, can include a case where the target's > flash is not probable and we need the flash layout upon connection, > I think we need a more general solution than the one you have below. > Also, I think it is good, in general, to require the target to be halted > before the flash is probed GDB aside.
Well, many targets DO need to be halted to be able to probe the flash and I agree that it would be nice with a solution to the GDB connect problem in the general case. However, I don't see how it helps to impose artificial restrictions to targets/flash drivers that are free from such limitations. I believe such restrictions should be removed, regardless of any general solution. Besides, if we for some reason would want the target to always be halted before a flash probe, shouldn't that be enforced in the generic flash layer instead of in each individual driver? > I would like a robust and simple solution. This is not a common problem, > it is the first time that it has been spotted. A solution that made the > general > case harder would not be desirable. I don't know, I somehow recall previous reports of this kind of problem, earlier than Freddie's. And I suspect there's a vast number of problems like this that never get reported, since people are historically used to having random glitches and occasional malfunction. Restarting GDB/OpenOCD is easier than reporting the bug. For sure it's been a long-standing major annoyance at work with those once-in-a-while failed loads. I just haven't found a cause until now (there may be other as well). > Did you consider adding target config script code to a pre connect > GDB event? > > Such an event could reset init the target if the flash is not probe-able. I did consider, but refrained for three reasons: 1. I couldn't find a reference to the available hooks in the documentation, and I don't know them by heart. I'm sure I just didn't look hard enough. 2. That would be somewhat of a workaround and I'd much rather see a fix for the underlying problem. 3. It would probably make it impossible to connect to a running target without stopping it, for the cases where it is desired. This may be a good solution for targets which are impossible to probe in the running state. Other targets shouldn't need it. -- Andreas _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
