Hi Freddie,
On 12/03/2010 11:11 PM, Freddie Chopin wrote:
How can this be unreliable? LPC23xx/LPC24xx after reset use 4MHz
internal clock. Doing "reset halt" sets that clock and prevents any
code from changing that (let's not talk about broken cases, because a
broken case can be found everywhere), so what's wrong with this approach?
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.
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.
What's the purpose of using a 512KiB flash micro if you only need 50K?
Lots of applications *will* use big parts of the flash, and yes,
programming times *do* matter in my development cycle, especially if we
are talking 10s vs. 20s (and for no good reason!).
Why use big chip? LPC2478 has an LCD driver, and there is no chip with
LCD driver that has less flash. Because for developement of the
project you take big chip just-in-case, and choose right one
(regarding flash size) for production when the code is ready. Anyway -
we should be talking about the average size of the upload, and that's
never 512kB - the code has to grow from 0 to this size during
developement.
BTW - you use libusb of ftd2xx (if you use Windows and FT2232 based
JTAG)? I'm asking because if waiting 10s is worth breaking
configurations of OpenOCD's regular users, then I hope you use the
fastest library for the process.
C'mon! 10s?! Don't read mailing lists and that will save you much more
time (;
I'm afraid but professional embedded development is different. Speed
matters.
Why would I renounce the comfort of a fast download when I can get it
for free?
I want OpenOCD to be as efficient as possible.
If you don't like that, you may always run at a slower clock, and help
yourself with a cup of tea.
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.
So what is the problem? Right now, you are using the LPC2478 target
config file. You could use some kind of "lpc2478_std" config file
instead - same amount of typing, same user experience, but those people
working with more complex boards will have the benefit of running at the
right clock speed.
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 have a crazy idea - I think it is possible to measure frequency of
the external crystal (and check for it's existence) with simple code
using one timer. This way OpenOCD would work without specifying this
frequency. It could then - before programming - measure it (backup-ing
all settings of timer), switch PLL to max value (using external
crystal or internal resonator, also backup-ing all settings of clock
and PLL), flash, revert all changes made to clock, PLL and timer and
voila [; Problem gone
Nice idea. However, that goes way beyond what is required right now to
get reliable programming at the maximum possible speed.
Also, will this work without a "reset init" to get the system into a
known state?
I was thinking about embedding that within OpenOCD's flash handling
code specific for LPC, not in config files. Right now you have to
supply that speed, with such wise flashing algorithm this parameter
would be useless (could be provided, could be omitted - freq would be
measured then).
Deep inside I have a feeling that this proposal is on a head-on
collision course with your wish for simplicity...
Technically, I do not know how you want to measure frequency without a
timing reference.
And why on earth would I *temporarily* enable the PLL to circumvent the
difficulty of enabling the PLL at all?
I'm lost.
Regards,
Rolf
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
