Lpc2000

Hi, 

> > Why not implement a CDC class, just as I did?
> 
> If by CDC class you mean a Connected Device Configuration 
> class (thanks google!), that appears to be a next step to be 
> done after solving the issue at hand.  I'm surmising that 
> from reading about CDCs online.

Yes, CDC devices are things like serial lines, modems, and Ethernet
adapters.

> > Why not power the board and then you can debug USB 
> insertion and trace 
> > things...  Alternatively, use serial I/O to dump data.
> 
> The program problems are due to communication over serial 
> while using USB, so I think using serial I/O to dump data 
> will be a new set of bugs.  I wasn't too elaborate on this 
> before because the problems are program specific (and I hate 
> when people dump their code and ask for someone to fix it).

Ok, well, I see no issues at all with interrupt-driven I/O on two LPC
comms channels and the USB with timers firing.  Hence, I believe you
have a software problem as I can send and receive data over both lines,
with software flow control if I want, and also service USB requests to
dump data into the UARTs (as I implement a CDC class).

> > > Does anyone have suggestions, keywords to search for, or 
> articles to 
> > > help me understand power-on operation and how to trace it?
> > 
> > POR will either go into the bootloader or into your own 
> code.  Check 
> > the ISP jumpering.  If you want a nice 2148 board, try the 
> IAR LPC2148 
> > board which Olimex made for them.  It's a nice board, has 
> an LCD for 
> > debugging if you need it, and can be powered from various sources 
> > which allows you to easily debug self-powered devices.
> > 
> > --
> > Paul Curtis, Rowley Associates Ltd  http://www.rowley.co.uk 
> CrossWorks 
> > for MSP430, ARM, AVR and now MAXQ processors
> >
> 
> I'm hoping to stay with the board and IDE I'm evaluating for 
> a little longer.

You can stay with that, just purchase an IAR board.  There's no inherent
"you must buy this compiler" associated with the Keil tools.

>  Since my device will be eventually powered 
> from the USB, externally powering the device will only 
> postpone the issue until later when the code is more complex.

I find that debugging self-powered devices *much* easier than
bus-powered devices.  I recommend that you do this.

> Thanks for the suggestions though.

Invest in a USB analyzer is another suggestion.  I can't do without
mine.

> Is there publically available source for the Philips 
> bootloader?  Is there a way to trace the bootloader through 
> JTAG?  My board doesn't have an ETM connector.

Why do you need to do this?  The bootloader isn't traceable in some
parts (so I'm told by one of the engineers here).  It doesn't gain you
much anyway, does it, as it's not part of the problem?

--
Paul Curtis, Rowley Associates Ltd  http://www.rowley.co.uk
CrossWorks for MSP430, ARM, AVR and now MAXQ processors