-
Notifications
You must be signed in to change notification settings - Fork 137
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[bug #41857] avr109 atmega2564rfr2 erase timeout to short #336
Comments
Joerg Wunsch <joerg_wunsch> 3rd idea: add an adjustable timeout option to the config syntax, |
Georg von Zengen setting the timeout for the programmer will also increase the time for fault detection for all AVRs. |
Georg von Zengen Hi, any comments about my patch? |
Klaus Leidinger Hi, So this should be the place for a "extend_delay' or any similar command. How do other programmers handle the longer delay time of this chip? |
Joerg Wunsch <joerg_wunsch> Other programmers (like JTAGICE, AVRISPmkII) simply have much The serial communications timeout is meant just as a fallback Given that, why not take the simple solution (as already |
Georg von Zengen 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. |
Klaus Leidinger My vote for the simple solution to match the timeout to other serial programmers. Thanks Jörg for pointing this out. |
Georg von Zengen What is your reason against the "complicated" (8 lines) solution which solves the problem and not only delays its appearance. |
Yannic Schröder <yan_nic> 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. |
Dennis Reimers 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. |
Klaus Leidinger Georg, 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. 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. |
Georg von Zengen First of all, 8 lines are simple. NO, the erase cycle duration does not depend on the clock rate. "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." |
Georg von Zengen Hi, I appended a new version of my patch which applies to revision 1304. regards
|
This seems to be in line with the following feature request. |
Help wanted from the community to check whether the issue still exists. PR (which can be new or based on the above patch) is welcome. |
This has been solved for Lines 606 to 611 in f0da9a6
This technique could be promoted from usbtiny.c's chip_erase() to the general Thoughts? |
I think this is a good idea. |
For now, other than those programmers specific to bootloaders, as far as I know, only the following prorgammer serves both bootloader and real programmer.
|
|
Turns out the increased delay needs to be done in the corresponding programmer types as was done for usbtiny derived programmers. So @mcuee's list above is very useful. |
I have had a look and followed the ideas of the original patch to address this issue, as timeout handling is different for different programmers. |
oni
Thu 13 Mar 2014 03:46:13 PM UTC
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:
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?
file #30888: timeout.patch
file #31392: serial_timeout.patch
This issue was migrated from https://savannah.nongnu.org/bugs/?41857
The text was updated successfully, but these errors were encountered: