On Wed, 4 Mar 2009, Øyvind Harboe wrote:
> > Well, actually the documentation for "halt" says that an argument of 0
> > should skip waiting for the halted state. This patch brings the code in
> > agreement with the doc.
>
> Actually I find the documentation obtuse on this point.
>
> There is a difference between checking if the target was in the halted
> stated without waiting(which it does today) and not checking if the
> target is in the halted state. Checking if the
> target is in the halted stated *could* have side effects or
> even fail on some targets I guess.
Right. It fails on Feroceon when nSRST is asserted. Still, the
documented behavior is what I need in that case. If someone really
needs to halt and check without waiting, then a combination of "halt 0"
and "wait_halt 0" or even "poll" could be used.
> I'd favour clarifying the doc and a patch along your lines, except
> that I'd like to check for numeric 0 instead of string 0. This is
> to avoid annoying hard to trace bugs if the "halt 0" is e.g.
> generated via tcl in hex. Maybe that would "never happen",
> but I'd feel better if it parsed then argument to a number
> and checked afterwards.
Here's amended patch. I'll let you clarify the doc as you seem to have
a better idea of what it should be.
diff --git a/src/target/target.c b/src/target/target.c
index 6a72c5b..d2fb1c8 100644
--- a/src/target/target.c
+++ b/src/target/target.c
@@ -1759,6 +1759,16 @@ int handle_halt_command(struct command_context_s
*cmd_ctx, char *cmd, char **arg
return retval;
}
+ if (argc == 1)
+ {
+ int wait;
+ char *end;
+
+ wait = strtoul(args[0], &end, 0);
+ if (!*end && !wait)
+ return ERROR_OK;
+ }
+
return handle_wait_halt_command(cmd_ctx, cmd, args, argc);
}
Nicolas
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
