Re: [Openocd-development] Getting rid of default jtag clock rate

[David B. <da...@pa...>]

--- On Mon, 12/6/10, Laurent Gauch <lau...@am...> wrote:



> > I don't subscribe to the idea that there is a safe,
> correct and robust
> > default setting for JTAG clock,


The only thing that'd prevent a given board from
having such a (board-specific) setting is using
it with a debug adapter that doesn't support the
board's preferred frequency.  Trying that must
trigger a fatal error from the adapter.

That is:  any given board/target will have such
a setting, which can be saved in a config file.



 better to make the
> user get a
> > good error message 

Good messaging is always good.  Just like
Bad messaging is always bad...  Somewhat
tautological.

But relying on messaging to achieve proper
setup is not very wise.  We know that users tend not to
read or understand such messaging.  Treat such
procedures as undesirable fallbacks, except for
basic error reporting.  Good diagnostics (with
"what to do next" advice" are so rare nowadays
that I think users will run away in fear if they
come across any such.


> I do not say the 1MHz is safe correct and robust, but
> having a known 1MHZ JTAG at startup, is is a good way to let
> the user do something with openocd

That presumes, wrongly, that 1 MHZ would work.
First time I used OpenOCD was with a 32KHz
system clock, so a 1 MHz default would have
been a complete and utter lose.


 without having to
> obligatory set a specific frequency in the script. 

Were it not safe/correct/robust it couldn't work.
So don't even bother with it.

Remember that the board's frequency only needs
to be set once.  Once that's done, "the user"
has no more setup to handle.  In fact, Whoever did
the board config file should have handled all
such issues, so "the user" never sees them.


> THE SAFE CORRECT ROBUST frequency can never be known as
> static !

See above.  It's board-specific, but can very
easily be "known as static" for startup.  (And a
good config can adapt later, to new PLL settings
and so forth.)

 A good JTAG software has to find this frequency by
> itself (auto-detecting the max safe JTAG frequency );-)

All JTAGs I've used require manual config for
this, since board requirements vary so much, and
since detecting that a particular problem was
caused by a bad frequency setting isn't very
easily automated.  There are a LOT of distinct
failure modes, but some look like failures of
a different kind (e.g. wiring errors).  The
best way to sort this stuff out involves ways
to leverage end-user brains.  (and failure modes
stying simple enough that they don't need
extensive troubleshooting training).