Lpc2000

It's a marginal issue that shows on some machines I think.
I don't know whether it's the OS, or I/F or what, but I get the EXACT
same misbehaviours as nw_mcu gets.
For me, briefly holding P0.14 LOW when starting debug fixed it.

Of course the DBGSEL is set properly, it wouldn't work at all
otherwise !

-- Kris



----- Original Message -----
From: <pontus.oldberg@...>
To: <lpc2000@yahoogroups.com>
Sent: Monday, April 19, 2004 6:20 AM
Subject: [lpc2000] 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
>
>
> --- 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
>
>
>
> --------------------------------------------------------------------------
------
> Yahoo! Groups Links
>
>   a.. To visit your group on the web, go to:
>   http://groups.yahoo.com/group/lpc2000/
>
>   b.. To unsubscribe from this group, send an email to:
>   lpc2000-unsubscribe@yahoogroups.com
>
>   c.. Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
>
>