EmbeddedRelated.com
Forums
Memfault State of IoT Report

Help: Rowley CrossStudio & Wiggler Problem

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


An Engineer's Guide to the LPC2100 Series

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:

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 , 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 , "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:
>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" <>
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" <>
To: <>
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" <>
> 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 , "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 , "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



Memfault State of IoT Report