bugAVR Downloader/UploaDEr - Bugs: bug #41857, avr109 atmega2564rfr2 erase...

 
 

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

bug #41857: avr109 atmega2564rfr2 erase timeout to short

Submitter:  Georg von Zengen <oni>
Submitted:  Thu 13 Mar 2014 03:46:13 PM UTC
   
 
Category:  None Severity:  3 - Normal
Priority:  5 - Normal Item Group:  None
Status:  None Privacy:  Public
Assigned to:  None Originator Name:  oni
Open/Closed:  Open Release:  None
Programmer hardware:  Device type: 

Jump to the original submission

Fri 16 May 2014 07:00:36 PM UTC, comment #13: 

Hi,

I appended a new version of my patch which applies to revision 1304.

regards
Georg von Zengen

(file #31392)

Georg von Zengen <oni>
Wed 02 Apr 2014 03:49:02 PM UTC, comment #12: 

First of all, 8 lines are simple.
Second, in my opinion sending SIG-TERM to a process should not be the normal way to end it in error cases.
No, I do not have a stk500 but jtagICE II does not time out.

NO, the erase cycle duration does not depend on the clock rate.
As I wrote before it is "7.3ms - 8.9ms per page" (values copied from the datasheet).
More information about flash erase can be found here:
http://en.wikipedia.org/wiki/Flash_memory
The only clock rate dependent operation is to increase the page counter.

"So if choosing this fix, it should be deployed to at least avr910 also." I do not have the any avr910 based system, so I can not test it. If you have such devices: feel free to do so.
 
"Whould be a nice improvement for the old protocol."
NO, it will cause in compatibility with other software like avr-studio.

Georg von Zengen <oni>
Wed 02 Apr 2014 12:48:42 PM UTC, comment #11: 

Georg,
for me the reason was keep it simple. A longer timeout is only valid for not connected/responding programmers and can be stopped with ctrlC

And this is may be a "general" fix for programmers which use serial protocol instead of fixing one by one. I expect more programmers running in this problem (at least avr910 is one)

After having a look to the behavier of stk500 shows, that it does a retry for several times before it quits with an error. (or is stopped with ctrlC ) The interval itself seems to be 5 seconds.
So does stk500 delete the atmega2564rfr2 without timeout? Do you have a stk500 for testing this?

The Method of 10 times wait per # of pages depends on clock rate of the Controller as far as I understand your post. What about 4 or 1 MHz?

So if choosing this fix, it should be deployed to at least avr910 also.

If this problem really hits only avr109 and avr910 why not pimping the erase command with a kind of status bar (running dots) and setting the timeout for this erase command to a higher time for next Chips and slower clockrate? Whould be a nice improvement for the old protocol.












Klaus Leidinger <kllei>
Wed 02 Apr 2014 11:51:58 AM UTC, comment #10: 

I vote for the dynamic solution because its more future-proof. In general giving the user feedback in case of unexpected/faulty behavior as soon as possible is the better solution than let the program hang forever. So we should look if other programmers might have similar problems.

Dennis Reimers <dreimers>
Wed 02 Apr 2014 09:00:11 AM UTC, comment #9: 

I dislike the option to generally raise the serial timeout to 10 seconds. When I have a new untested chip/board it happens a lot, that my programmer times out. When this timeout increases to 10 seconds the whole avrdude will feel way more unresponsive.

Also as Georg pointed out, when new chips with even more flash arrive then this timeout has to be increased again (20 seconds for 2048 pages).

The proposed solution with a dynamic timeout calculated with the number of flash pages seems best to me as it does not hurt the responsiveness of avrdude on small chips and makes it possible to program devices with arbitrary large flash sizes on avr109 programmers.

In any case this is a workaround for a design flaw in the avr109 specification.

Yannic Schröder <yan_nic>
Wed 02 Apr 2014 07:47:34 AM UTC, comment #8: 

What is your reason against the "complicated" (8 lines) solution which solves the problem and not only delays its appearance.

Georg von Zengen <oni>
Wed 02 Apr 2014 07:00:57 AM UTC, comment #7: 

My vote for the simple solution to match the timeout to other serial programmers. Thanks Jörg for pointing this out.

Klaus Leidinger <kllei>
Wed 02 Apr 2014 07:00:23 AM UTC, comment #6: 

One of the problems with avr109 is that it has only a chip erase command which only sends a reply when the memory is erased completely. That is why the process bar of the erase command simply jumps to 100% immediately. I think other programmers are responding in between.

Using some kind of extendet parameter to increase the timeout is hacky in my opinion. Avrdude should support all AVRs with all Atmel Programmers (avr109 is a app-note) with the "default" parameters.

My argument against setting the timeout to 10s is that in cases of errors the time out for all commands is twice as long as it is now. Additionally The same problem will appear again for AVRs with 2048 pages. By now there are no such AVRs but using a solution where the next problem is foreseeable is not an option. Especially if there is another solution without this problem which does not have any side effects.

Georg von Zengen <oni>
Wed 02 Apr 2014 05:42:24 AM UTC, comment #5: 

Other programmers (like JTAGICE, AVRISPmkII) simply have much
longer default timeouts, so the timeout is never hit even by
the somewhat longer erase time of this device.

The serial communications timeout is meant just as a fallback
if nothing responds at all at the other end, so extending it
to some seconds should normally not hurt.

Given that, why not take the simple solution (as already
suggested in the report itself), and bump it to 10 s?

Joerg Wunsch <joerg_wunsch>
Group administrator
Tue 01 Apr 2014 09:49:30 PM UTC, comment #4: 

Hi,
avrdude already accepts programmer specific parameters with the -x 'extendet parameter'
http://www.nongnu.org/avrdude/user-manual/avrdude_4.html#Option-Descriptions
and
http://www.nongnu.org/avrdude/user-manual/avrdude_5.html#Programmers-accepting-extended-parameters

So this should be the place for a "extend_delay' or any similar command.
Just my 2 cents

How do other  programmers handle the longer delay time of this chip?

Klaus Leidinger <kllei>
Tue 01 Apr 2014 07:47:42 AM UTC, comment #3: 

Hi,

any comments about my patch?

Georg von Zengen <oni>
Thu 13 Mar 2014 09:10:31 PM UTC, comment #2: 

setting the timeout for the programmer will also increase the time for fault detection for all AVRs.
The patch I attached implements a fourth idea.
For the butterfly chip erase function it takes the number of flash pages and multiplies it with 10. If this is higher the the default timeout it is applied.
For a chip with 1024 pages like the 2564rfr2 that means ~10s timeout.
I think a multiplier of 10 is a good value because it corresponds with my observations and the 7.3ms - 8.9ms per page erase mentioned in the datasheet.

(file #30888)

Georg von Zengen <oni>
Thu 13 Mar 2014 03:55:38 PM UTC, comment #1: 

3rd idea: add an adjustable timeout option to the config syntax,
so this can be configured on a per-programmer basis.

Joerg Wunsch <joerg_wunsch>
Group administrator
Thu 13 Mar 2014 03:46:13 PM UTC, original submission:  

An atmega2564rfr2 is not able to erase its program flash in under 5s when running at 8MHz.
That leads into a serial read timeout when using an avr109 like bootloader.

I have two ideas to fix this:
1. set timeout to 10s, will increase the time to wait for all AVRs if a command really fails.
2.introducing a "wait longer" character like '!' to tell avrdude to wait a bit longer. This adds some kind of "non-standard" thinks to the avr109 protocol of avrdude.
Which of these ideas would you prefer or are there other/better ideas?


Georg von Zengen <oni>

 

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

Attached Files
file #31392:  serial_timeout.patch added by oni (1KiB - text/x-patch - appling to rev 1304)
file #30888:  timeout.patch added by oni (633B - text/x-patch)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by dreimers (Posted a comment)
  • -email is unavailable- added by yan_nic (Posted a comment)
  • -email is unavailable- added by yan_nic
  • -email is unavailable- added by kllei (Posted a comment)
  • -email is unavailable- added by joerg_wunsch (Posted a comment)
  • -email is unavailable- added by oni (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 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2014-05-16 oni Attached File- Added serial_timeout.patch, #31392
    2014-04-02 yan_nic Carbon-Copy- Added -email is unavailable-
    2014-03-13 oni Attached File- Added timeout.patch, #30888

    Back to the top

    Powered by Savane 3.13-cf05.
    Corresponding source code