Lpc2000

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


--- In lpc2000@yahoogroups.com, "microbit" <microbit@c...> wrote:
> > That would be hard to do with CrossStudio because it writes 
> > the loader and code back-to-back.  To make things more 
> > difficult, the Olimex board has a jumper rather than a switch 
> > for that function.
> 
> That's what I had to do.
> For some mysterious reason, having it in bootloader mode
> when loader.exe is downloaded into RAM, but then letting go
> of P0.14 works fine.
> Maybe wire in a pushbutton, just to work around it.
> I had to wire nTRST to the reset pin (ie. NOT pull it up to Vcc).
> 
> > If that's really the way the chip works, Philips should be 
> > ashamed of themselves!  As I said in my previous message, 
> > I'm NOT impressed with the way the LPC parts are programmed.  
> > It's a poor design especially for debugging and high-speed 
> > production programming.
> 
> It works a treat with the Nohau/Seehau/Hitech C environment,
> so it's not Philips' fault.
> I suspect it's a marginal timing issue on CrossWorks.
> Maybe Paul or Michael can shed some light there.
> I do recall they use the loader like this because the TAP
> needs to be reset or some such.
> 
> 
> > > Do you maybe disable the PLL here after recompiling ?
> > > Most likely the Flash download "looks" succesful, but it's not.
> > 
> > That's what I suspect is going on.  That part of the code is 
> > still living in RAM even after you tell it to use FLASH.  
> > This seems to be a bug in the way CrossStudio is building the 
> > make (and/or other) file(s) for the linker?
> 
> Nope, the building and linking is fine.
> I think this is because you're not setting P properly.
> I set up the PLL in my sys_init() start code in C.
> It's preferable not to depart from the vendors' default startup
> code, it will bite you in the bum later.
> 
> > Yes, the startup code executes the magic sequence after 
> > establishing the PLL settings.  The PLL should be properly 
> > initialized EVERY time the chip is reset.  I don't understand 
> > how the startup code is only executed sometimes, or perhaps 
> > there are two different copies of it (one in RAM and one in 
> > FLASH)?  Again, this seems like a bug in how the code is built?
> 
> As above.
> 
> -- Kris