Regression between uno and uno R2 VALIDATED. HARDWARE PROBLEM CONFIRMED

retrolefty:
Very interesting symptom, sorry I don't own a Uno (R1 or R2) to help with the diagnosis. I hope we get a independent validation (reproducible) of the bug and a explanation/resolution of the cause.

At the moment, we are two with that problem.
I yet don't know if i should hope more will.. :s

Would you be able to try the new bootloader mentioned here: http://arduino.cc/forum/index.php/topic,64105.0.html on one of the problem boards? (I don't have any theory as to why this would result in a change, but it would be worth a try...)

Thanks for the idea.

Unfortunatly, i only have UNO boards around and no isp.

Any hint on the possibility to use them anyway, one day?
(btw, i tried, just in case http://arduino.cc/en/Tutorial/ArduinoISP was outdated, but got this error http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1287836171 )

i had a good look over the schematics of the R1 and R2 today, and did spot one flaw that might be worth checking up on.

on both R1 and R2 boards there is a link on the schematic missing between GND and UGND pins on the 8U2. if this link is absent, and power is being supplied through the USB connector, then the 328p will likely be getting bad power via internal connects within the 8U2. on the pictures i've found of UNOs on the net, they all seem to have this link present, but that does not guarantee it being there on every manufacturing run of the board. if it is missing on the schematic files (i only looked at the pdf's), then it's possible the link was added during layout and later got 'lost' at some revision point.

the link is located on the reverse side of the PCB, appearing to be between a track running from pin 4 of the USB connector and the surrounding ground plane. check that it is there, and if not then try bridging with a solder blob across the adjacent pads.

someone else with a UNO in front of them might care to comment a little more.

It's okay for that link. I have it on both revisions, identical.

The problem also occurs when powering via the external power input. I do use a medical grade 12v power supply for my tests too. Same problems arise when using usb and external supply.

Here are the results from the scope:
All on R2 board, watch out for the different time scales.

pic1: 5V taken from the power pin on board without resistor
pic2: 5V taken from the power pin on board WITH resistor
pic3: reset taken from the reset pin on board, without resistor
pic4: reset taken from the reset pin on board, WITH resistor

unfortunatly, my scope only peaks at 5mhz, so i cannot check the crystal.

same tests, on R1 board:

pic1: 5V taken from the power pin on board without resistor
pic2: 5V taken from the power pin on board WITH resistor
pic3: reset taken from the reset pin on board, without resistor
pic4: reset taken from the reset pin on board, WITH resistor

Reset looks pretty different...
However, on R2, using a resistor or not does not change the values by much. Not much enough imho to make the difference each time.

power looks reasonably ok, though that reset looks incredibly ugly!! the arduino designers should have placed a diode from RESET to +5V so as to clamp any overshoot on the pin, preventing it from rising more than 0.6v above the supply rail. does the RESET line look the same on the R1 board?

last but not least, here is an other test on R2...
this time, i test the reset signal on powerup, then resetting using the button, without powering down in between.

pic1: first reset, no resistor
pic2: manual reset, no resistor
pic3: first reset, with resistor
pic4: manual reset, without resistor

i think we might have a winner!!

try placing a diode between RESET and +5V on the POWER connector, with the cathode (end with the bar) towards the +5V.

i agree that reset is pretty ugly, however there seems to be only very negligible difference between signals with and without the resistor...

i'd be betting my money on the overshoot of the reset pulse causing the problem. the overshoot, in turn, being caused by the 1k pulldown resistor charging up the 0.1uf series capacitor (by default, the 8U2 pins are open-circuit until configured).

a pulse that goes above the supply rail will do unpredictable things to the 328p, and the presence of your 4k7 pullup merely enables a set of conditions that direct the over-voltage pulse towards a lock-up condition.

ROBERT, YOU ARE THE WINNER !!!!!

This is the problem that caused our headache.
You can't imagine how happy i am.

Now, time to get the dev team so that they can create a R3... :slight_smile:

:slight_smile: these are the moments that i live for - i'm a test engineer by trade, though a slightly unemployed one right now.

i'd suggest you add that diode (a 1N914 would be fine) to the back of all your UNO boards (R1 and R2) if you intend sending them out to customers as part of a product. now the interesting question will be... will the arduino team recall all the R2 boards?

Heh. This, for sure is a good enough reason to recall them. But do they have money to?

edit: i wonder what's the best way to catch their attention, in case they missed this topic.. tweeter?

i'm picking suppliers will have to provide rework instructions to customers, and existing stock will need to have diodes added. the problem seems to have also struck folks with various 'shields' that have pullups present on non-PWM digital pins.

rattle the bars, make noise. i've posted a followup to my posting on the adafruit forums describing problem and fix - hopefully the owners of that site (who sell lots of arduinos) will feed word back up the supply chain.

Now they have reasons to hire you. (hint, hint :wink: )

edit: oh, and i think you might want to add a link on the adafruit forums so that the team can follow the whole discussions and tests.

excellent piece of research work there
especially since you found the real problem

well done, sir!

a pulse that goes above the supply rail will do unpredictable things to the 328p, and the presence of your 4k7 pullup merely enables a set of conditions that direct the over-voltage pulse towards a lock-up condition.

Maybe not so unpredictable. Isn't a higher then Vcc voltage to the reset pin the method that puts the chip into it's high voltage programming mode? As I understand it the reset pin does not have an internal positive clamping diode to Vcc (unlike the normal I/O pins, just because of the higher then Vcc on reset method to enter HV programming mode.

As far as the 'fix' :

try placing a diode between RESET and +5V on the POWER connector, with the cathode (end with the bar) towards the +5V.

Would this then prevent the arduino board from being able to be programmed via the 'high voltage' method? Granted that would represent a very small population of users, however I've seen at least one shield based high voltage programmer avalible for sale. It allows those that have managed to 'brick' their processor by errors in fuse settings, i.e. change reset pin to be a I/O pin, etc.

Lefty

retrolefty:
[...]
Maybe not so unpredictable. Isn't a higher then Vcc voltage to the reset pin the method that puts the chip into it's high voltage programming mode? As I understand it the reset pin does not have an internal positive clamping diode to Vcc (unlike the normal I/O pins, just because of the higher then Vcc on reset method to enter HV programming mode.
[...]
Lefty

good point! i wonder if HV programming mode looks at the non-PWM digital pins, and all-zeros represents a no-operation/exit, while anything else (ie, a 4k7 pullup present) initiates something else?

there are indeed more complicated solutions than a simple diode-fix, that would still allow for the HV programming, though none that can be retrofitted easily to an existing board. the 'correct' solution would be to replace the 0.1uF capacitor and 1k pulldown with a monostable.

as an aside, that 1k pulldown wastes 5mA of current drain.