Regression between uno and uno R2 VALIDATED. HARDWARE PROBLEM CONFIRMED

does anyone know if there has been any action from the 'powers that be' over this - it's been a couple of weeks now, long enough to identify and quantify the problem, and verify the fix. i do note that a number of folks around the place are reporting problems with UNOs not talking to their PCs, and wonder how many are linked to reset issues covered in this thread.

I've submitted Google Code Archive - Long-term storage for Google Code Project Hosting.
I don't know for sure if that's a good place to submit HW bugs, but I don't see an official alternative.

westfw:
I've submitted Google Code Archive - Long-term storage for Google Code Project Hosting.
I don't know for sure if that's a good place to submit HW bugs, but I don't see an official alternative.

well, a week has passed, and apart from someone confirming the reset problem on a duemilanove (!) the google code 'issues' page (above) has fallen silent. i really do find myself wondering if anyone who should care does?

am also seeing various folks on here and elsewhere having major problems talking to their arduinos, and nobody offering any concrete solutions. it seems to me that hooking up an arduino to your PC should be straightforward and simple. for each platform (windows, linux, mac) there should be a simple procedure to test drivers and hardware, that works independently of the arduino IDE - for instance loop back RxD and TxD and run a small program that simple writes text and verifies it returns to provide a 100% confirmation of driver + serial hardware.

i wonder if at least some of the strife folks are seeing is their 328 processor being incapacitated (in a not-easily reversible way) by a spike on the RESET line followed by 'random' data sent to the arduino as the IDE tries to communicate.

I had some communication with the arduino team, which by the way confirmed a R3 uno that will include a diod fix.

I, too, would like an open discussion on that matter. At least a public sign of activity on this topic would be a nice move. Silently correcting a problem is not really what an open source project should do imho.

foubarre:
I had some communication with the arduino team, which by the way confirmed a R3 uno that will include a diod fix.

I, too, would like an open discussion on that matter. At least a public sign of activity on this topic would be a nice move. Silently correcting a problem is not really what an open source project should do imho.

Could someone describe the diode fix, can someone participating sum up?

Could someone describe the diode fix, can someone participating sum up?

Wiring a diode from the reset pin to +5vdc (cathode lead to +5v) clamps any voltage higher then +5vdc going to the reset pin. This prevents the +10vdc pulse from the auto-reset cap from causing the problem stated in this thread. It's treating the symptom rather then the cause, but is simple and effective.

Lefty

Thanks lefty,This in replacement of the pullup resistor in the same configuration?

Boz:
Thanks lefty,This in replacement of the pullup resistor in the same configuration?

No, pull-up resistor remains. The diode serves a voltage clamping function, but it can't provide a pull-up voltage.

Lefty

Thanks again lefty, just wanted to confirm.

I have posted a photo showing the modification on this thread:
http://arduino.cc/forum/index.php/topic,68936.0.html

Guillaume

This prevents the +10vdc pulse from the auto-reset cap from causing the problem stated in this thread ... consistently make the 328 chip power up into some kind of 'locked-up' condition

Enter Programming Mode ... 3. Wait 20 - 60 ?s, and apply 11.5 - 12.5V to RESET.

I suspect the "locked-up" condition is parallel programming mode. I wonder if that's how the bootloader gets erased?

As good a theory as any. I always wondered how bootloaders got corrupted, because as far as I know there is no way a arduino sketch can blow up a bootloader?
Lefty

retrolefty:

Could someone describe the diode fix, can someone participating sum up?

Wiring a diode from the reset pin to +5vdc (cathode lead to +5v) clamps any voltage higher then +5vdc going to the reset pin. This prevents the +10vdc pulse from the auto-reset cap from causing the problem stated in this thread. It's treating the symptom rather then the cause, but is simple and effective.

I just came across this thread after acquiring an Uno R2. The coupling capacitor used for the auto-reset feature kind of bugs me: disabling auto-reset (as required by certain applications) involves overloading - albeit briefly - the the pin on the ATmega8U2. As does the proposed diode-clamp.

This situation calls for a proper solution. Switching the reset pin via a transistor entails no risk of voltage spikes, doesn't impede high-voltage programming, and can be disabled with a simple short. Excuse the scribble:

The disadvantage is that the logic of the auto-reset signal is inverted (high -> reset). Of course this can be corrected in the 8U2 firmware, but it's not a solution for boards which use external serial interfaces. These boards could use a second transistor to invert the auto-reset signal. Any thoughts?

For auto-reset to work correctly, it has to cause a reset pulse only during the transition of the signal from the 8u. that's because the host side software doesn't "toggle" the pin, it just changes the state as a result of "opening" the virtual serial port. If you're willing to make the host-side software specifically arduino-aware, you can just connect the 8u pin direction to the 328 reset pin, and use some other SW mechanism to create the reset pulse...

that's because the host side software doesn't "toggle" the pin, it just changes the state as a result of "opening" the virtual serial port.

I thought the arduino IDE (or is it AVRDUDE?) did perform an explicit DTR pulse right before performing the upload operation, rather then just relying only on the opening of the comm port by the OS?

Lefty

Ah, good point Westfw. Ok, here's another version. This one requires no modification of the 8U2 soft, and is also compatible with other commonly used serial interfaces.

It uses 3 extra components over the current version of the Uno: two 10k resistors and a transistor. The other components are already available at suitable positions on the board, including the op-amp. The reset pulsing remains exactly as on the Uno-R2, but the LM358 can withstand any over-voltage glitches applied to its input. The transistor allows external signals to be applied to the Reset pin without risk of damage.

-Tim

I thought the arduino IDE (or is it AVRDUDE?)

AVRDUDE is the culprit.

did perform an explicit DTR pulse

The Windows version pulses DTR and CTS for the "arduino" programmer type; the type used by Arduino 0022.

I'll investigate the *nix version tonight.

any more progress on this one? or is europe still on holiday?!

Nope,nope.
And due to lack of communication, the uncertainty it casts on the projects running on arduino, i've jumped off the boat.
I certainly don't want to be lost in the wild with a provider. Even if i had some discussions with the team.
Good luck everyone.

{EDIT}
To be specific, i choose other hardware not because the huge merits of arduino decreased. It is still a great platform, with lots of great things to offer. However, it was not the right choice for me, in my particular context.
I've had some discussions with the team, which helped me knowing their progress on the issue. We have some different vision about communication, that's all.

bump... once again, has there been any further progress? i still see postings all over the place from folks who can't program their UNO, etc boards, and nearly zero mention of adding a diode between RESET and 5V being offered. now i know that this diode will not fix every failure being reported, but i do strongly feel that adding a diode will help at least some people.