On 12/04/2010 10:31 AM, Freddie Chopin wrote:
On 2010-12-04 00:32, Rolf Meeser wrote:
This is a misconception. When OpenOCD tries to take control after a
reset, the CPU is already running. ISP mode or existing user firmware
may or may not have changed the clock tree. Like it or not, but there is
no a priori knowledge of CPU clock.
When doing "reset halt" (which would halt the chip immediately after
reset) the clock would be 4MHz.
Wrong. I've explained that often enough.
With LPC23xx you are in the same situation as with older LPC2000 which
required an external crystal. The operating frequency is *not* a target
parameter, it is a board/application parameter.
Indeed - older LPCs don't work this way, because there is no internal
oscillator. So why change lpc2478.cfg that CAN work with default
value, and leave all older files that CAN'T?
No, the lpc2478.cfg *CANNOT* work with a default, because there is none.
Are you blaming me for not having changed all the other lpc2xxx.cfg
files yet? I promise I *will* change them all. They *must* be changed.
See below.
But there's no point in having a "board" file that in reality is not
for board but for target, that will do nothing more than include
target file... What for? What does that make easier? If one has it's
own board with some chip I don't think one would look for config
scripts in board directory... I wouldn't. Please - try to make OpenOCD
more user-friendly, not user-hostile!
That's the whole point of OpenOCD's layered config file approach.
Do you refuse to work with an LPC2138 device just because its target
config file cannot include a clock frequency? There is no way to avoid a
board file here. And at the risk of repeating myself, the situation for
LPC23xx is the same.
I've stated on multiple occasions that for me this whole policy is wrong.
As for the second paragraph, you are wrong. All LPC2xxx target config
files have that frequency embedded without possibility to change with
some parameters in board config files and - somehow - people manage to
use it without problems. And I like those files very much, because
they work standalone, so in my favorite way.
For me this policy is right. I'm willing to state this on as many
occasions as required.
Look at the ever so perfect standalone configs:
lpc2148.cfg: The clock frequency is hard-coded as 14.756 MHz.
Nobody will ever use this device with a 14.756 MHz crystal. Nobody. Never.
Now assuming a realistic crystal of 12 MHz, the gentle user will use the
device outside spec. With a 24 MHz crystal he might still be able to
program the flash and verify correctly. Unfortunately he will have field
returns, because the devices will certainly start failing after six
months or so.
This has already happened.
lpc2103.cfg: The clock frequency is hard-coded as 12 MHz.
So you're saying is that anybody using crystals of 10, 14.756, 16,
18.432, 20, 24 MHz has to accept that flashing won't work for him?
Just because you don't mind failures here and then?
The problem is that "right now" OpenOCD provides all I need, because
there is no "lpc2478_std" config file, lpc2478.cfg works just fine - I
(and anyone willing to use OpenOCD with that chip) would have to
create it first. Same amount of typing and user experience? I doubt it
- right now I don't need to know ANYTHING about tcl, OpenOCD's config
files etc. They work out-of-the-box. People working with more complex
boards are not forbidden to set right clock speed now. Actually I
think they managed, because I've not seen any complaints...
Why can't you do with LPC2478 what you *must* do with LPC2148? I'm not
getting it.
We're talking about a three-liner: 1. your interface, 2. your clock
frequency, 3. your target.
That's clearly a no-brainer!
I don't have to do that with ANY LPC2xxx file now. You're wrong here,
because all these target files have frequency embedded inside without
any parameters.
You don't do it now? Then you're failing *miserably*.
Having embedded frequencies in the target files is plain wrong. It
*DOESN'T* work.
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development
