Lpc2000

Hi guys,

Another new member, and another problem.  I appreciate any help, and 
I hope to be able to return the favor in the future.

I am in the final stages of a project that uses a LPC2106.  Things 
work perfectly as it is, but we have recently discovered that we are 
getting low performance issues as we are running without the MAM and 
PLL.

I am currently working on trying to add in the MAM and PLL, but I 
have run into problems.  Basically what I have found is the following:

1. When running either the MAM or the PLL, interrupts from UART1 TX 
stop occurring
2. When running both the MAM and the PLL, the processor doesn't seem 
to run properly, or digital outputs no longer happen.

I am testing, using a program that does the following:
1. Clears Pin
2. Enables PLL (and or) MAM
3. Sets Pin
4. Calls function
5. Clears Pin.

The program was made to see the performance increases using the PLL 
and MAM.  When running the PLL or the MAM the program works fine.  
However, when running both the PLL and MAM, the last clear pin does 
not occur.  I'm unsure what's happening, as when I step through the 
program step by step using J-Tag, it works as expected!

When adding the PLL or the MAM into the existing project, 
communication on UART1 stops working.  The first byte is sent 
correctly, but the rest of the string (sent using the interrupt 
generated from UART1 TX) isn't sent.

I have read the Philips datasheet, and the guide from Hitex (The 
Insider's Guide To The Philips ARM7-Based Microcontrollers) and 
haven't found anything relating to the MAM or PLL and its effects on 
interrupts.

Any ideas?

Karl

--- In lpc2000@yahoogroups.com, "karlstiller" <karls@...> wrote:
>
> Hi guys,
> 
> Another new member, and another problem.  I appreciate any help, and 
> I hope to be able to return the favor in the future.
> 
> I am in the final stages of a project that uses a LPC2106.  Things 
> work perfectly as it is, but we have recently discovered that we are 
> getting low performance issues as we are running without the MAM and 
> PLL.
> 
> I am currently working on trying to add in the MAM and PLL, but I 
> have run into problems.  Basically what I have found is the following:
> 
> 1. When running either the MAM or the PLL, interrupts from UART1 TX 
> stop occurring
> 2. When running both the MAM and the PLL, the processor doesn't seem 
> to run properly, or digital outputs no longer happen.
> 
> I am testing, using a program that does the following:
> 1. Clears Pin
> 2. Enables PLL (and or) MAM
> 3. Sets Pin
> 4. Calls function
> 5. Clears Pin.
> 
> The program was made to see the performance increases using the PLL 
> and MAM.  When running the PLL or the MAM the program works fine.  
> However, when running both the PLL and MAM, the last clear pin does 
> not occur.  I'm unsure what's happening, as when I step through the 
> program step by step using J-Tag, it works as expected!
> 
> When adding the PLL or the MAM into the existing project, 
> communication on UART1 stops working.  The first byte is sent 
> correctly, but the rest of the string (sent using the interrupt 
> generated from UART1 TX) isn't sent.
> 
> I have read the Philips datasheet, and the guide from Hitex (The 
> Insider's Guide To The Philips ARM7-Based Microcontrollers) and 
> haven't found anything relating to the MAM or PLL and its effects on 
> interrupts.
> 
> Any ideas?
> 
> Karl
>

But, you haven't told us the important stuff: what crystal frequency,
what PLL setup (for a 14.7456 MHz crystal, PLLCFG=0x23 works), what
MAM setup (MAMCR=0x02 and MAMTIM=0x04 works) and what VPBDIV (0x01 works).

These values are from James Lynch's excellent tutorial. Rev 3 is here:
http://www.olimex.com/dev/pdf/ARM%20Cross%20Development%20with%20Eclipse%20version%203.pdf

There is a complete distribution of the entire tool chain somewhere. 
Search the archives here to see who hosts it.

Richard

At 10:32 PM 4/24/2006 +0000, rtstofer wrote:
>--- In lpc2000@yahoogroups.com, "karlstiller" <karls@...> wrote:
> > When adding the PLL or the MAM into the existing project,
> > communication on UART1 stops working.  The first byte is sent
> > correctly, but the rest of the string (sent using the interrupt
> > generated from UART1 TX) isn't sent.
> >
> > I have read the Philips datasheet, and the guide from Hitex (The
> > Insider's Guide To The Philips ARM7-Based Microcontrollers) and
> > haven't found anything relating to the MAM or PLL and its effects on
> > interrupts.
> >
> > Any ideas?
> >
> > Karl
> >
>
>But, you haven't told us the important stuff: what crystal frequency,
>what PLL setup (for a 14.7456 MHz crystal, PLLCFG=0x23 works), what
>MAM setup (MAMCR=0x02 and MAMTIM=0x04 works) and what VPBDIV (0x01 works).

You can definitely get odd behaviour if you operate the PLL outside of its 
range.  The CPU may run but the peripherals may behave strangely.  You can 
also look at the support routines in the newlib-lpc lib for an example that 
takes the crystal frequency and desired operating frequency as inputs and 
set the PLL registers accordingly.  That might give you a double check on 
your values.

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
http://www.aeolusdevelopment.com/

> >But, you haven't told us the important stuff: what crystal 
frequency,
> >what PLL setup (for a 14.7456 MHz crystal, PLLCFG=0x23 works), what
> >MAM setup (MAMCR=0x02 and MAMTIM=0x04 works) and what VPBDIV (0x01 
works).

Oops.. I knew I forgot something.

I'm running using an external crystal of 14.7456 MHz.  VPDIV = 0 
default -> one fourth of the processor clock.   I'm using the 
following code snippet for setting up the PLL and MAM:

// PLL
PLLCFG = 0x23;    // M = 4 P = 2 -> FOSC x 4 = 58980000(cclk)
PLLFEED = 0xAA;
PLLFEED = 0x55;   // PLL feed sequence
PLLCON = 0x1;     // habilita PLL e conecta PLL
PLLFEED = 0xAA;
PLLFEED = 0x55;   // PLL feed sequence

while( !(PLLSTAT & 0x400) );    // wait for PLL lock

PLLCON = 0x3;      // Connect PLL 
PLLFEED = 0xAA;
PLLFEED = 0x55;    // PLL feed sequence


// MAM

MAMCR = 0x00;
MAMTIM = 0x02;     // 2 processor clocks in duration for fetch cycles
MAMCR = 0x02;

I don't know if its relevant, but I'm using the IAR compiler (version 
4.30) to develop.

> also look at the support routines in the newlib-lpc lib for an 
example that 
> takes the crystal frequency and desired operating frequency as 
inputs and 
> set the PLL registers accordingly.  That might give you a double 
check on 
> your values.
> 
> Robert

Thanks, I'll check that out.

Karl

--- In lpc2000@yahoogroups.com, "karlstiller" <karls@...> wrote:
>
> > >But, you haven't told us the important stuff: what crystal 
> frequency,
> > >what PLL setup (for a 14.7456 MHz crystal, PLLCFG=0x23 works), what
> > >MAM setup (MAMCR=0x02 and MAMTIM=0x04 works) and what VPBDIV (0x01 
> works).
> 
> Oops.. I knew I forgot something.
> 
> I'm running using an external crystal of 14.7456 MHz.  VPDIV = 0 
> default -> one fourth of the processor clock.   I'm using the 
> following code snippet for setting up the PLL and MAM:
> 
> // PLL
> PLLCFG = 0x23;    // M = 4 P = 2 -> FOSC x 4 = 58980000(cclk)
> PLLFEED = 0xAA;
> PLLFEED = 0x55;   // PLL feed sequence
> PLLCON = 0x1;     // habilita PLL e conecta PLL
> PLLFEED = 0xAA;
> PLLFEED = 0x55;   // PLL feed sequence
> 
> while( !(PLLSTAT & 0x400) );    // wait for PLL lock
> 
> PLLCON = 0x3;      // Connect PLL 
> PLLFEED = 0xAA;
> PLLFEED = 0x55;    // PLL feed sequence
> 
> 
> // MAM
> 
> MAMCR = 0x00;
> MAMTIM = 0x02;     // 2 processor clocks in duration for fetch cycles
> MAMCR = 0x02;
> 
> I don't know if its relevant, but I'm using the IAR compiler (version 
> 4.30) to develop.
> 
> > also look at the support routines in the newlib-lpc lib for an 
> example that 
> > takes the crystal frequency and desired operating frequency as 
> inputs and 
> > set the PLL registers accordingly.  That might give you a double 
> check on 
> > your values.
> > 
> > Robert
> 
> Thanks, I'll check that out.
> 
> Karl
>

It is worth noting that in "MAM USAGE NOTES" on page 59 or the
September 17, 2003 User Manual, for a speed above 40 MHz, 3 CCLKs are
proposed as the MAMTIM value.  Just 'proposed', mind you.

Your MAMTIM value is probably too small.  I have had good success with
a value of 4 but I haven't tried 3.

VPBDIV can be 0x00 if you wish.  I use 0x01 so the VPB bus clock is
the same as the processor clock.

Richard

Hi guys,

I've done some more testing with some of the different values 
proposed for the PLL and MAM, but the problems continue.  From this I 
suppose that the problem with the communication may be in the UART 
settings rather than the PLL or MAM settings.

But the problem of the last pin clear is still strange...it must be 
something setting or affect I've overlooked.  Is the operation of the 
processor so sensitive to these changes?

I will do some further study of the PLL, MAM and UART, as well as my 
code and see what I can uncover.

Thanks for the help so far.

Karl
 

--- In lpc2000@yahoogroups.com, "rtstofer" <rstofer@...> wrote:
> > > also look at the support routines in the newlib-lpc lib for an 
> > example that 
> > > takes the crystal frequency and desired operating frequency as 
> > inputs and 
> > > set the PLL registers accordingly.  That might give you a 
double 
> > check on 
> > > your values.
> > > 
> > > Robert
> 
> It is worth noting that in "MAM USAGE NOTES" on page 59 or the
> September 17, 2003 User Manual, for a speed above 40 MHz, 3 CCLKs 
are
> proposed as the MAMTIM value.  Just 'proposed', mind you.
> 
> Your MAMTIM value is probably too small.  I have had good success 
with

> a value of 4 but I haven't tried 3.
> 
> VPBDIV can be 0x00 if you wish.  I use 0x01 so the VPB bus clock is
> the same as the processor clock.
> 
> Richard
>

Quoting karlstiller <karls@...>:
> I've done some more testing with some of the different values
> proposed for the PLL and MAM, but the problems continue.  From this I
> suppose that the problem with the communication may be in the UART
> settings rather than the PLL or MAM settings.

Just a thought but you don't try to use the same UART settings both before and
after setting the PLL do you?

> But the problem of the last pin clear is still strange...it must be
> something setting or affect I've overlooked.  Is the operation of the
> processor so sensitive to these changes?

Not that I've noticed.  I did see some odd behaviour when I misset the PLL and
had too high an intermediate frequency.  And I wouldn't try MAMTIM below the
recommended value at full speed.


Robert

--- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@...> 
> Just a thought but you don't try to use the same UART settings both 
before and
> after setting the PLL do you?

No no, nothing like that, just a set-up and use strategy.

After a somewhat decent sleep I will add in use of the UART in the test 
program to confirm that there is nothing in the rest of the project 
that screws up the UART interrupt.

Karl

Hey Guys,

Problem solved.  The supply of 1.8V to the processor was ok when 
running without the PLL and MAM.  When the PLL was added, the voltage 
fell to 1.3V.  Thus leading to the strange operation.

Just goes to show that when you are dealing with embedded processors 
you have to keep in mind both hardware and software.

Thanks for the help!