For Bertrik or anybody else who's familiar with LPCUSB: is there flow
control built into USB and/or LPCUSB? I know a device can return
"NAK" to tell the host it can't accept/send data during a frame, so it
seems like it would inherently handle buffer full, etc.

I'm writing a USB bootloader for my Olimex LPC-H2148 board because
it'll be installed in a system without an RS232 port. I have
LPCUSB-serial working, and I can interact at human speed easily, but
for sending a new image to run, I'd like to do "cat image.hex >
/dev/ttyACM0" However, when I do this, the bootloader crashes after
receiving a line or two of the hex file. (I'm checking with debug
messages on a serial port that's temporarily connected.)

My next step is to check with JTAG to see where it's dying, but I
thought somebody might know of fundamental problems that I'll have to
work around.

Thanks,
dave m.
Start a New Thread

On Thu, Oct 16, 2008 at 1:25 PM, thirdshoedrops wrote:
> For Bertrik or anybody else who's familiar with LPCUSB: is there flow
> control built into USB and/or LPCUSB?

I think the lpcusb CDC code is pretty simplistic implementation
of the CDC-ACM class.

You may want to read the excellent example/tutorial by Tsuneo
here in order to understand USB CDC-ACM better.
http://www.cygnal.org/ubb/Forum9/HTML/000945.html

For your application, I think you have to define your
own protocol (command from host and response
from the device). For example you can use Xon/Xoff.

A PIC example is here (no special host program necessary).
http://www.thebytefactory.com/dl_codeloader.asp
Xiaofan

Start a New Thread

Hi,

USB has built in flow control handled entirely by the hardware. Thus
when your boot-loader is busy the HW will send NAK:s on the USB.

I think your problem lies somewhere else. For example the core is not
able to fetch code from the FLASH while doing a write/erase operation.
If you interrupt handlers are executed from FLASH then you must disable
them during these operations.

You can try to receive to a memory buffer without touching the FLASH
just to see if the problem relates to FLASH programming or not.

Foltos

thirdshoedrops wrote:
> For Bertrik or anybody else who's familiar with LPCUSB: is there flow
> control built into USB and/or LPCUSB? I know a device can return
> "NAK" to tell the host it can't accept/send data during a frame, so it
> seems like it would inherently handle buffer full, etc.
>
> I'm writing a USB bootloader for my Olimex LPC-H2148 board because
> it'll be installed in a system without an RS232 port. I have
> LPCUSB-serial working, and I can interact at human speed easily, but
> for sending a new image to run, I'd like to do "cat image.hex >
> /dev/ttyACM0" However, when I do this, the bootloader crashes after
> receiving a line or two of the hex file. (I'm checking with debug
> messages on a serial port that's temporarily connected.)
>
> My next step is to check with JTAG to see where it's dying, but I
> thought somebody might know of fundamental problems that I'll have to
> work around.
>
> Thanks,
> dave m.
> Start a New Thread

--- In l..., Foltos wrote:

> I think your problem lies somewhere else. For example the core is not
> able to fetch code from the FLASH while doing a write/erase operation.
> If you interrupt handlers are executed from FLASH then you must disable
> them during these operations.
>
> You can try to receive to a memory buffer without touching the FLASH
> just to see if the problem relates to FLASH programming or not.

Thanks, but I'm already doing that! (Both the disabled interrupts
during Flash operations and the "just receive data, check the checksum
and discard it.") Everything works if I send slow (either hand typing
or delaying a few ms at the end of every line) but not if I try a "cat
> /dev/tty".

--- Xiaofan wrote: ---
> For your application, I think you have to define your
> own protocol (command from host and response
> from the device)....

For somebody who claims not to be a programmer, you sure know a lot
about programming! Thanks for the good pointers!

d.
Start a New Thread

--- In l..., "thirdshoedrops" wrote:
>
> For Bertrik or anybody else who's familiar with LPCUSB: is there flow
> control built into USB and/or LPCUSB?
> ...
> My next step is to check with JTAG to see where it's dying...

Ha ha! I win at microcontrollers!

When the stock LPCUSB receive FIFO fills up, it just returns from the
next BulkOut call without doing anything. This leaves the data in the
USB controller endpoint, which causes the controller to stall the USB
host. Then, when the FIFO drains ... um ... nothing happens.

I added some simple code to mark the fifo as jammed, and when the
getchar() routine finds that there's no data available but the fifo
had jammed at some point in the past, it re-invokes BulkOut. Piece o'
cake!
Start a New Thread