Regression between uno and uno R2 VALIDATED. HARDWARE PROBLEM CONFIRMED

would the same apply to FT232RL driven chips?

No. But none of those seem to be exhibiting the problem...

westfw:

would the same apply to FT232RL driven chips?

No. But none of those seem to be exhibiting the problem...

can you explain why they wouldn't have the same problem?

mmcp42:

westfw:

would the same apply to FT232RL driven chips?

No. But none of those seem to be exhibiting the problem...

can you explain why they wouldn't have the same problem?

have a look back at reply #53 from retrolefty (and the following couple of messages). he saw some aberrant behaviour from an Arduino board that had an FT232 fitted, it just took a little more digging to expose it. so the problem is not exclusive to the UNO, but in the case of the UNO R2 more obvious in its manifestation.

No. But none of those seem to be exhibiting the problem...

he saw some aberrant behaviour from an Arduino board that had an FT232 fitted, it just took a little more digging to expose it. so the problem is not exclusive to the UNO, but in the case of the UNO R2 more obvious in its manifestation.

If you read back over my prior posts you will see that I could consistently make the 328 chip power up into some kind of 'locked-up' condition, by just by having a 4.7k pull-up resistor wired to pin 4 and plugging the board into the PC usb and then a PC terminal program was opened. The PC would report a valid USB connection being established, but the sketch (the simple serial loopback test) would NOT start automatically. The symptom would not be present if the pull-up resistor is removed and the testing redone. So it takes a combination of starting with a inital power-up of the board and then opening some application that attempts to auto-reset the board, it fails on first attempt and only a manually forced auto-reset or a manual button reset clears the condition. Without the pull-up or with a diode installed the problem can't be recreated.

This was on a bog standard 'official' Arduino 2009 board using a FTDI chip. Pressing the manual reset button would successfully restart the sketch (or generating a DTR on signal would also 'un-lock' the board) without having to quit the PC serial terminal application.

A diode is a simple and effective fix, but how to get that info out to the arduino community at large (both users and manufacturers) and having to consider this kind of a possible failure mode when trying to help others having weird unexplainable/illogical problems that may or may not be related to this failure mode, will I suspect be a challenge for a long time to come.

It's kind of like the 'lost my bootloader' reports we use to get frequently in the past. Reburning the bootloader would often get the user back in business, but I don't recall anyone ever being able to recreate a lost bootloader condition on purpose by something written in a sketch and uploaded?

Lefty

First words for some time on the subject. Now that the problem is confirmed, validated, checked and a solution has been found, what is the next step?
I, for sure, want next boards i'll purchase not to exhibit this problem and i would hate having to solder diods on each and every of them.

This situation pours some pretty cold water on heat and excitation that comes out of the arduino project. Hardware is open, everything is nice and fun but when things derail it seems that there is no-one to handle them.
Did the creators finally turned into carton box pushers and only get interested in making money out of the project?
This is pretty far from how the other open communities react. In fact, the lack of reaction is the most disturbing problem to my eyes.

How do we make sure this problem is taken in account seriously? I would like the arduino team to communicate on this.

hello foubarre

Consider that there are thousands of topics on this forum, it's impossible for us to be able to track all of them but on the website there are instructions on how to get in touch with us quickly (i.e. email team (at) arduino.cc or through twitter like you did)

email us a summary of the problem and we'll take immediate action if needed.

Did the creators finally turned into carton box pushers and only get interested in making money out of the project?

I think this is a particularly unfair statement. We're always responsive when there are issues and we've always adhered to our open source principles even when we could have made an easy buck......

m

Summary is easy and has been sent as pm, i will let you read the full details and scope captures in the pages of this thread.

Please post followups as this is going to cause lots of headaches to users around the globe.

This is pretty far from how the other open communities react.

Not really. Difficult bugs take time to address. All hardware bugs are difficult.
For example, this arduino-related gcc issue took 7 months for the compiler gurus to say that they weren't going to fix it.:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38342
(and gcc is a pretty shining example of open-source-software. There's a LOT of stuff out there written by students, released on a lark, and essentially abandoned when they graduated and got a real job. Shucks, "winavr", the packaging of gcc and related tools for AVR development on windows, was nearly abandoned.)

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