Re: [avrdude-dev] [bug #35208] avrdude 5.11 on freebsd 8.2-STABLE does not reset Arduino Uno properly

[Bob Frazier]

On 01/02/12 11:13, David A. Mellis so wittily quipped:
> Follow-up Comment #1, bug #35208 (project avrdude):
>
> If I remember correctly, "setting" DTR and RTS actually lowers them to ground
> and "cleaning" them pulls the pins high.  Which means that the current avrdude
> code should pull the lines high and then low, triggering a reset.  Bob, did
> you check this on a scope or meter?  What'd you see?

after scoping it, I saw the 'low' value when RTS/DTR is set to 1 on the 
Uno.  Also saw many other anomolies, including reset signals that 
weren't "low enough" to actually reset, followed 50 msecs later by one 
that was [looked like cap wasn't discharging properly].  Also saw 
inconsistent behavior in resets in some cases, where the board did a 
reset, but the programmer still failed to work.  Conclusion:  reset 
timing still the problem, but not for the reasons I originally thought 
it was.  My scope isn't that good (it's a DSO Nano) so it's hard to 
capture logic with it.  But I was able to better observe SOME of the 
behavior by writing a test application in C.

> If I'm right, then this patch could have the effect of generating two falling
> edges on some platforms, which might be problematic.

I think I found a BETTER solution than the previous one:  rather than 
add a 'set to 1' before the set to 0, set to 1 sequence, you increase 
the time delay between setting to zero, and POSSIBLY reduce the time 
delay after the set to 1.  I attempted to re-program the 'Blink' sample 
several times in a row, and ended up seeing a number of failures to 
program, but no 'failure to reset' (watched lights blink on Uno during 
reset process).  My conclusion:  the reset timing is actually wrong 
(needs more time to discharge capacitor).  Hopefully this doesn't break 
earlier arduinos, but I see no reason why it would.  I'll also have to 
try this on the 7.2-STABLE machine that uses the libusb port.  I doubt 
I'll see anything bad there, either.

Is there some justification for the 50msec delay after setting RTS/DTR 
to 1?  Just curious.

I'm attaching a different patch file that increases the time delay 
between DRT+RTS '0' and '1' to 250msecs.  I'll experiment with this some 
more to make sure it works correctly.  So far I'm getting consisting 
flashing, and no failures.

patch-arduino.c
Description: Text Data