usbpicprog-technical

[Usbpicprog-technical] Weird transient failures on some programs

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

Hi,

when creating a few initial testing programs, I've been suffering from the
"Hardware should say OK" error message. After some investigation, it seemed as
if some hex files would consistently trigger this message, while others would
consistently work. Some more investigation shows that is the case that the
working programs work _most_ of the time, but not always.

I've attached two examples of a program that works most of the time (around
one in 10 tries failed so far) and another that failed on every try so far.
This was on a 16f876, using a Windows system with usbpicprog 0.4 and brand new
usbpicprog hardware. When the programming fails, I have to replug the
programmer and restart the usbpicprog application.

On a Linux system, both of the attached programs fail every time (while a
blinking led example does work).

The examples include a hex file, together with the .mbas (MikroBasic) file and
(intermediate) assembly file that they were generated from.

On a related note, I'm also seeing errors when erasing every now and then on
the Windows system. On the linux system, these have occured every time so far
(until I disabled "Erase before programming" to make things work). Not sure if
this is related, but I think it is.


Can someone try if these programs are ok or broken for them? It seems that
something in the actual hex code that somehow triggers a (timing) bug in the
usbpicprog firmware. From these examples, you might suspect the length of the
program is relevant (the breaking program is slightly shorter), but I've also
seen breaking programs that are way longer.

I've also tried to use a shorter USB cable, but that didn't seem to matter
much (initially, the problem seemed to increase, but that evened out later
on).

Any suggestions on how to debug this problem?

Gr.

Matthijs

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

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

Hi,

> when creating a few initial testing programs, I've been suffering from the
> "Hardware should say OK" error message. After some investigation, it seemed as
> if some hex files would consistently trigger this message, while others would
> consistently work. Some more investigation shows that is the case that the
> working programs work _most_ of the time, but not always.

I've mucked around in the PC application sources a bit, and it seems the error
is caused by an USB timeout in readString (which I gathered from adding a
cout line, since the wxLogError call that is in readString didn't show up
anywhere for me).

As a hack I tried increasing the USB timeout (USB_OPERATION_TIMEOUT) from
1000ms to 3000ms, which magically solved all my problems, including the
erasure problems (though I've only tested a handful times on the Linux PC, not
the Windows one).

Could it be that the USB controller is causing this? Both machines I've tested
on are laptops with very similar hardware.

Gr.

Matthijs

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

[Frans S. <fra...@gm...>]

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

Thanks for your message!

Frans

On 30-5-2010 19:26, Matthijs Kooijman wrote:
> Hi,
>
>   
>> > when creating a few initial testing programs, I've been suffering from the
>> > "Hardware should say OK" error message. After some investigation, it seemed as
>> > if some hex files would consistently trigger this message, while others would
>> > consistently work. Some more investigation shows that is the case that the
>> > working programs work _most_ of the time, but not always.
>>     
> I've mucked around in the PC application sources a bit, and it seems the error
> is caused by an USB timeout in readString (which I gathered from adding a
> cout line, since the wxLogError call that is in readString didn't show up
> anywhere for me).
>
> As a hack I tried increasing the USB timeout (USB_OPERATION_TIMEOUT) from
> 1000ms to 3000ms, which magically solved all my problems, including the
> erasure problems (though I've only tested a handful times on the Linux PC, not
> the Windows one).
>
> Could it be that the USB controller is causing this? Both machines I've tested
> on are laptops with very similar hardware.
>
> Gr.
>
> Matthijs
>   

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

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

[Frans S. <fra...@gm...>]

On 31-5-2010 10:02, Matthijs Kooijman wrote:
> 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?
>   
Yep, that's the dirty fix. But maybe if we give the delay as an argument
to readString, we can have a shorter timeout on connect.
>   
>> 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
>   
>
>
> ------------------------------------------------------------------------------
>
>   
>
>
> _______________________________________________
> Usbpicprog-technical mailing list
> Usb...@li...
> https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical
>