|
--- 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. |
|
|
Help: Rowley CrossStudio & Wiggler Problem
Started by ●April 17, 2004
Reply by ●April 18, 20042004-04-18
Reply by ●April 18, 20042004-04-18
|
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 |
Reply by ●April 18, 20042004-04-18
|
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 |
|
|
Reply by ●April 18, 20042004-04-18
|
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. |
Reply by ●April 18, 20042004-04-18
|
--- 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. |
|
|
Reply by ●April 18, 20042004-04-18
|
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 |
Reply by ●April 18, 20042004-04-18
|
--- 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. |
|
|
Reply by ●April 18, 20042004-04-18
|
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 |
|
|
Reply by ●April 18, 20042004-04-18
|
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 |
Reply by ●April 18, 20042004-04-18
|
> 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
|
