On Wednesday 23 July 2008 21:19:50 you wrote: > I've committed the fix for "<memory> is missing" problem.
Thanks. > > * Also, since the halt() is asynchronous target connect will be > > * instantaneous and thus avoiding annoying timeout problems during > > * connect. > > */ > > > > The above comment means that OpenOCD knowingly replies with stale data, > > even if there's absolutely no reason for doing so... > > could you explain what you mean by "absolutely no reason"? When I found the bug - my target was running - the OpenOCD was running - I realized that my application was locked, i.e. it must have crashed somewhere, or entered some infinite loop - I wanted to know where my application was, and possibly examine some data, registers etc. In that case, there's absolutely no reason why starting GDB and connecting to the OpenOCD should result in stale/bogus data being presented to the user. The halt might take a while (~1s with jtag_speed 1400), but the target can easily enter debug state, and by the time it is halted we have reliable data. > Do you specifically mean that the target should be halted, if possible, > before replying to the register packet? Well, that's what GDB expects, isn't it? Upon connection, GDB believes the target is halted, and queries its current state (e.g. 'g' packet). > There are a couple of things that need to line up just right: > > - we need to allow GDB connections to dead or unresponsive targets. This > is to allow users to have monitor commands in the GDB init script to set > things up. > - we need to respond immediately to the connect, or we get weird error > messages that are pretty much impossible to deduce anything from, it > just looks like OpenOCD or GDB is broken) You forgot: - we must not reply with bogus/stale data. if we absolutely must reply with bogus data we should at least inform the user... > You didn't include a -d3 log, so I don't know much about what happened > in your debug session. I've already sent the -d3 log last night: https://lists.berlios.de/pipermail/openocd-development/2008-July/002756.html > Perhaps we can get rid of the white lie upon connect, but for > now it seems like the best option. > > Perhaps waiting 500ms for the halted state will do the trick? Thanks a lot, looks like that worked. Do you know how much time we have here? Would it be possible to keep GDB going with the empty reply packets we send in keep_alive? > If this fails, then I'd like to see the -d3 log. See above. Let me know if you still want a -d3 log. Regards, Dominic _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
