Add -xdelay=n for -c wiring to modify sleep after dtr/rts reset #1505
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
diresi
reviewed
Sep 27, 2023
There was a problem hiding this comment.
Adding xdelay after setting RTS/DTR (physically) high didn't work for me in #1504 (comment).
The delay had to be applied before doing that.
@diresi I think this was a fluke! Look very closely at your two scope images: The 75 ms delay moved the point of setting DTR high onto the top of a voltage ripple making the RESET spike that little bit higher to just cause the AVR to enter HV programming, while the 80 ms delay moved that point into the trough of a voltage ripple just about avoiding HV programming. (Why is that reproducible? I don't know, but suspect that setting DTR low causes some inrush from RESET, and the ensuing charging the 1 µF cap ties the ripple phase locally to settinng DTR low.) Anyway, dropping Vcc (recommended) would have solved your problem (and changing the usleep() would not have mattered) and increasing Vcc by as little as 50 mV (don't do this!) would have entered into HV no matter what the usleep() before was. I have not thought about what AVRDUDE could do to help an out-of-specs over-voltage Vcc without Reset to Vcc clamp diode. But thinking about this, I now believe what really and reliably would help your board is collapsing the sleep time before setting DTR high to some, say, 0.2 ms: C9 would not have had time to charge fully (and a large cap helps here), so is only perhaps a couple of V charged, which reduces the reset voltage spike considerably. @diresi Would you mind removing the clamp diode, using |
|
I can try later today. But I gave it enough tries yesterday to at least convince myself that this sleep configuration doesn't work with unmodified GT2560 boards. |
|
Wait, do you really mean |
Yes! Actually, I think this can go down to |
|
... Even the 30 µs is conservative: this assumes that the inrush to the cap from RESET is dampened by a 30 Ohm internal resistance and a large cap of 1 µF. It will probably work with less time. |
|
I think this PR is good to have. For my Mega2560 CH340 clone, |
|
Alright, I'm back with test results. I do have some scope snaps but there's not much to see:
It seems like there's a limit how fast the RPI3 can go. |
|
That's brilliant. And exactly how I expected. So, the trick is to pluck DTR a few microseconds and not to hang around. For what it's worth I have done a little simulation of pulling DTR low for 100 µs albeit with a 100 nF/10 kΩ reset circuit:
Not much to see either, but it is clear that charging the cap only for a short time won't cause a huge spike. In this case we only have a 10% = 0.5 V spike above Vcc. With your 1 µF cap the reset spike should be much lower (as it takes 10 times as long to charge the cap). |
|
It is barely noticable, I'd say some 0.2V. |
Standard AVR reset circuits deploy a connection from the DTR/RTS line of a USB-to-serial chip to the AVR via a small capacitor, see https://onlinedocs.microchip.com/pr/GUID-F626284A-58F0-4C25-A6F3-0EA5054F3E2B-en-US-6/index.html?GUID-B80B25FF-E9D7-4766-B562-DA197B8B938C Setting DTR/RTS low once will issue a reset. Setting this signal high again after a short time ensures that a direct connection DTR/RTS to reset also works. The duration of pulling DTR/RTS low must be relatively short, say RC/10, in order to avoid a reset spike above Vcc. If Vcc exceeds 5.5 V then a full 2 Vcc reset spike can potentially trigger HV programming. See also - avrdudes#1504 (comment) - avrdudes#1505 (comment)
|
OK, we have a plan. I'll change those waiting times to 100 µs (though much smaller would also be OK). |
|
Also fixes #1503 |
|
No regression on my Mega2560 CH340 clone. |
|
No regression on a Uno clone (ATmega16U2 USB to Serial chip),
|
|
One more board: Nano FT232RL clone. |
|
So this PR is good to go from my side. |
|
FWIW I also think this PR is good. Thanks! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
For more detailed discussions see #1503 and #1504
This PR introduces a
-xdelay=...parameter for the-c wiringprogrammer; it modifies the time AVRDUDE waits after issuing a reset through plucking the DTR/RTS lines, which can be useful to adapt to the startup time of a board.