--- In , "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.
> 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
Reply by microbit●April 19, 20042004-04-19
> --- 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
Reply by leon_heller●April 19, 20042004-04-19
--- 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
Reply by microbit●April 19, 20042004-04-19
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
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
Reply by Michael Johnson●April 19, 20042004-04-19
> 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
Reply by Michael Johnson●April 19, 20042004-04-19
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
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?
Reply by nw_mcu●April 19, 20042004-04-19
--- 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!
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!
