On 2010-11-11 19:34, Peter Stuge wrote:
>/ Freddie Chopin wrote:
/>>>>/ If no SRST pin is available, Cortex-M3 soft-reset is required,
/>>>/
/>>>/ How common is this case?
/>>/
/>>/ How common is what? Lack of SRST?
/>/
/>/ Yes?
/
For me such situations are almost impossible, but some strange and
bizarre policy makes default target file for stm32 tell OpenOCD there is
no reset at all...
Of course user can change that, but with this assumption, target, board
and interface cfg files can as well be deleted, as the user can write
his/her own... Number of things that users of OpenOCD have to do prior
to using it for it's main purpose tends to grow, rather than shrink...
Yes, you're right ...
I (and many other people) like to use OpenOCD with just command-line
parameters, like this:
openocd -f interface/... -f target/...
It worked fine, and that was very cool, because one does not need to
prepare millions of config files for each project / occasion.
Yes VERY cool, and a part of the success of OpenOCD !
Now with
this method peripherals are NOT reset during "reset ..." command on
stm32... I know what to do to fix this, but I bet 95% of OpenOCD users
don't. You can decide that it's their problem if you want. The files in
target directory are soon going to be useless alone.
Completely off-topic: sometimes I think, that open-source projects are
just a cover-up made by people working for big companies - they ensure
that the software works, but is impossible to use without reading the
manual twice, browsing through the mail archives, searching the web for
half a day and then reading the manual again... Then they find out that
this "problem" they have is a "policy" and that it will never be
changed, because someone decided that it's the right way to go.
OpenOCD project was not started in this way. But it is close to become
as you say.
Why the OpenOCD was a success,
- 1. open-source
- 2. easy to use to do BASIC debug
- 3. cheap hardware debug (USB JTAG)
- 4. easy to come in the project and add new features / patches ...
An important point is the "BASIC debug" - if you want to do more
complexe debug you should buy something else DSRTEAM / KEIL / GREENHILLS ...
But the complex debug are only for the 1% of users, the 99% will use
openocd or something like the excellent Rowley Crossworks ;-)
Now, OpenOCD is becoming more & more difficult to build (with the
dependency of external tools like JimTCL / for me it is not a good thing
to have JimTcl as an external module -> we will see more troubles in
futures.) ... and more and more difficult to use with changing System
Reset idea ....
If we do not keep the openocd Easy to use, we will certainly kill it, or
we will just provide an Excellent Debug platform for some big company
with more manpower, and some company not respecting open-source license !
my 2c.
>>/ If SRST is available, no soft-reset is required.
/>/
/>/ Of course. What decides on the code path?
/
I don't understand the question, so here is a blind answer...
1. no chip resets, no cortex-m3 reset method specified - use SYSRESETREQ
(now use VECTRESET - does not reset peripherals)
2. chip reset available, cortex-m3 reset method specified - use
cortex-m3 reset method that was specified
3. chip resets available, no cortex-m3 reset method specified - use SRST
4. no chip resets, cortex-m3 reset method specified - use it, but if
cortex-m3 reset method is SRST that will be changed to SYSRESETREQ (now
it will be changed to VECTRESET, note as in 1.)
4\/3!!
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
