EmbeddedRelated.com
Forums
Memfault State of IoT Report

Help: Rowley CrossStudio & Wiggler Problem

Started by nw_mcu April 17, 2004
--- In , 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.



An Engineer's Guide to the LPC2100 Series

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 , "nw_mcu" <nw_mcu@y...> wrote:
> --- In , 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 , 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 , "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 , "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


> 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.
The Philips data is correct, I've used the timers enough with different
PLL settings, and the figures were always correct.
As Robert pointed out, at that phase of testing you most likely had
your Fcco out of its range.
 
Think of the cco as a VCO in a PLL.
The VCO has a particular range, and if you eg. divide the VCO output
by 10, and feed that into a phase comparator, with eg a 10 MHz reference
then - if VCO is capable of that - the PLL will phase lock it to 100 MHz.
(This is presuming that the loopfilter is correct, damping factor, VCO gain,
phase margin etc are all appropriate of coyrse).
If you were to set the divider in this example for 20, and the VCO can only
tune up to, say, 130 MHz, then the PLL will remain unlocked, and the VCO will
be free running at around ~ 130 MHz.
 
Something similar to that is happening on the LPC2106, but I suspect that the
high integration of cco and PLL + dividers causes it to go apeshit when you incorrectly
program it, which is a fair equation.
 
B rgds
Kris



Memfault State of IoT Report