Lpc2000

Mr. Curtis and Mr. E. Janitor,

I appreciate the suggestion to to supply outside power.  I was
initially resistant to it, but reading your comments on the matter
made me remember that problems should be solved in smaller bites than
I was trying to tackle.  After applying continuous power I discovered
the problem was due to too small of a stack.  

Thank you greatly for your comments on the matter.  I also plan to
learn more about CDCs.

As for my original question: Where does a bootloader start executing
the code?  I'm now assuming that the bootloader always starts at 0x0
reset_handler, however my ULINK JTAG may not be able to take control
of the execution fast enough to stop the code at a power-on reset.

JP

--- In lpc2000@yahoogroups.com, "Paul Curtis" <plc@r...> wrote:
>
> Hi, 
> 
> > > I find that debugging self-powered devices *much* easier than 
> > > bus-powered devices.  I recommend that you do this.
> > 
> > Agree. Using self power allows you to debug through things 
> > better because you can handle the connection stuff easier.
> >
> > Debugging USB is challenging because the timing of the USB 
> > protocol prevents you from single stepping/breaking.
> 
> Interrupt-driven serial I/O during enumeration is how I debug setup
> problems.
> 
> > > > Thanks for the suggestions though.
> > > 
> > > Invest in a USB analyzer is another suggestion.  I can't do without 
> > > mine.
> > 
> > What analyser do you use?
> 
> The Ellisys Tracker 110.  Nice piece of hardware, simple to use.
> 
> > Something I have found **very** useful is libusb (Google will find). 
> > This allows you to do host-side stuff without USB drivers and 
> > can make for more controlled test apps etc. 
> 
> We found that libusb works well on some PCs with some drivers, and
> completely nukes other PCs.
> 
> --
> Paul Curtis, Rowley Associates Ltd  http://www.rowley.co.uk
> CrossWorks for MSP430, ARM, AVR and now MAXQ processors
>