On Sunday 27 September 2009, Freddie Chopin wrote:
> >
> > If it doesn't ... seems buggish, but maybe you
> > could declare it as a global.
>
> I works when I use a wrapper script, but doesn't work when I use
> -c "set CRYSTAL_FREQ 1200" -f target/lpc2103.cfg
In fact the same thing happens i
Rolf Meeser pisze:
> How would you write a board file for a board with two LPC2103 in the
> chain? A simple source [find target/lpc2103.cfg] source [find
> target/lpc2103.cfg] wouldn't work because it would try to declare two
> targets with the same name (lpc2103.cpu).
>
> Previously it was possib
t; Von: Freddie Chopin
> Betreff: Re: [Openocd-development] new lpc2xxx cfg files layout
> An: "openocd-development"
> Datum: Sonntag, 27. September 2009, 21:05
> Be it your way...
>
> 4\/3!!
>
> ---
Be it your way...
4\/3!!
Index: tcl/target/lpc2103.cfg
===
--- tcl/target/lpc2103.cfg (revision 2744)
+++ tcl/target/lpc2103.cfg (working copy)
@@ -1,38 +1,19 @@
-# NXP LPC2103 ARM7TDMI-S with 32kB Flash and 8kB SRAM, clock
David Brownell pisze:
> Not sure; did it fail the same way with that set in
> an "openocd.cfg" file?
>
> There's a bunch of code that works today and uses
> variables set in previous files. If you're doing
> that the same way that code does, I'd expect it
> to "just work".
>
> If it doesn't ...
On Sunday 27 September 2009, Freddie Chopin wrote:
> David Brownell pisze:
> >> -f interface/sth.cfg -f target/sth.cfg
> >
> > That's the same as a "wrapper script".
> >
> > Just stick "-c set CRYSTAL_SPEED 3579545" in there, same effect.
>
> I tried the same yesterday (-c "set CRYSTAL_FREQ xxx"
David Brownell pisze:
>> -f interface/sth.cfg -f target/sth.cfg
>
> That's the same as a "wrapper script".
>
> Just stick "-c set CRYSTAL_SPEED 3579545" in there, same effect.
I tried the same yesterday (-c "set CRYSTAL_FREQ xxx") but... it doesn't
work...
> c:\>openocd -c "set CRYSTAL_FREQ 12
On Saturday 26 September 2009, Freddie Chopin wrote:
> > A "wrapper" is already required to associate the right JTAG adapter
> > with the right target. I fail to see how adding the "set" in this:
> >
> > source [interface/...cfg]
> > set CRYSTAL_SPEED 3579545
> > source [target/...cfg
David Brownell pisze:
> I don't see how that can be right either, except on chips that
> have a real way to halt-on-reset ... and as I understand, these
> chips from NXP don't support that. So chip startup code will run,
> and likely set up some clocking stuff first thing, which will be
> neither
On Wednesday 23 September 2009, Petri Pirttinen wrote:
> > If you don't see what's wrong about forcing every
> > single LPC2xxx chip to use "12 MHz" even if that's
> > not the *correct* frequency for their board ... I
> > don't know what more I could try to explain.
>
> I may have missed something
On Wednesday 23 September 2009, freddie_cho...@op.pl wrote:
> "Petri Pirttinen" napisał(a):
> > I may have missed something in here, but why trying to specify a crystal
> > frequency? Can't we use 4 MHz in here, IF we are setting the clock
> > source to internal RC oscillator in reset-init s
"Petri Pirttinen" napisał(a):
> I may have missed something in here, but why trying to specify a crystal
> frequency? Can't we use 4 MHz in here, IF we are setting the clock
> source to internal RC oscillator in reset-init script anyway?
1. Not all LPCs have internal RC - just the "more rec
> If you don't see what's wrong about forcing every
> single LPC2xxx chip to use "12 MHz" even if that's
> not the *correct* frequency for their board ... I
> don't know what more I could try to explain.
I may have missed something in here, but why trying to specify a crystal
frequency? Can't we
.pl
>> Cc: openocd-development@lists.berlios.de
>> Subject: Re: [Openocd-development] new lpc2xxx cfg files layout
>>
>> On Wednesday 23 September 2009, freddie_cho...@op.pl wrote:
>> > Will the new cfg files layout be committed or not?
>> > If not, I'll just
On Wednesday 23 September 2009, freddie_cho...@op.pl wrote:
> "David Brownell" napisał(a):
> > If you don't see what's wrong about forcing every
> > single LPC2xxx chip to use "12 MHz" even if that's
> > not the *correct* frequency for their board ... I
> > don't know what more I could try to
s.de
> Subject: Re: [Openocd-development] new lpc2xxx cfg files layout
>
> On Wednesday 23 September 2009, freddie_cho...@op.pl wrote:
> > Will the new cfg files layout be committed or not?
> > If not, I'll just stop wasting my time.
>
> We try to avoid committing obvio
"David Brownell" napisał(a):
> If you don't see what's wrong about forcing every
> single LPC2xxx chip to use "12 MHz" even if that's
> not the *correct* frequency for their board ... I
> don't know what more I could try to explain.
Well, I just don't see that as "forcing" - you should chang
oyvind.har...@zylin.com napisał(a):
> My concern about your patch(I haven't dived into it) is that last
> time I worked on LPC reset scripts, I had to stay clear of soft_reset_halt
> and set the CPU into the ARM state manually...
To keep the "status quo" for now I haven't changed that part - t
On Wednesday 23 September 2009, freddie_cho...@op.pl wrote:
> Will the new cfg files layout be committed or not?
> If not, I'll just stop wasting my time.
We try to avoid committing obvious new bugs; and this
crystal rate is sort of in that category.
I think there's fair agreement that being able
> I'm still calm, but this whole discussion is really off-topic now. New cfg
> files layout
> is one thing, use of crystal frequency or the reset-init script is another,
> completely separate one (in my opinion). Why not end one subject, and
> move to another then?
I'm with you 100% on this one.
oyvind.har...@zylin.com napisał(a):
> Calm down. If we weren't going to commit your stuff
> (we regularly do), then we wouldn't be talking to you.
>
> I've been impressed with your patience on this one, just hang in
> there.
>
> David has a residual concern that some user out there wi
2009/9/23 :
> "David Brownell" napisał(a):
> > If I translate correctly ... you're saying that this is a
> > pre-existing bug that you're just perpetuating. Yes?
> >
> > Bug being: they're all getting set up to use the wrong
> > clock rate. If the flash driver is using that, it could
> >
On Tuesday 22 September 2009, Øyvind Harboe wrote:
> I was thinking about recommending a one second busy loop in
> the flashed application upon reset for debug builds. This gives
> OpenOCD enough time to do it's evil deeds...
Might be worth adding a (currently short) chapter to the
user's guide su
"David Brownell" napisał(a):
> If I translate correctly ... you're saying that this is a
> pre-existing bug that you're just perpetuating. Yes?
>
> Bug being: they're all getting set up to use the wrong
> clock rate. If the flash driver is using that, it could
> make problems flashing..
> My two cents worth... what if the debug build waits forever until the
> JTAG debugger allows it to run?
It's nice to have a timed loop in the beginning so that you can run the
debug build in standalone mode...
That's just a matter of taste and particular requirements for
testing/development th
> Date: Wed, 23 Sep 2009 08:53:04 +0200
> From: ?yvind Harboe
> Subject: Re: [Openocd-development] new lpc2xxx cfg files layout
> To: David Brownell
> Cc: openocd-development@lists.berlios.de
> Message-ID:
>
> Content-Type: text/plain; charset=UTF-8
>
> I w
I was thinking about recommending a one second busy loop in
the flashed application upon reset for debug builds. This gives
OpenOCD enough time to do it's evil deeds...
--
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer
On Monday 21 September 2009, Freddie Chopin wrote:
> > I think the fact that it doesn't work reflects a bug. But I
> > don't know those LPC chips, or thus where the bug would be.
>
> That's a silicon limitation of LPC chips... For example in CrossWorks
> this is overcome by injection a startup w
On Tuesday 22 September 2009, Freddie Chopin wrote:
> David Brownell pisze:
> > On Tuesday 22 September 2009, Freddie Chopin wrote:
> >> +set CRYSTAL_FREQ 1200
> >
> > Really? It's not possible to use these chips
> > except with 12 MHz crystals, which is why all
> > these target config files
David Brownell pisze:
> On Tuesday 22 September 2009, Freddie Chopin wrote:
>> +set CRYSTAL_FREQ 1200
>
> Really? It's not possible to use these chips
> except with 12 MHz crystals, which is why all
> these target config files now specify 12 MHz?
>
> For grins, I grabbed the LPC210[123] data
On Tuesday 22 September 2009, Freddie Chopin wrote:
> +set CRYSTAL_FREQ 1200
Really? It's not possible to use these chips
except with 12 MHz crystals, which is why all
these target config files now specify 12 MHz?
For grins, I grabbed the LPC210[123] data
sheet, and it says otherwise: any f
I've taken suggestions from Duane and David and added warning messages
when default values are used.
4\/3!!
Index: tcl/target/lpc2103.cfg
===
--- tcl/target/lpc2103.cfg (revision 2744)
+++ tcl/target/lpc2103.cfg (working c
On Monday 21 September 2009, Freddie Chopin wrote:
> > + puts "WARNING: RESET_CONFIG not set, assuming: $_RESET_CONFIG"
> > +}
>
> I also thought about that, but... in here such line does not print any
> output in the console... It doesn't get printed even with "-d 3", so I
> have no idea
Duane Ellis pisze:
> 2) Only thing I can think of is this.. type of a change
>But that is a minor thing, I hate hidden default values.
>They are MAGIC - that always mess me up, been burned one too many
> many times.
>
> +# check for RESET_CONFIG - if not defined set the default: trst_and
Freddie Chopin wrote:
> Here is the patch that adds the lpc2xxx_internals.tcl file and
> modifies all lpc2xxx (ARM7) files to use that.
1) Looks good, I agree the "reset" issue can be resolved later.
2) Only thing I can think of is this.. type of a change
But that is a minor thing, I hate hi
Here is the patch that adds the lpc2xxx_internals.tcl file and modifies
all lpc2xxx (ARM7) files to use that.
4\/3!!
Index: tcl/target/lpc2103.cfg
===
--- tcl/target/lpc2103.cfg (revision 2744)
+++ tcl/target/lpc2103.cfg (
Hi,
Im using LPC2364 with modified sample target/lpc2378.cfg with
interface/jtagkey2.cfg and with modification reset_config none (I dont have
connected reset to JTAG). My GDB flash init is:
target remote localhost:
monitor soft_reset_halt
monitor gdb_breakpoint_override hard
d
b main
c
And
David Brownell pisze:
> Normally a "reset halt" should have caused MAM and PLL to
> enter their just-after-hard-reset hardware default states ...
>
> Are you saying those hardware default states cause problems?
> If so, that seems buggy. I'm not sure where the issue would
> lie, but it's hard to
On Saturday 19 September 2009, Freddie Chopin wrote:
> 1. When there is "soft_reset_halt" in the script:
>
> v1 fails - target not halted
> v1 (without load) - works
> v2 fails - target not halted
> v2 (without load) - works
>
> But: When I want to load I have to do:
>
> monitor reset halt
> loa
On Saturday 19 September 2009, Freddie Chopin wrote:
> I don't know how should the GDB initialization commands look like:
>
> monitor reset init
> load
> (let's call that "v1")
That should work. If it doesn't, there's a bug lurking somewhere.
> or maybe:
>
> monitor reset halt
> monitor reset
On Monday 21 September 2009, Petri Pirttinen wrote:
> > - JTAG_FREQ - CRYSTAL_FREQ / 8 works for me all the times, but
> > CRYSTAL_FREQ / 6 - not (in the .tcl file I divide by 8 now)
>
> Agreed. Divided by 8 seems to be a more stable option in here as well.
div/6 is *ABSOLUTE BEST CASE* that mor
On Monday 21 September 2009, Petri Pirttinen wrote:
> What is the purpose of reset-init event? In my opinion it is where we
> want to get things back to the beginning.
A "reset halt" is intended to reset and cause a halt before
execution of the first post-reset instruction. That's "back
to the b
> What is the purpose of reset-init event?
"reset init" puts a target that is reset into the halted state,
into a state where gdb load, flash programming, etc. will work.
I.e. that the target is ready to be debugged or programmed.
the reset-init event is the most straightforward way to implemen
>>> Why are you doing a soft_reset_halt?
>> Why not?
>>
>> If this command is forbidden / wrong / whatever - remove it. If it's not,
>> why do you care if I use it? Without that command it does not work. Or maybe
>> I just don't understand the meaning of "reset init"? For me that is "do a
>> reset,
> BTW I have also attached a reset-init script that not only does a
> soft_reset_halt and vector table remap, but also disables MAM and PLL
> after reset - without that two steps I experienced really crazy
> behaviour in a very simple and correct code while debugging.
This is a little bit same
On Sat, Sep 19, 2009 at 3:32 PM, Freddie Chopin wrote:
> Øyvind Harboe pisze:
>> Freddie, calm down.
>
> OK, I'm calm, sorry.
>
> First of all - I haven't found any info in the manual about what exactly
> does "reset init" do. Does it just reset and run the init script, or
> maybe it also halts af
Øyvind Harboe pisze:
> Freddie, calm down.
OK, I'm calm, sorry.
First of all - I haven't found any info in the manual about what exactly
does "reset init" do. Does it just reset and run the init script, or
maybe it also halts after reset?
I don't know how should the GDB initialization commands
On Sat, Sep 19, 2009 at 2:23 PM, Freddie Chopin wrote:
> Øyvind Harboe pisze:
>>
>> Why are you doing a soft_reset_halt?
>
> Why not?
>
> If this command is forbidden / wrong / whatever - remove it. If it's not,
> why do you care if I use it? Without that command it does not work. Or maybe
> I jus
Øyvind Harboe pisze:
> Why are you doing a soft_reset_halt?
Why not?
If this command is forbidden / wrong / whatever - remove it. If it's
not, why do you care if I use it? Without that command it does not work.
Or maybe I just don't understand the meaning of "reset init"? For me
that is "do a
Why are you doing a soft_reset_halt?
--
Øyvind Harboe
Embedded software and hardware consulting services
http://www.zylin.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-d
How about now (your way)? Should I make a patch?
What about defining variables like CPUTAPID, which - most probably - is
exactly the same for all LPC2xxx chips? Should that be defined in the
"lpc2xxx.cfg" file, of just left with the default value? The variables
like this are:
- RESET_CONFIG -
Here, I agree with Duane,
The end user want to debug/flash a device -> not a concept of multiple
devices.
You may auto-generate the files one time at the MAKE of openocd.
Or you may have a separated script, generating this file one time and
put these file to the trunk.
Regards,
Laurent
http:/
Freddie Chopin wrote:
freddie> I still cannot agree on that. Which version is better:
freddie> Your:
duane> global CHIPNAME
duane> set CHIPNAME lpc2103
duane> global FLASH_SIZE
duane> set FLASH_SIZE ...
duane> ... [snip] ...
duane> source [find target/lpc2xxx_internals.tcl]
freddie> or mine
fre
Duane Ellis pisze:
> As an *end*user* if I saw a sequence of filenames that I recognized I
> could examine a few of them - see the simple pattern and settings and
> could probably follow that simple pattern successfully. By simple I
> mean: perform lots of "set VARNAME VALUE" - then include/so
On Tue, Sep 8, 2009 at 2:31 AM, Duane Ellis wrote:
> david> Having a hundred or so chip-specific config files is
> david> a messy concept...
>
> Yes, but that is exactly what is needed.
>
> If there are 100 chips - you need 100 files, with 100 names.
I guess I have to agree with you on this one.
david> Having a hundred or so chip-specific config files is
david> a messy concept...
Yes, but that is exactly what is needed.
If there are 100 chips - you need 100 files, with 100 names.
Take the "openocd-developer-hat" off for a little bit and think about this.
Configure files are something *
On Monday 07 September 2009, Duane Ellis wrote:
> I would have put *ALL* sets in the CHIP_SPECIFIC file
> And some type of validation in the CHIP_INTERNALS file.
Wasn't the key part of Freddie's idea to git rid of
the need for a plethora of chip-specific files?
NXP has 90-odd lpc2xxx chips (most
Duane Ellis pisze:
Freddie Chopin wrote:
I got the second version - it implements ideas from Duane and David.
comments...
-Duane.
===
1) Seems to be missing proc _SET_DEFAULT..
2) There are numerous syntax errors ... example:
# check for VARIANT - it has to be defined
if {
Freddie Chopin wrote:
> I got the second version - it implements ideas from Duane and David.
comments...
-Duane.
===
1) Seems to be missing proc _SET_DEFAULT..
2) There are numerous syntax errors ... example:
# check for VARIANT - it has to be defined
if { [info exists VARIAN
I got the second version - it implements ideas from Duane and David.
Take a look and tell me what do you think about it. Should I create a patch?
I attach 2 files - lpc2xxx_internals.tcl and lpc2103.cfg as an example.
Notice that now ALL the magic is completely hidden inside
lpc2xxx_internals.
Yes this is nice idea; it also helps keeping track on changes (one
does not need to reflect possible config modifications to a bunch of
similar files). I just wanted to remind that LPC17xx series also falls
under LPC2xxx group in OpenOCD. The differences are VARIANT=lpc1700,
RAM (i.e. work-area-phy
> BTW 1 - is there a way to check just a part of the string in TCL?
> For example I could set "variant 1" for all LPCs from LPC23* and LPC24*
There are 2 approaches, "regex" - and "string match"
JimTCL (is not real TCL and) does not have "regex" - it does have
"string match"
The "string" comm
Freddie,
To david's point:
>> Why not just error out at this point if
>> these five variables (__CHIPNAME too!) aren't set?
I have a suggestion about these files, why don't you follow this format:
The file -
(a) should just SET a bunch of variables.
(b) then source/include the commo
David Brownell pisze:
> Please wrap lines before 80 chars.
That is not so important right now - I can wrap them in the last step.
Ignore that now [;
> And adopt _either_ uppercase or (preferred by me) lowercase
> for the CHIPNAME symbols ...
For me that's fine to use lower case only, but some u
Avoiding a bazillion lpc config files is a Good Idea!
I noticed that mess too.
On Saturday 05 September 2009, Freddie Chopin wrote:
> # LPC2478 - 512kB Flash (12kB occupied by bootloader) and 64kB Local On-Chip
> SRAM (98kB total), clocked with 4MHz internal RC oscillator
Please wrap lines befo
Take a look at the attached file. It's not ready yet, but it shows my
idea. When someone want's to create a file for a new LPC device (one
that doesn't have a cfg in OpenOCD) he/she has to dig through whole
OpenOCD guide to find out how to do that and then ask questions. When
using a file like
66 matches
Mail list logo
