Re: [Usbpicprog-technical] Weird transient failures on some programs

[Matthijs K. <mat...@st...>]

On Mon, May 31, 2010 at 08:50:46AM +0200, Frans Schreuder wrote:
> Hi Matthijs,
> 
> The timeout used to be on 5000, but I recently changed it to 1000 due to
> a bug in the Libusb-1.0 library for Windows. This bug caused the
> connection to the bootloader to timeout on a re-connect, so I just
> skipped its error message and reduced the timeout.
So the connect to bootloader code simply retries after a timeout or something?

> If this is causing problems, I will put it back on 3000.  btw, I have tested
> it on Linux Windows and Mac, but never got an error with 1000ms. Probably
> there is some difference in the hardware.
I've just discovered another program that doesn't work with 3000, but does
work with 5000. Perhaps put it back to 5000?

It also seems the long timeout is only needed for the last block, earlier
blocks get the reply within 1000ms. In fact, the time until a reply is
received seems to increase when the last block is shorter (e.g., when there
are more 0xff's for padding). This seems counter-intuitive: If there is less
data, it takes longer.

What is the timeout for, exactly? I presume that's the time to wait for the
pic to finish programming the board and sending an USB reply message? Does it
also include the time to send the data to the board in the first place, or is
libusb / writeString synchronous for that? Is there something special the
firmware does after the last block?


Perhaps the timeout should be a parameter to readString, so it can be
increased for the last block only (or reduced for the bootloader connection
only, perhaps?) 

Gr.

Matthijs