Hi Paul and others I finally understand why OpenOCD is so prone to lock in target-cannot-be-reset state.
Polling is off during reset processing. Let say DP initialization fails for whatever reason. Reset process fails leaving poll off and target in not examined state. Poll is able to resolve most of out-of-sync states. But I don't think it is good idea to force poll on after reset failure. The problem in reset process might be serious and OpenOCD should expose it to user, not hide it by regaining sync in poll. So poll is off and ordinary user retries reset. Now reset fails and keeps failing just because target is not examined. First check is in jim_target_reset, target.c:4767 another one somewhere in arp_reset. Usual but painful solution is restart OpenOCD. Reset should really do a reset, I thing it is a legitimate requirement. I propose to improve error treating in reset process depending on srst/trst availability. If a hw reset line is available then reset process can safely ignore all errors and proceed to asserting and deasserting reset line. In case of reset_config none, reset process should expend best effort to regain access to DP similarly to poll. Paul, I do not know OpenOCD internals enough to change the code without problems. Please please can you take that task? Maybe priority for 0.9.0, what do you thing? Tom ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
