Lpc2000

I'm evaluating the Keil MCB2140 board and uVision3 to read serial
input and transmit it to the USB port of a PC.  Seeing as how Keil
generously already wrote software to mount an MCB2140 as a USB HID
device and separately to communicate with interrupts via UART, you'd
think this would be easy.

It's not for me.  I've pasted the two programs together and I'm
tracking down a resulting bug that locks up the system.  The bug is a
result of some memory location being incorrect.  I can't say too much
on the bug itself because I can't trace the program from the moment of
power-on.  That is where I need help.

The USB operation requires unplugging the USB cable to the board and
plugging it back in so that the USB PC host will begin communication.
 Since this powers off and on the board, I expected the board to reset
at 0x0.  Again, I was wrong.  Power-on does not do what pressing reset
does.  I'm guessing that the bootloader (v2.11) remaps something, but
I really don't know.  There is no battery visible on the board to
preserve a volitile memory location, and the bug appears whether the
JTAG is connected or not (to weed out JTAG power preserving state).

Does anyone have suggestions, keywords to search for, or articles to
help me understand power-on operation and how to trace it?

Thanks,

JP

PS: Unfortunately, I don't see the USB peripheral supported in the
simulator, so that doesn't appear to be an option.

Hi, 

> I'm evaluating the Keil MCB2140 board and uVision3 to read 
> serial input and transmit it to the USB port of a PC.  Seeing 
> as how Keil generously already wrote software to mount an 
> MCB2140 as a USB HID device and separately to communicate 
> with interrupts via UART, you'd think this would be easy.

Why not implement a CDC class, just as I did?

> It's not for me.  I've pasted the two programs together and 
> I'm tracking down a resulting bug that locks up the system.  
> The bug is a result of some memory location being incorrect.  
> I can't say too much on the bug itself because I can't trace 
> the program from the moment of power-on.  That is where I need help.

Ok.

> The USB operation requires unplugging the USB cable to the 
> board and plugging it back in so that the USB PC host will 
> begin communication.
>  Since this powers off and on the board, I expected the board 
> to reset at 0x0.  Again, I was wrong.  Power-on does not do 
> what pressing reset does.  I'm guessing that the bootloader 
> (v2.11) remaps something, but I really don't know.  There is 
> no battery visible on the board to preserve a volitile memory 
> location, and the bug appears whether the JTAG is connected 
> or not (to weed out JTAG power preserving state).

Why not power the board and then you can debug USB insertion and trace
things...  Alternatively, use serial I/O to dump data.

> 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

--- In lpc2000@yahoogroups.com, "Paul Curtis" <plc@r...> wrote:
>
> Hi, 
> 
> > I'm evaluating the Keil MCB2140 board and uVision3 to read 
> > serial input and transmit it to the USB port of a PC.  Seeing 
> > as how Keil generously already wrote software to mount an 
> > MCB2140 as a USB HID device and separately to communicate 
> > with interrupts via UART, you'd think this would be easy.
> 
> 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.

...<snip>...
 
> 
> 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).

> > 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.  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.

Thanks for the suggestions though.

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.

JP

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

> >  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.

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.
> 
> > Thanks for the suggestions though.
> 
> Invest in a USB analyzer is another suggestion.  I can't do without
> mine.

What analyser do you 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. 

Depending on what you're doing you may never have to write any drivers 
and libusb might be enough for everything.

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

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
>

jp_thrower wrote:

>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.
>  
>
It's not an issue with the speed of the JTAG cable - this is what the 
ARM NTRST pin should be used for i.e. to enable debugging from RESET. 
Either all the LPC2xxx boards we have are incorrectly wired (not 
unlikely) or this pin is initially used by Philips to put magic code 
into the chip that subsequently renders the NTRST pin (hence debug from 
RESET) unusable. A clarification from Philips would be appreciated here.

Michael

>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
>>
>>    
>>
>
>
>
>
>
>
>
> 
>Yahoo! Groups Links
>
>
>
> 
>
>
>
>
>  
>