Lpc2000

I'm evaluating Rowley's CrossStudio and am having serious problems. 
I'm using the Olimex 2106 demo board and the Wiggler JTAG interface.  
I'm new to the LPC devices and GCC but not MCUs in general.

The tools and board work mostly as expected when using RAM for the 
codespace. When using FLASH, however, several unexpected things are 
happening: 

1 - CrossStudio always successfully writes the Loader and erases the 
flash but usually fails with various timeout errors when it tries to 
write the code to the erased flash.  Once in a while it will work.  
I've tried both ECP and EPP settings for the parallel port and 
various settings in CrossStudio with no change.  The 2106 is also 
hung up when this happens and needs to be reset.  The wiggler 
sometimes needs to be power cycled as well, and a few times, 
CrossStudio stopped responding for good and had to be shut down with 
the task manager.  NOT GOOD!

2 - When I can manage to write the code to flash, the startup code 
doesn't seem to be linked correctly. I can change the PLLCFG 
multiplier from 0x24 (4X) to 0x21 (1X) and the chip still runs at 59 
Mhz.  I'm importing the assembly startup file into CrossStudio as 
specified in the docs, and it assembles just fine.  I'm new to this 
toolchain so I'm not sure where to look?  I can't even figure out how 
to tell the linker to generate a list file in CrossStudio?  This 
happens with the demo projects and when I start a new project from 
scratch.

3 - Things get even more strange. When I can write to flash, my code 
runs at 59mhz as outlined above (no matter what I set the PLL to).  
If I disconnect the wiggler and reset the board, the clock rate drops 
down to 1X (14.7 Mhz)!  Again, this is true no matter what the PLL is 
actually set to in the startup file!

I've verified the above problems are not related to the memory 
accelerator (which is disabled in all cases) or MAMTIM (flash wait 
states).  Those things work normally when I change them in the main 
code.

It's almost as if, even when set to use flash, CrossStudio is still 
telling the GCC linker to use RAM for some of the code?  The 
documentation isn't very clear on the CrossStudio-to-GCC interface.  
The problem with CrossStudio timing out when trying to write the 
flash is especially annoying as I usually have to power cycle the 
board (wiggler) and start over.

Frankly, I'm not impressed with the way code is loaded into the LPC 
parts.  It's a bit of mess compared to other processors that have 
much more direct (and bulletproof) programming interfaces.

Does anyone have any ideas or suggestions?  This is really 
frustrating!  CrossStudio is priced right, and I otherwise like it so 
far, so I hope I'm just doing something wrong?

--- In lpc2000@yahoogroups.com, "nw_mcu" <nw_mcu@y...> wrote:
> I'm evaluating Rowley's CrossStudio and am having serious problems. 
> I'm using the Olimex 2106 demo board and the Wiggler JTAG 
interface.  
> I'm new to the LPC devices and GCC but not MCUs in general.
> 
> The tools and board work mostly as expected when using RAM for the 
> codespace. When using FLASH, however, several unexpected things are 
> happening: 

[tale of woe deleted]


I've not had any problems programming the flash with the Rowley 
software, apart from when the supply voltage was marginal due to flat 
batteries (I usually use four NiMH cells for powering my boards). 
This can be puzzling because loading into RAM can work OK with a 
marginal supply. Have you tried a different power supply, yours might 
be noisy or something like that? Or, the regulator on the Olimex 
board might be misbehaving with the additional load for programming 
the flash. Ideally, you could try swapping boards, but you presumably 
only have the one.

Leon

--- In lpc2000@yahoogroups.com, "microbit" <microbit@c...> wrote:
> 
> First of all, what are you doing with nTRST ?

nTRST is connected to the 20 pin JTAG header on the Olimex 
board. I have no idea what the Wiggler does with it as I 
don't have a schematic for the Wiggler.  CrossStudio does 
have the option of performing a reset through the JTAG 
interface.  

 
> ( I did this is with a Nohau tester board)
> Provide for a button that selects bootloader mode on reset
> (ie. P0.14 must be pulled LOW on reset).
>
> When you start the debug - PRESS the bootloader button while 
> the loader code is being downlloaded. (ie. hold P0.14 LOW)
> Then release the button (P0.14 high again) BEFORE the actual 
> Flash app code is downloaded. You should find your Flash 
> download works everytime.
> I have NO idea why this has to be like that

That would be hard to do with CrossStudio because it writes 
the loader and code back-to-back.  To make things more 
difficult, the Olimex board has a jumper rather than a switch 
for that function.

If that's really the way the chip works, Philips should be 
ashamed of themselves!  As I said in my previous message, 
I'm NOT impressed with the way the LPC parts are programmed.  
It's a poor design especially for debugging and high-speed 
production programming.

 
> Do you maybe disable the PLL here after recompiling ?
> Most likely the Flash download "looks" succesful, but it's not.

That's what I suspect is going on.  That part of the code is 
still living in RAM even after you tell it to use FLASH.  
This seems to be a bug in the way CrossStudio is building the 
make (and/or other) file(s) for the linker?


> Keep in mind that to disable the PLL (or change multiplier),
> when your last succesful download enabled it - you must ALSO 
> use the password sequence to _actually_ DISable the PLL.

Yes, the startup code executes the magic sequence after 
establishing the PLL settings.  The PLL should be properly 
initialized EVERY time the chip is reset.  I don't understand 
how the startup code is only executed sometimes, or perhaps 
there are two different copies of it (one in RAM and one in 
FLASH)?  Again, this seems like a bug in how the code is built?


> Finally, if you set the PLL for 1X, chances are that the CCO isn't 
> within its proper specified freq range anymore !

This I don't understand.  The spec says:

"The input frequency is multiplied up into the range 
of 10 MHz to 60 MHz with a Current Controlled Oscillator 
(CCO). The multiplier can be an integer value from 1 to 32 
(in practice, the multiplier value cannot be higher than 6 
on the LPC2106/2105/2104 due to the upper frequency limit 
of the CPU). The CCO operates in the range of 156 MHz to 
320 MHz, so there is an additional divider in the loop to 
keep the CCO within its frequency range while the PLL is 
providing the desired output frequency."

If you mean that 14.7Mhz * 1 is less than 156 Mhz, you're 
correct.  But so is 14.7Mhz * 4!  How are you supposed to 
get to 156Mhz if the multiplier cannot be greater than 6 
(see above)?  14.7Mhz * 1 is in the range of 10Mhz to 60Mhz.


> I initially got EXACTLY the same results. The only time you 
> will find that the loader/app code Flash programming will 
> work is with a blank LPC2106....
> ...The reason for it, I'll be buggered if I know.

You're correct.  If I erase the part with the Philips ISP 
utility it always will load correctly from CrossStudio.  
Interestingly, selecting the "erase all" function in 
CrossStudio doesn't seem to solve the problem although it 
does seem to help in some cases.

Is this REALLY the only way the chip works?  Or is there 
something wrong with the CrossStudio/Wiggler/Olimex 
implementation?

The final target LPC2XXX for this application will not have 
a lot of RAM and the code will have to reside in FLASH.  If 
it's going to be a big hassle to debug the application in 
FLASH, I think I'll start looking at other ARM7 parts (like 
STM and OKI) or at least better tools for the Philips parts.

--- In lpc2000@yahoogroups.com, "leon_heller" <leon_heller@h...> 
wrote:
> This can be puzzling because loading into RAM can work 
> OK with a marginal supply. Have you tried a different 
> power supply, yours might be noisy or something like that?
> Or, the regulator on the Olimex board might be misbehaving 
> with the additional load for programming the flash.

Thanks for the reply.  I'm using a regulated bench power supply to 
run the Olimex board (and Wiggler).  To test your theory, I put a 
scope on the 1.8v and 3.3v lines on the Olimex board while attempting 
to write the flash and they're rock solid.  The board uses 800ma 
LM1117 regulators.

I seem to be having the same problem programming the flash as 
Microbit.  See my previous post for more info.

The problem with the PLL and clock speed is still a mystery.

Howdy,

> If you mean that 14.7Mhz * 1 is less than 156 Mhz, you're
> correct.  But so is 14.7Mhz * 4!  How are you supposed to
> get to 156Mhz if the multiplier cannot be greater than 6
> (see above)?  14.7Mhz * 1 is in the range of 10Mhz to 60Mhz.

There is a prescaler !

Look at PLLCFG register.
If you for example are after 14.7 MHz * 4 = 58.8 MHz,
then you would set the Multiplier(M) to 4, and the presaler (P)
could for example be 2 - thus :
Fcco = Fosc * M * 2 * P = 14.7 * 4 * 2 * 2 = 235.2 MHz.
cclk = Fosc * M  = 58.8 MHz.

If you now would want the M value to be only 1, then P would have
to be 4 times higher, ie. 8 - thus :
Fcco = Fosc * M * 2 * P = 14.7 * 1 * 8 * 2 = 235.2 MHz.
But cclk now is :
14.7 MHz * M = 14.7 MHz.

It sounds like the way you have it now, your PLL is incorrectly
programmed, the CCO is not capable of that low frequency, thus
the capture in range is not possible, _thus_ the PLL doesn't/can't lock.
The ref manual specifically states that you will yield unreliable operation.

Try setting the P and M values properly, and it should work properly then.
You need to change the "mov R1, # 0x24" instruction to change the prescaler
("divider") value.
For example, 0x25 sets P to 2 instead of etc.

-- Kris

> That would be hard to do with CrossStudio because it writes 
> the loader and code back-to-back.  To make things more 
> difficult, the Olimex board has a jumper rather than a switch 
> for that function.

That's what I had to do.
For some mysterious reason, having it in bootloader mode
when loader.exe is downloaded into RAM, but then letting go
of P0.14 works fine.
Maybe wire in a pushbutton, just to work around it.
I had to wire nTRST to the reset pin (ie. NOT pull it up to Vcc).

> If that's really the way the chip works, Philips should be 
> ashamed of themselves!  As I said in my previous message, 
> I'm NOT impressed with the way the LPC parts are programmed.  
> It's a poor design especially for debugging and high-speed 
> production programming.

It works a treat with the Nohau/Seehau/Hitech C environment,
so it's not Philips' fault.
I suspect it's a marginal timing issue on CrossWorks.
Maybe Paul or Michael can shed some light there.
I do recall they use the loader like this because the TAP
needs to be reset or some such.


> > Do you maybe disable the PLL here after recompiling ?
> > Most likely the Flash download "looks" succesful, but it's not.
> 
> That's what I suspect is going on.  That part of the code is 
> still living in RAM even after you tell it to use FLASH.  
> This seems to be a bug in the way CrossStudio is building the 
> make (and/or other) file(s) for the linker?

Nope, the building and linking is fine.
I think this is because you're not setting P properly.
I set up the PLL in my sys_init() start code in C.
It's preferable not to depart from the vendors' default startup
code, it will bite you in the bum later.

> Yes, the startup code executes the magic sequence after 
> establishing the PLL settings.  The PLL should be properly 
> initialized EVERY time the chip is reset.  I don't understand 
> how the startup code is only executed sometimes, or perhaps 
> there are two different copies of it (one in RAM and one in 
> FLASH)?  Again, this seems like a bug in how the code is built?

As above.

-- Kris

You shouldn't have any problems at all.
I am using the Olimex 2106-MT board together with CrossWorks and 
everything works like a charm.I have tried compiling into all 
different kind of targets and they all work perfectly. Mind you, i 
have not messed around with the PLL yet, but i'm getting there.

Did you remove both the DEBUG and BSL jumper ?

The only snag i found was that the control pins to the LCD pins were 
located on the ETM, so i can not debug my LCD driver. Bummer ;-)

Regards
/Pontus


--- In lpc2000@yahoogroups.com, "microbit" <microbit@c...> wrote:

> > That would be hard to do with CrossStudio because it writes 
> > the loader and code back-to-back.  To make things more 
> > difficult, the Olimex board has a jumper rather than a switch 
> > for that function.
> 
> That's what I had to do.
> For some mysterious reason, having it in bootloader mode
> when loader.exe is downloaded into RAM, but then letting go
> of P0.14 works fine.
> Maybe wire in a pushbutton, just to work around it.
> I had to wire nTRST to the reset pin (ie. NOT pull it up to Vcc).
> 
> > If that's really the way the chip works, Philips should be 
> > ashamed of themselves!  As I said in my previous message, 
> > I'm NOT impressed with the way the LPC parts are programmed.  
> > It's a poor design especially for debugging and high-speed 
> > production programming.
> 
> It works a treat with the Nohau/Seehau/Hitech C environment,
> so it's not Philips' fault.
> I suspect it's a marginal timing issue on CrossWorks.
> Maybe Paul or Michael can shed some light there.
> I do recall they use the loader like this because the TAP
> needs to be reset or some such.
> 
> 
> > > Do you maybe disable the PLL here after recompiling ?
> > > Most likely the Flash download "looks" succesful, but it's not.
> > 
> > That's what I suspect is going on.  That part of the code is 
> > still living in RAM even after you tell it to use FLASH.  
> > This seems to be a bug in the way CrossStudio is building the 
> > make (and/or other) file(s) for the linker?
> 
> Nope, the building and linking is fine.
> I think this is because you're not setting P properly.
> I set up the PLL in my sys_init() start code in C.
> It's preferable not to depart from the vendors' default startup
> code, it will bite you in the bum later.
> 
> > Yes, the startup code executes the magic sequence after 
> > establishing the PLL settings.  The PLL should be properly 
> > initialized EVERY time the chip is reset.  I don't understand 
> > how the startup code is only executed sometimes, or perhaps 
> > there are two different copies of it (one in RAM and one in 
> > FLASH)?  Again, this seems like a bug in how the code is built?
> 
> As above.
> 
> -- Kris

It's a marginal issue that shows on some machines I think.
I don't know whether it's the OS, or I/F or what, but I get the EXACT
same misbehaviours as nw_mcu gets.
For me, briefly holding P0.14 LOW when starting debug fixed it.

Of course the DBGSEL is set properly, it wouldn't work at all
otherwise !

-- Kris



----- Original Message -----
From: <pontus.oldberg@...>
To: <lpc2000@yahoogroups.com>
Sent: Monday, April 19, 2004 6:20 AM
Subject: [lpc2000] Re: Help: Rowley CrossStudio & Wiggler Problem


> You shouldn't have any problems at all.
> I am using the Olimex 2106-MT board together with CrossWorks and
> everything works like a charm.I have tried compiling into all
> different kind of targets and they all work perfectly. Mind you, i
> have not messed around with the PLL yet, but i'm getting there.
>
> Did you remove both the DEBUG and BSL jumper ?
>
> The only snag i found was that the control pins to the LCD pins were
> located on the ETM, so i can not debug my LCD driver. Bummer ;-)
>
> Regards
> /Pontus
>
>
> --- In lpc2000@yahoogroups.com, "microbit" <microbit@c...> wrote:
> > > That would be hard to do with CrossStudio because it writes
> > > the loader and code back-to-back.  To make things more
> > > difficult, the Olimex board has a jumper rather than a switch
> > > for that function.
> >
> > That's what I had to do.
> > For some mysterious reason, having it in bootloader mode
> > when loader.exe is downloaded into RAM, but then letting go
> > of P0.14 works fine.
> > Maybe wire in a pushbutton, just to work around it.
> > I had to wire nTRST to the reset pin (ie. NOT pull it up to Vcc).
> >
> > > If that's really the way the chip works, Philips should be
> > > ashamed of themselves!  As I said in my previous message,
> > > I'm NOT impressed with the way the LPC parts are programmed.
> > > It's a poor design especially for debugging and high-speed
> > > production programming.
> >
> > It works a treat with the Nohau/Seehau/Hitech C environment,
> > so it's not Philips' fault.
> > I suspect it's a marginal timing issue on CrossWorks.
> > Maybe Paul or Michael can shed some light there.
> > I do recall they use the loader like this because the TAP
> > needs to be reset or some such.
> >
> >
> > > > Do you maybe disable the PLL here after recompiling ?
> > > > Most likely the Flash download "looks" succesful, but it's not.
> > >
> > > That's what I suspect is going on.  That part of the code is
> > > still living in RAM even after you tell it to use FLASH.
> > > This seems to be a bug in the way CrossStudio is building the
> > > make (and/or other) file(s) for the linker?
> >
> > Nope, the building and linking is fine.
> > I think this is because you're not setting P properly.
> > I set up the PLL in my sys_init() start code in C.
> > It's preferable not to depart from the vendors' default startup
> > code, it will bite you in the bum later.
> >
> > > Yes, the startup code executes the magic sequence after
> > > establishing the PLL settings.  The PLL should be properly
> > > initialized EVERY time the chip is reset.  I don't understand
> > > how the startup code is only executed sometimes, or perhaps
> > > there are two different copies of it (one in RAM and one in
> > > FLASH)?  Again, this seems like a bug in how the code is built?
> >
> > As above.
> >
> > -- Kris
>
>
>
> --------------------------------------------------------------------------
------

> Yahoo! Groups Links
>
>   a.. To visit your group on the web, go to:
>   http://groups.yahoo.com/group/lpc2000/
>
>   b.. To unsubscribe from this group, send an email to:
>   lpc2000-unsubscribe@yahoogroups.com
>
>   c.. Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
>
>

--- In lpc2000@yahoogroups.com, "microbit" <microbit@c...> wrote:

> Look at PLLCFG register.
> If you for example are after 14.7 MHz * 4 = 58.8 MHz,
> then you would set the Multiplier(M) to 4, and the presaler (P)
> could for example be 2 - thus :
> Fcco = Fosc * M * 2 * P = 14.7 * 4 * 2 * 2 = 235.2 MHz.
> cclk = Fosc * M  = 58.8 MHz.

The demo code supplied by Rowley has P set to 1 and M set to 4 
(PLLCFG = 0x24) in their example giving 59Mhz with a 14.7Mhz 
crystal.  This gives a Fcco of 117Mhz which should be illegal.

Second, the data sheet shows "P" is a 2 bit value (bits 5 and 6 of 
PLLCFG) , yet it talks about values for P in the range of 2 - 16!  
Which is it Philips?

Third, Toggling an I/O pin in a while(1) loop I get periods of:

PLL OFF: 1150ns (should be 14.7Mhz)
PLLCFG = 0x61 (P=3, M=1): 577ns (should be 14.7Mhz but is 29Mhz?)
PLLCFG = 0x21 (P=1, M=1): 577ns (as above)
PLLCFG = 0x42 (P=2, M=2): 384ns (Should be 29.4Mhz but is 44Mhz?)
PLLCFG = 0x43 (P=2, M=3): 288ns (Should be 44Mhz but is 59Mhz?)
PLLCFG = 0x44 (P=2, M=4): 231ns (Should be 59Mhz but is 73.5Mhz?)
PLLCFG = 0x23 (P=1, M=4): 231ns (as above)

The above numbers are running from RAM with VPBDIV = 1 (full speed 
peripherals).  Because of the way I/O works on the Philips parts, you 
don't get a 1:1 correlation between clock rate and I/O speed but the 
above still show something is wrong?  What's going on here?


> You need to change the "mov R1, # 0x24" instruction to 
> change the prescaler ("divider") value.
> For example, 0x25 sets P to 2 instead of etc.

Not as I read the User Manual. 0x24 is P=1, M=4.  0x25 would be P=1, 
M=5.

--- In lpc2000@yahoogroups.com, pontus.oldberg@i... wrote:
> You shouldn't have any problems at all.
> I am using the Olimex 2106-MT board together with CrossWorks and 
> everything works like a charm.I have tried compiling into all 
> different kind of targets and they all work perfectly.

I'm using the LPC-P1 (no LCD).  


> Did you remove both the DEBUG and BSL jumper ?

The DBG jumper has to be ON with the P1 board.  This pulls DBGSEL 
high to allow the JTAG interface to work.  The BSL jumper has to be 
off.

If this is a problem that only some of us are having, I'm wondering 
where the problem is?  Is it an issue with the parts?  The Olimex 
board appears to be reasonably well designed and made.  It's very 
simple.  The power supply lines are bypassed, etc.

It might be the Olimex JTAG Wiggler is the problem.  The Olimex 
website mentions the following in using the Wiggler with IAR: "driver 
for ARM-JTAG have some glitches on newer and faster computers and 
does several crashes before connect to target".  That may well be an 
IAR problem, but it's not too far off from what I'm seeing with 
CrossStudio.

It's really frustrating to have to be debugging tool/part problems 
instead of my own code.  I'd hoped the LPC parts (and certainly ARM7 
tools) were sufficiently mature to avoid this sort of thing, but that 
doesn't seem to be the case so far.  Admitedly, however, the tools 
I'm using are at the bargain end of the scale.

At 04:17 AM 4/19/04 +1000, you wrote:
>It sounds like the way you have it now, your PLL is incorrectly
>programmed, the CCO is not capable of that low frequency, thus
>the capture in range is not possible, _thus_ the PLL doesn't/can't lock.
>The ref manual specifically states that you will yield unreliable operation.

I will add here that the manual is quite correct ;)  I've had the PLL 
programmed incorrectly and the only obvious effect was to make the serial 
baud rate rather odd.  Otherwise the micro seemed to be operating properly 
and at the correct speed.  I suspect the side effect can be even more 
subtle than that.

Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,
be they legal, genetic, or physical.  If you don't believe me, try to
chew a radio signal. "

                         Kelvin Throop, III

At 09:01 PM 4/18/04 +0000, you wrote:
>PLLCFG = 0x44 (P=2, M=4): 231ns (Should be 59Mhz but is 73.5Mhz?)
>PLLCFG = 0x23 (P=1, M=4): 231ns (as above)

How do you figure 231ns is a 73.5MHz clock?

Robert


" 'Freedom' has no meaning of itself.  There are always restrictions,
be they legal, genetic, or physical.  If you don't believe me, try to
chew a radio signal. "

                         Kelvin Throop, III

I also have the same timeout errors with an Olimex LPC-P1 board and 
the Olimex JTAG cable using CrossStudio Eval.

I tried with different PC configuration (PII and PIII, Win2K and XP, 
ECP and EPP parallel port) but I gave up and I am using the RAM 
configuration for the moment.

HAO


--- In lpc2000@yahoogroups.com, "nw_mcu" <nw_mcu@y...> wrote:
> --- In lpc2000@yahoogroups.com, pontus.oldberg@i... wrote:
> > You shouldn't have any problems at all.
> > I am using the Olimex 2106-MT board together with CrossWorks and 
> > everything works like a charm.I have tried compiling into all 
> > different kind of targets and they all work perfectly.
> 
> I'm using the LPC-P1 (no LCD).  
> 
> 
> > Did you remove both the DEBUG and BSL jumper ?
> 
> The DBG jumper has to be ON with the P1 board.  This pulls DBGSEL 
> high to allow the JTAG interface to work.  The BSL jumper has to be 
> off.
> 
> If this is a problem that only some of us are having, I'm wondering 
> where the problem is?  Is it an issue with the parts?  The Olimex 
> board appears to be reasonably well designed and made.  It's very 
> simple.  The power supply lines are bypassed, etc.
> 
> It might be the Olimex JTAG Wiggler is the problem.  The Olimex 
> website mentions the following in using the Wiggler with 
IAR: "driver 
> for ARM-JTAG have some glitches on newer and faster computers and 
> does several crashes before connect to target".  That may well be 
an 
> IAR problem, but it's not too far off from what I'm seeing with 
> CrossStudio.
> 
> It's really frustrating to have to be debugging tool/part problems 
> instead of my own code.  I'd hoped the LPC parts (and certainly 
ARM7 
> tools) were sufficiently mature to avoid this sort of thing, but 
that 
> doesn't seem to be the case so far.  Admitedly, however, the tools 
> I'm using are at the bargain end of the scale.

--- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@a...> 
wrote:
> At 09:01 PM 4/18/04 +0000, you wrote:
> >PLLCFG = 0x44 (P=2, M=4): 231ns (Should be 59Mhz but is 73.5Mhz?)
> >PLLCFG = 0x23 (P=1, M=4): 231ns (as above)
> 
> How do you figure 231ns is a 73.5MHz clock?

If you do the math on the numbers I posted they are all 17 clock 
cycles--i.e. a 14.7Mhz clock is 68ns * 17 = 1156ns and 231ns/17 = 
73.5Mhz.

I've further confirmed the numbers by measuring the Timer0 period 
with a scope.  I've also confirmed the crystal circuit is always 
running at 14.7mhz.  I admit this seems REALLY strange!  Can anyone 
else reproduce these results?  Are lots of people running their 
LPC210X's at 5X instead of 4X and not realizing it?  Seems unlikely 
but I've double checked the measurements I've posted and they're 
accurate.  

The only thing I can think of is I somehow got a 2106 with bad PLL 
logic and/or damaged mine by using a too low Fcco?  Both seem pretty 
unlikely, however.

Thanks guys (Kris,  Leon, and  nw_mcu),
for enlightening details (better than Philips docs) on PLL operation. I 
have been using Rowleys Crossworks with an Ashling Eval board (using 
McCraiger Wiggler) for a week or two now and have not experienced any of 
the problems you two have run into. Yesterday, (concerned over your 
reports) rebuilt my app for flash vs RAM and both it and Rowley samples ran 
OK so suspect issues are with either Olimex board startup or imported 
startup code. I changed my PLL settings to same as you guys mentioned and 
still no problems running at either 14 or 58 MHz whether from flash or RAM.

Tech support from Rowley has been good for me so far so I would expect 
you'll be getting reply from them soon. Their CTL libraries provide basic 
RTOS functionalities (scheduling, prioritizing of IRS's, etc) ithout the 
baggage of full blown RTOS  All (80% done in this time) for my first Arm 
project (Second will likely need more/real RTOS though as will need 
queues/TCP-IP stacks etc).(Maybe someone at Rowley listening so can 
provide/raise profits) All in all Crossworks to me seems very nice product 
at very nice price.

That said, where I'm stumbling now is on RTC operation. If anyone has 
figured this out and can provide any sample code or better info than in 
Philip's docs. (all I need to do is find out if new second) it would be 
greatly appreciated.

Regards and TIA,
Mike

--- In lpc2000@yahoogroups.com, "nw_mcu" <nw_mcu@y...> wrote:

OK, I've now confirmed the PLL problem! With my 2106, I get the 
following results:

PLL OFF: 1150ns (14.7Mhz)
PLLCFG = 0x61 (P=3, M=1): 577ns (should be 14.7Mhz but is 29Mhz)
PLLCFG = 0x21 (P=1, M=1): 577ns (as above)
PLLCFG = 0x42 (P=2, M=2): 384ns (Should be 29.4Mhz but is 44Mhz)
PLLCFG = 0x43 (P=2, M=3): 288ns (Should be 44Mhz but is 59Mhz)
PLLCFG = 0x44 (P=2, M=4): 231ns (Should be 59Mhz but is 73.5Mhz)
PLLCFG = 0x24 (P=1, M=4): 231ns (as above)

The above shows that P doesn't change the clock rate (we presume only 
Fcco), while the M value does but not in the way Philips documents.

Here's my set up to test the clock rate:

PINSEL0 = 0x0800; //enable MAT0.1 output pin
T0TCR = 0; //Timer off 
T0PR = 0; //No prescale
TOMR1 = 100; //match every 100 counts
T0MCR = 0x10; //clear timer on match1
T0EMR = 0x0fff; //enable match outputs
T0TCR = 1; //start the timer

while(1);

I put a Agilent digital scope on the MAT0.1 pin and the above code 
yields a MAT0.1 period of 1360nS using PLLCFG = 0x24.  If you divide 
by 100 you get a 13.6nS clock or 73.53 Mhz!

If you disable the PLL, you get a period of 6.80uS which is a 14.7Mhz 
clock.

So, for my LPC2106 at least, I'm absolutely convinced that a 
multiplier (M) of 4 is really 5!  The following Philips formula is 
wrong:

   cclk = M * Fosc

The correct forumla appears to be:

   cclk = (M + 1) * Fosc

As I said earlier, it's possible I somehow have a bad part, so if 
someone else could confirm this, that would be helpful?  If what I've 
measured is generally true, the Philips data is wrong and that's 
really disturbing for such a critical parameter.  The power 
consumption listed is also wrong (30ma at 60Mhz is really 44ma but 
that's already been discussed).  At 75Mhz, my 2106 draws 58ma.

At 12:04 AM 4/19/04 +0000, you wrote:
>--- In lpc2000@yahoogroups.com, "nw_mcu" <nw_mcu@y...> wrote:
>
>OK, I've now confirmed the PLL problem! With my 2106, I get the
>following results:
>
>PLL OFF: 1150ns (14.7Mhz)
>PLLCFG = 0x61 (P=3, M=1): 577ns (should be 14.7Mhz but is 29Mhz)

Ah, I see what's happening,  I should have clued in earlier

PlLLCFG of 61 gives PSEL of 3, MSEL of 1

That gives a P of 8 and and M of 2

In turn Fcco is 470MHz (outside the valid range) and cclk is 29.4 MHz

If you check http://www.aeolusdevelopment.com the newlib-lpc source has an 
example of how to set up the PLL.

Robert



" 'Freedom' has no meaning of itself.  There are always restrictions,
be they legal, genetic, or physical.  If you don't believe me, try to
chew a radio signal. "

                         Kelvin Throop, III

Hi,

> The demo code supplied by Rowley has P set to 1 and M set to 4
> (PLLCFG = 0x24) in their example giving 59Mhz with a 14.7Mhz
> crystal.  This gives a Fcco of 117Mhz which should be illegal.

It is correct.
Look at the formula in the ref manual, there is a fixed divide value of 2,
which I suspect
is to ensure a 50% dutycycle on the clock.
IOW, your Fcc= 117 * 2 = 234 MHz.

The mov R1,#24, and #25 example I gave was indeed incorrect, it
was "off the cuff". I DID say it was an example, 0x25 will set M to 5
instead of 4.

I understand your frustration, but please don't take it out on me,
a "thank you" would have been welcome instead of arguing :-)

-- Kris

> I also have the same timeout errors with an Olimex LPC-P1 board and
> the Olimex JTAG cable using CrossStudio Eval.
>
> I tried with different PC configuration (PII and PIII, Win2K and XP,
> ECP and EPP parallel port) but I gave up and I am using the RAM
> configuration for the moment.
>
> HAO

Hi,

As I had mentioned before, if you're able to briefly assert P0.14 LOW
while you start the debug (ie. while loader.exe is programming), then that
will solve the problem, I'm quite sure.
I have NO idea why this should be.
I've reported this erroneous condition to Rowley Asscs ages ago, but they
weren't
able to reproduce the problem I think. I run on WIN98SE, so it's good to see
that the good old "it's because you're running 98SE" argument indeed is
irrelevant,
since the problem is observed on the _magic_ XP as well  :-)
In my situation I used a homebrew "wiggler" I quickly banged together on
some veroboard for the test.

-- Kris

At 12:04 AM 4/19/04 +0000, you wrote:
>--- In lpc2000@yahoogroups.com, "nw_mcu" <nw_mcu@y...> wrote:
>
>OK, I've now confirmed the PLL problem! With my 2106, I get the
>following results:

I thought I'd repeat the calculation for the rest of your results.


>PLL OFF: 1150ns (14.7Mhz)
>PLLCFG = 0x61 (P=3, M=1): 577ns (should be 14.7Mhz but is 29Mhz)
>PLLCFG = 0x21 (P=1, M=1): 577ns (as above)

I get Fcco of 235.2 MHz (in range), and cclk of 29.4 MHz

>PLLCFG = 0x42 (P=2, M=2): 384ns (Should be 29.4Mhz but is 44Mhz)

Fcco = 352.8 MHz (out of range), cclk 44.1 MHz

>PLLCFG = 0x43 (P=2, M=3): 288ns (Should be 44Mhz but is 59Mhz)

Fcco = 470.4 MHz (out of range), cclk = 58.8 MHz

>PLLCFG = 0x44 (P=2, M=4): 231ns (Should be 59Mhz but is 73.5Mhz)

Fcco = 588 MHz (way out of range), cclk = 73.5 MHz

>PLLCFG = 0x24 (P=1, M=4): 231ns (as above)

Fcco = 294 MHz (out of range), cclk = 73.5 MHz

Apparently there is a fair amount of margin in the PLL specs since it still 
seems to work even when Fcco is >2x the max.  Of course there's always the 
peripheral side effects to worry about.

However, the expected clock frequency matches the measured frequency in all 
cases.

Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,
be they legal, genetic, or physical.  If you don't believe me, try to
chew a radio signal. "

                         Kelvin Throop, III

--- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@a...> 
wrote:

> >PLLCFG = 0x61 (P=3, M=1): 577ns (should be 14.7Mhz but is 29Mhz)
> 
> Ah, I see what's happening,  I should have clued in earlier
> 
> PlLLCFG of 61 gives PSEL of 3, MSEL of 1
> 
> That gives a P of 8 and and M of 2

Call me embarrassed!  Thanks everyone for your help on this.  I 
totally missed the lookup tables that translate the bits for the P 
and M values.  Things make much more sense now!  

The CrossWorks startup code contains these lines:

  /* Configure PLL Multiplier/Divider */
  mov r1, #0x24 /* multipler = 4, divider = 1 */

I both assumed the values were chosen for a 14.7 Mhz crystal as this 
is the frequency found on most demo boards (for serial port reasons) 
and I also read the comment as M = 4 and P = 1.  In reality, those 
are just the raw bit values MSEL and PSEL and they get translated 
into M = 5 and P = 2 by the magic tables.

I and others still seem to be stuck with the flash loading problem, 
but at least the PLL is working right now!  Progress!

Thanks again to all.

Firstly, are you using the latest 1.2 RC release 
(http://www.rowley.co.uk/arm/arm_1_2_0.zip)? This version has 
improved LPC2000 support.

It sounds like you are having reliability problems with the 
Wiggler/JTAG connection. Try the following:

1. Turn on automatic load verification (Tools | Option | Target | 
General | Enable Load Vericiation) so you can tell if the program in 
memory matches the executable file.
2. Reduce the JTAG clock frequency (increase the JTAG Clock Divider 
target property).
3. If your still having problems, reduce the length of your parallel 
port cable as much as possible (I personally always plug the Wiggler 
directly into the back of the PC).

Regards,

Jon Elliott
Rowley Associates

--- In lpc2000@yahoogroups.com, "nw_mcu" <nw_mcu@y...> wrote:
> I'm evaluating Rowley's CrossStudio and am having serious problems. 
> I'm using the Olimex 2106 demo board and the Wiggler JTAG 
interface.  
> I'm new to the LPC devices and GCC but not MCUs in general.
> 
> The tools and board work mostly as expected when using RAM for the 
> codespace. When using FLASH, however, several unexpected things are 
> happening: 
> 
> 1 - CrossStudio always successfully writes the Loader and erases 
the 
> flash but usually fails with various timeout errors when it tries 
to 
> write the code to the erased flash.  Once in a while it will work.  
> I've tried both ECP and EPP settings for the parallel port and 
> various settings in CrossStudio with no change.  The 2106 is also 
> hung up when this happens and needs to be reset.  The wiggler 
> sometimes needs to be power cycled as well, and a few times, 
> CrossStudio stopped responding for good and had to be shut down 
with 
> the task manager.  NOT GOOD!
> 
> 2 - When I can manage to write the code to flash, the startup code 
> doesn't seem to be linked correctly. I can change the PLLCFG 
> multiplier from 0x24 (4X) to 0x21 (1X) and the chip still runs at 
59 
> Mhz.  I'm importing the assembly startup file into CrossStudio as 
> specified in the docs, and it assembles just fine.  I'm new to this 
> toolchain so I'm not sure where to look?  I can't even figure out 
how 
> to tell the linker to generate a list file in CrossStudio?  This 
> happens with the demo projects and when I start a new project from 
> scratch.
> 
> 3 - Things get even more strange. When I can write to flash, my 
code 
> runs at 59mhz as outlined above (no matter what I set the PLL to).  
> If I disconnect the wiggler and reset the board, the clock rate 
drops 
> down to 1X (14.7 Mhz)!  Again, this is true no matter what the PLL 
is 
> actually set to in the startup file!
> 
> I've verified the above problems are not related to the memory 
> accelerator (which is disabled in all cases) or MAMTIM (flash wait 
> states).  Those things work normally when I change them in the main 
> code.
> 
> It's almost as if, even when set to use flash, CrossStudio is still 
> telling the GCC linker to use RAM for some of the code?  The 
> documentation isn't very clear on the CrossStudio-to-GCC 
interface.  
> The problem with CrossStudio timing out when trying to write the 
> flash is especially annoying as I usually have to power cycle the 
> board (wiggler) and start over.
> 
> Frankly, I'm not impressed with the way code is loaded into the LPC 
> parts.  It's a bit of mess compared to other processors that have 
> much more direct (and bulletproof) programming interfaces.
> 
> Does anyone have any ideas or suggestions?  This is really 
> frustrating!  CrossStudio is priced right, and I otherwise like it 
so 
> far, so I hope I'm just doing something wrong?

If you have access to the ISP UART it's possible to download and execute
a program in RAM that turns on the secondary JTAG port. The enabling of
the pins appears to survive a reset so this only has to be done on power
up. Some of
our customers are using this with CrossWorks to program the flash and
debug without losing too many IO lines.

Regards
Michael

>   Date: Sun, 18 Apr 2004 20:20:38 -0000
>   From: pontus.oldberg@...
>Subject: Re: Help: Rowley CrossStudio & Wiggler Problem
>
>You shouldn't have any problems at all.
>I am using the Olimex 2106-MT board together with CrossWorks and 
>everything works like a charm.I have tried compiling into all 
>different kind of targets and they all work perfectly. Mind you, i 
>have not messed around with the PLL yet, but i'm getting there.
>
>Did you remove both the DEBUG and BSL jumper ?
>
>The only snag i found was that the control pins to the LCD pins were 
>located on the ETM, so i can not debug my LCD driver. Bummer ;-)
>
>Regards
>/Pontus

> 2 - When I can manage to write the code to flash, the startup code 
> doesn't seem to be linked correctly. I can change the PLLCFG 
> multiplier from 0x24 (4X) to 0x21 (1X) and the chip still runs at 
59 
> Mhz.  I'm importing the assembly startup file into CrossStudio as 
> specified in the docs, and it assembles just fine.  I'm new to this 
> toolchain so I'm not sure where to look?  I can't even figure out 
how 
> to tell the linker to generate a list file in CrossStudio?  This 
> happens with the demo projects and when I start a new project from 
> scratch.

Try

View | Symbol Browser

Regards
Michael

Message: 1
   Date: Mon, 19 Apr 2004 12:10:03 +1000

   From: "microbit" <microbit@...>
Subject: Re: Re: Help: Rowley CrossStudio & Wiggler Problem

Kris/HAO

As Jon suggested - try the 1.2 version. We've added a lot more
initialisation to the reset script to try to get something that
resembles a reset on the LPC2000.

Regards
Michael

  TargetInterface.setNSRST(0);
  TargetInterface.setNSRST(1);
  TargetInterface.delay(100);
  TargetInterface.trst();
  TargetInterface.setICEBreakerBreakpoint(0, 0x00000000, 0xFFFFFFFF,
0x00000000, 0xFFFFFFFF, 0x100, 0xF7);
  TargetInterface.waitForDebugState(1000);
  TargetInterface.getICEBreakerRegister(5); /* Clear out Debug Comms
Data */
  TargetInterface.pokeWord(0xE0000000, 0); /* Reset Watchdog */
  TargetInterface.pokeWord(0xE0028008, 0); /* Reset IODIR */
  TargetInterface.pokeWord(0xE002C000, 0); /* Reset PINSEL0 */
  TargetInterface.pokeWord(0xE01FC000, 0); /* Reset MAMCR */
  TargetInterface.pokeWord(0xE01FC080, 0);  /* Reset PLL */
  TargetInterface.pokeWord(0xE01FC08C, 0xAA);  /* Feed PLL */
  TargetInterface.pokeWord(0xE01FC08C, 0x55);  /* Feed PLL */
  TargetInterface.pokeWord(0xFFFFF014, 0xFFFFFFFF); /* Disable all
interrupts */
  TargetInterface.setICEBreakerBreakpoint(0, 0x00000000, 0x00000000,
0x00000000, 0x00000000, 0x000, 0x00);


> I also have the same timeout errors with an Olimex LPC-P1 board and
> the Olimex JTAG cable using CrossStudio Eval.
>
> I tried with different PC configuration (PII and PIII, Win2K and XP,
> ECP and EPP parallel port) but I gave up and I am using the RAM
> configuration for the moment.
>
> HAO

Hi,

As I had mentioned before, if you're able to briefly assert P0.14 LOW
while you start the debug (ie. while loader.exe is programming), then
that
will solve the problem, I'm quite sure.
I have NO idea why this should be.
I've reported this erroneous condition to Rowley Asscs ages ago, but
they
weren't
able to reproduce the problem I think. I run on WIN98SE, so it's good to
see
that the good old "it's because you're running 98SE" argument indeed is
irrelevant,
since the problem is observed on the _magic_ XP as well  :-)
In my situation I used a homebrew "wiggler" I quickly banged together on
some veroboard for the test.

-- Kris

Thanks Michael.
Was this around just recently ? I only saw 1.1.4 ?

-- Kris

----- Original Message ----- 

From: "Michael Johnson" <mpj@...>
To: <lpc2000@yahoogroups.com>
Sent: Tuesday, April 20, 2004 4:14 AM
Subject: [lpc2000] Re: Re: Help: Rowley CrossStudio & Wiggler Problem


> Message: 1
>    Date: Mon, 19 Apr 2004 12:10:03 +1000
>    From: "microbit" <microbit@...>
> Subject: Re: Re: Help: Rowley CrossStudio & Wiggler Problem
> 
> Kris/HAO
> 
> As Jon suggested - try the 1.2 version. We've added a lot more
> initialisation to the reset script to try to get something that
> resembles a reset on the LPC2000.
> 
> Regards
> Michael

--- In lpc2000@yahoogroups.com, "microbit" <microbit@c...> wrote:
> Thanks Michael.
> Was this around just recently ? I only saw 1.1.4 ?

Scroll down the page. It's at the bottom.

Leon

--- In lpc2000@yahoogroups.com, "microbit" <microbit@c...> wrote:
> Thanks Michael.
> Was this around just recently ? I only saw 1.1.4 ?

Scroll down the page. It's at the bottom.

Leon

> --- In lpc2000@yahoogroups.com, "microbit" <microbit@c...> wrote:
> > Thanks Michael.
> > Was this around just recently ? I only saw 1.1.4 ?
> 
> Scroll down the page. It's at the bottom.
> 
> Leon

Thanks Leon, I didn't see it - the home page only mentioned
V1.1.
Found it at bottom of DL page, getting hardly 0.6 Kb/s though :-)
Is the server cooking ? heh.

73s
Kris

Hi Michael,

> As Jon suggested - try the 1.2 version. We've added a lot more
> initialisation to the reset script to try to get something that
> resembles a reset on the LPC2000.

Tried it out - works like a charm now re. the Flash download.

-- Kris

--- In lpc2000@yahoogroups.com, "microbit" <microbit@c...> wrote:
> Hi Michael,
> 
> > As Jon suggested - try the 1.2 version. We've added a lot more
> > initialisation to the reset script to try to get something that
> > resembles a reset on the LPC2000.
> 
> Tried it out - works like a charm now re. the Flash download.
> 
> -- Kris

Taking your suggestion, I also downloaded the Rowly software. I think
its better out of the box than the ARM SDK. 

For instance ARM shipped me a Multi ICE and the drivers for Real ICE. 

Makes it hard.

Art