On 2010-12-04 12:05, Rolf Meeser wrote:
When doing "reset halt" (which would halt the chip immediately after
reset) the clock would be 4MHz.
Wrong. I've explained that often enough.
So you say that after reset and immediate halt the chip clock (for new
LPCs) is not 4MHz? Are you working for NXP and do you know something
that's not public? Because the manuals say something different than you.
Bootloader has nothing to do with it, as "reset halt" will prevent it
from running and changing anything.
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.
You say there is none, I say there is. There's no way we can agree.
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.
Sure - OpenOCD can be changed so that other - easier to use - tools
would be more and more popular.
For me this policy is right. I'm willing to state this on as many
occasions as required.
I can also say it's wrong anytime, so obviously we cannot agree on that
subject too.
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.
Changing these 5 numbers is pretty straightforward and people do that
(as OpenOCD works for them). I do. And are you saying that programming
flash with wrong speed causes it to fail LATER? Again - do you have some
secret knowledge from NXP that general public doesn't?
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?
Obviously this device cannot be used with 14.765 crystal because LPC2148
also cannot (see your paragraph above) - I don't know why is that, but
if you say so...
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.
It works because I set the right frequency in files. This is pretty
simple because I usually see no reason to use crystals different than
12MHz. Yes, this must be plain wrong, and you must be plain right, as
the world is black and white. Ease of use does not matter, the most
important thing is to be ultra-correct with everything. Do you actually
care about the users, or maybe you're affiliated with Keil or IAR and
your goal is to make using OpenOCD harder? Really - your change does
nothing more than make OpenOCD harder to use, as everyone could change
that frequency before that (and they did, as people were using OpenOCD
successfully with those chips for a long time), but to do that no
additional file was required.
Again (and again) - default (whatever they may or may not be) values
with warning for ALL LPC config files are GOOD. Adding "board" files
with such default value is exactly the same as leaving default value
inside target files. You loose nothing, we gain easy use and we are
warned that this may fail in some way or another.
Alternatively you may want to make that work:
openocd -c "set FREQ 12345" -f interface/... -f target/...
Because now it does not work (at least it didn't work the last time I've
tried). It would also be fine. The need for obligatory creation of
otherwise useless files is not fine.
4\/3!!
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development
