On Saturday 16 January 2010, Freddie Chopin wrote:
> On 2010-01-16 20:59, David Brownell wrote:
> > Oh, and while this is clearly a "bug", from what I've heard it
> > isn't a "regression" from the last release ... "just" a long
> > standing bug.
>
> My bisection (
> https://lists.berlios.de/pipermail/openocd-development/2010-January/014229.html
>
> ) shows that the bug was originated ~4months ago, so that's not so very
> long. It's a regression from 0.2.0.
OK, but 0.2.0 != "last release"! :)
So with regards to the 0.4 release, a bugfix wouldn't quite count as a
regression fix. Re fixing it, you fingered:
commit 37755ffdb63164e768745369a98f06c5ec9d476d
Author: oharboe <ohar...@b42882b7-edfa-0310-969c-e2dbd0fdcd60>
Date: Thu Sep 24 06:34:23 2009 +0000
When attaching GDB to OpenOCD, the target state is no longer affected.
Added gdb_sync feature that allows GDB to sync up to target state.
Issue "monitor gdb_sync" and the next stepi, will return immediately
with updated register values to GDB.
That's not at all directly related to STM32. So evidently the
failure mode is some kind of side effect, possibly related to how
the Cortex-M3 debug entry code acts strangely the first time through.
I'll look at that; previously I just took that as a minor annoyance,
but this makes me think there must be more to it.
Maybe Øyvind has some notions...
> Before that there was a similar bug
> that I've reported once, that ft2232 code somehow fails to correctly
> initialize JTAG adapter first time after power-up (from what I remember
> this affected ftd2xx compilations only).
>
> IMHO this bug is pretty nasty - I know that it exists, so I'm not
> surprised about it, but it's a very "silent" bug - GDB (via Eclipse
> plugin) doesn't report any failure at all most of the time - to notice
> that one has to browse through the OpenOCD noise and interpret "write
> failure" as something serious, not "usual noise"...
Not denying that it's a bug, or that it would be good to see this fixed.
Or even that, if we'd know about it, it would have been appropriate to
hold the 0.3 release until this was fixed.
- Dave
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
