bugAVR Downloader/UploaDEr - Bugs: bug #43626, Inconsistent timeouts in stk500v2

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #43626: Inconsistent timeouts in stk500v2

Submitter:  Matthijs Kooijman <matthijs>
Submitted:  Mon 17 Nov 2014 04:42:50 PM UTC
   
 
Category:  None Severity:  3 - Normal
Priority:  3 - Low Item Group:  None
Status:  Wont Fix Privacy:  Public
Assigned to:  joerg_wunsch Originator Name:  Matthijs Kooijman
Open/Closed:  Closed Release:  None
Programmer hardware:  Device type: 

Wed 19 Nov 2014 05:23:52 PM UTC, comment #3: 

OK, I added a respective comment, pointing to this bug report,
so anyone interested could read our discussion later on.

Joerg Wunsch <joerg_wunsch>
Group administrator
Wed 19 Nov 2014 05:07:55 PM UTC, comment #2: 


> Do you have any indication this situation (character received

by ser_posix, but then thrown away due to being older than
two seconds) is really triggered in any practical situation,
or is this rather a theoretical possibility?

No, it's just something I noticed while looking at the code. I did have some timeout-related problems, but I don't think this actually influences it.

I don't mind to keep it like this now, though perhaps adding a comment here or there might help prevent future confusion (people thinking there is a retry after 2s while it's really after 5s or something)? Just a suggestion :-)

Matthijs Kooijman <matthijs>
Wed 19 Nov 2014 04:47:38 PM UTC, comment #1: 

I can see what you mean, but hesitate to change something
there, as it requires a lot of testing against a number of
possible programmer implementations.

Do you have any indication this situation (character received
by ser_posix, but then thrown away due to being older than
two seconds) is really triggered in any practical situation,
or is this rather a theoretical possibility?

Joerg Wunsch <joerg_wunsch>
Group administrator
Mon 17 Nov 2014 04:42:50 PM UTC, original submission:  

While investigating a problem, I noticed the timeouts for stk500v2_recv are a bit inconsistent. In particular, ser_posix defines:

    long serial_recv_timeout = 5000; /* ms */

While stk500v2.c defines:

    #define SERIAL_TIMEOUT 2

In practice, I think this means that when no data is being received, serial_recv blocks for 5 seconds. However, when a byte (that is not the final byte in the packet) is received, > 2 seconds after stk500v2_recv was called, it returns a timeout immediately.

Effectively this means that there's 3 seconds spent waiting for data this won't be processed anyway (unless it's the last byte).

Additionally, it seems that the 5 second timeout coincides with the timeout specified by AVR068 for "data" packets and it seems useful to let avrdude timeout (and thus retry) before the stk500 times out.

> The total timeout period is from a command is sent to the answer must be
> completely received. The total timeout period is 200 ms for the
> CMD_SIGN_ON command, 5 seconds for the CMD_READ/PROGRAM_FLASH/EEPROM
> commands, and 1 second for all other commands.

Matthijs Kooijman <matthijs>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by joerg_wunsch (Posted a comment)
  • -email is unavailable- added by matthijs (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2014-11-19 joerg_wunsch StatusNeed Info Wont Fix
        Open/ClosedOpen Closed
    2014-11-19 joerg_wunsch Priority5 - Normal 3 - Low
        StatusNone Need Info
        Assigned toNone joerg_wunsch

    Back to the top

    Powered by Savane 3.13-caa5.
    Corresponding source code