-
Notifications
You must be signed in to change notification settings - Fork 123
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
Change Arduino auto-reset via DTR/RTS/CTS to allow direct reset connection #1262
Comments
A more general method would be to have an option
|
| my 100n cap was not big enough to reliably pull down Some USB/serial boards (eg, my beloved USB-BUB-II) do not break out the signal itself, instead they insert a cap between the DTR pad and the FTDI FT232R chip, so when you connect to a uno board you get two 100 n caps in series halving capacity. |
I like this idea. As mentioned in a few other places, I do not have good facility to test urclock/optiboot other than the Arduiuo Nano/Uno and Mega clones. For other boards I have to use manual reset. Sometimes I have to rebuild the FW with 8 seconds WDT timeout to carry out the test as I may have a slow hand. |
BTW, I have looked into the cheap USB-TTL converters sold in Taobao/AliExpress, using CH340x series, FT232BL/RL series, CP2102 and PL2303 series. There are others like CH341x, CP2104, FT232H/FT2232H/FT4232H, etc.
|
@stefanrueger and @mariusgreuel There is actually an existing issue which is basically the same. I have closed #344 so that we can have single place for this discussion. Maybe the first step is to support the following. I am thinking that an extension of the above programmers will be useful, say Affected programmers:
Possible options:
|
From #344. David Zanetti Currently two different programmer types (arduino and wiring) each individually implement RTS/DTS toggling for automatic reset into a bootloader on a target board. I'd like this to be a generic option that could be applied to any serial-based programmer, either as a command-line option or programmer config feature. It would be useful for bootloaders like xboot ( Thanks! This issue was migrated from https://savannah.nongnu.org/bugs/?42324 |
I think it is rather clear to use rts/dts/dtr to carry out the reset. @mariusgreuel has already the implementation for rts and it should be easy to extend the support to dts/dtr as aell. Just wondering how it will work if we need to support "manual reset". |
Ping @mariusgreuel and @stefanrueger to see how to progress this improvement to avrdude. It seems to be a good candidate to be included in future release of avrdude. |
Here is what I don't understand: Reset is active-low, ie pulling DTR/RTS low in direct connection to MCU reset, ie, running
works then it cannot be that this was a direct connection. I suspect (but don't know) that there is actually a cap in the line somewhere between RTS/DTR and the MCU's reset. @mariusgreuel Can you double-check the resistance, please, between the actual pad of the FTDI (or equivalent) chip's RTS/DTR pin (directly at the IC, not at a solder pad on the board) and the MCU reset pin? I really don't get how the code above would work if that was a direct connection between the serial chip's signal and AVR reset, indeed. The comments (and expected behaviour) don't match up with the code and how I think this works. |
That is good practice but will prevent HVPP programming. I've never put a clamp diode in my reset circuits and actually never had a problem with that. Also, I never put a 300 Ω or similar resistor between reset buttons and MCU reset, and that has worked OK in practice. For reference the reset circuits on my (and a lot of other!) AVR boards look like |
Slightly off-topic: @mariusgreuel Your 50 ms wait here has changed from a 250 ms wait Line 91 in 4019edf
in the current AVRDUDE codebase. I commend that because this quarter-second wait is waaaay too much. I never saw the utility of that loooong sleep in arduino_open() .
Until a couple of months ago, that is. If you reduce the 250 ms in
Synchronisation problems that last 5 s. Now if you sleep 200 ms between the two AVRDUDE calls then all is back to normal
No sync problems. Both programming sessions finish in under 1.5 seconds. This effect is special to optiboot. Other bootloaders don't exhibit the need for a sleep between AVRDUDE runs . I believe this is to do optiboots's ambition to preserve the reset causes in the MCUSR as much as possible. Now, I still haven't got my head completely around this optiboot-specific effect, but that's what I suspect that happens: the issue is that an external reset while the MCU is still in the bootloader will make optiboot not enter the bootloader but the application instead. The watchdog is still set and will trigger later in the application, upon which optiboot then decides to run the bootloader, by which time the (impatient) second AVRDUDE run will have sent its first handshake and tries to receive a character. Now the AVRDUDE timeout for reading a char is per default 5 s (see
Three timings are relevant here:
OK, this is all analysis by reading the code and trying not to get a headache while attempting to figure out what happens. TLDR; this is why I have left the 250 ms wait in the Lines 2262 to 2263 in 4019edf
(It's OK to wait before AVRDUDE exits should it have served optiboot, but it's not OK to have every programming action delayed by 200 ms at the beginning and make all these |
First thing I check is whether there is a regression with the Arduino Meag 2560 clone (using the on-board CH340). I will try out a FT232R USB to TTL adapter later. It seems to be okay. I manually patched
|
I can get it working after making the connection more secure.
|
Same for UART3.
|
Same for UART1.
|
BTW, it also helps to talk to the urboot bootloader for ATTiny13A (the flash writing issue is not with the patch but seems to be with the bootloader) |
@mcuee @mariusgreuel I have no doubt that the suggested modification works with typical reset circuits. I don't see how it can work with a direct connection.
Are you sure? Have you measured resistance directly from the AT2560 reset IC pin (not board reset header) to the FT232R DTR IC IC pin of the FT232R USB to TTL adapter (not the adapter board DTR header)? There might be an inline cap on the USB to TTL adapter. The suggested code
will reset the board (almost) all the time if there was a direct connection from FT232R DTR to ATmega2560 reset. The last command above pulls DTR low at the end of open(). That is OK if isolated by a cap. But in a direct connection this puts the board in constant reset (it's low-active!) |
I am pretty sure there is a direct short for my ATmega2560/ATTiny13A test. But I will check with a proper multimeter next week (say tomorrow or a bit later). |
Just to be on the same page, the code I proposed assumes a negative-logic USB to TTL serial adapter, high-level for RTS idle, and of course low-level to reset the AVR. With a direct connection from RTS to /RESET, the idea is to start out with a high-level, and then briefly apply a low-level pulse. When we have an Arduino Uno style circuitry with a 100n cap between the RTS output and RESET input and a pull-up on the RESET pin, I figured it makes sense to pull the RTS line high first to discharge the cap, just in case the RTS line was left at low-level state by some other tool. I agree that the comments are not quite correct for the series cap case, as we set the state of the RTS line, not the reset line. So instead of 'Set reset', 'Set RTS/DTR' is better. I think I tested the code with a direct connection to an ATtiny85 flashed with urboot, and with an Arduino Uno Rev3 as well. I never actually checked the reset level on the Arduino, I just assumed the 16U2 was a drop-in replacement for the FTDI chip they used before. Otherwise, they could have just dropped the cap (RANT: which would have made debugging so much easier - or even better, implement a composite USB device with a EDBG port and a serial port). Is this better? (don't mind the 50ms):
|
Ah, I see, that will clear the confusions. And indeed FT232R is a negative logic USB to TTL serial adapter. DTR#, RTS#, CTS#, RI#, DSR#, DCD# mentioned in the datasheets are all ACTIVE LOW signal. Same for CH340 series. Same for CP2102. I think all the popular USB to TTL chip will follow this convention (Active LOW). In that case, I think the following comments are good.
I have deleted my old comments to avoid confusions for others. |
Then the question is what will be a reliable way to reset the chip after programming. I see you have remove the following line from
|
[edit: you are right: negative logic - that explains my confusion] I have an USB BUB II with an FT232R on it and measured the RTS signal (on a lone solder pad that is directly connected to the chip): it's The |
Oooops. Measured again and more carefully. You are right @mariusgreuel @mcuee. low-active So @mariusgreuel's patch will work with direct connection. Only change I'd do is to leave the 250 ms wait in arduino.c (for the reasons explained above). Do you want to do a PR, @mariusgreuel |
@mariusgreuel Your new comments in the code are much better (though I don't know what idle-high means).
True. The discharge time is vvv small assuming the DTR/RTS signal has low-impedance. 20 ms should be more than ample. |
Currently, the Arduino and urclock programmers attempt to auto-reset the board via the RTS line, to kick it into bootloader mode. On open, the do a 'RTS=0, Sleep, RTS=1', which pulls the reset line low. On close they do a 'RTS=0', which pulls the reset line high again. In other words, during the whole operation the RTS line stays at low-level.
To avoid a continuous reset, this behavior requires a special circuit that turns the low-level signal into a low pulse. For instance, the Arduino Uno has a capacitor in between the RTS line and the reset pin.
For testing with boards that do not have the integrated RTS reset circuitry, I would like to be able to simply connect the chips reset pin to the RTS pin. However, this currently requires a similar circuit, i.e. at least a cap and a diode to clamp the voltage after the cap. I find this inconvenient, unreliable, plus I am in constant fear of damaging the chips by not connecting the diode correctly.
Side story: I had some unreliable reset behavior, so I hooked up a scope to the reset pin just to find that my 100n cap was not big enough to reliably pull down the chips reset pin. Then I saw the voltage jump up close to 8.5V, and found that my diode misplaced...
How about changing the code in
open
toI think this would work for both the 'rts-capacitor-reset' boards, as well for a direct connection.
Any thoughts?
The text was updated successfully, but these errors were encountered: