Regression between uno and uno R2 VALIDATED. HARDWARE PROBLEM CONFIRMED

foubarre:
We finally found that simply taking a 4.7k resistor from the board 5V to pin 7 causes the problem. On original UNO, this works.

Can you reproduce? (we can, each time, using any program, even 'blink')

Further to previous post, have replicated this simple test too - if digital pin 7 is high my Arduino Uno SMD R2 fails to run the bootloader led sequence (let alone run any sketch) after power cycling, until the reset button is pressed.

Any other Arduino Uno R2 owners able to replicate?

This ought to be impossible. The pin in question hasn't changed between the two revs of the Uno, nor does it have any relevant alternate functions. (Analog comparitor, IFF configured, one of the pins involved in parallel HV programming, which requires ~12V on RESET.)

The only thing I can think of is that the D7 trace goes "close" to the resonator pads (but in the other side of the board!)
If the resonator was somehow "iffy" (the normal fuse setting is for a "low power crystal", and I had at least one resonator on an ATmega8 board that insisted on "full swing oscillator), having a solid signal on that wire might change the behavior. But ... then I'm not sure why it would work after a manual reset (well, Vcc would presumably be more stable...)

Another possibility is that the AVR is somehow mis-progammed, or a new chip revision with bugs, or something like that.
If you take the AVR out of one of the new and misbehaving boards, and put it in a Rev1 board, does it start behaving?
Do you have a way of reading the fuses?

D7 (PD7) has an alternate function of PCINT23 (Pin Change Interrupt 23). if this interrupt has been inadvertently enabled in the bootloader, and the fact that a pin is being held high at that point constitutes a change (which may or may not be classed as a bug in the silicon), then a jump to an uninitiated interrupt vector would occur.

from the 328P docs (Rev. 8271D–AVR–05/11):
"The External Interrupts are triggered by the INT0 and INT1 pins or any of the PCINT23...0 pins.
Observe that, if enabled, the interrupts will trigger even if the INT0 and INT1 or PCINT23...0 pins
are configured as outputs. This feature provides a way of generating a software interrupt. The
pin change interrupt PCI2 will trigger if any enabled PCINT[23:16] pin toggles. The pin change
interrupt PCI1 will trigger if any enabled PCINT[14:8] pin toggles. The pin change interrupt PCI0
will trigger if any enabled PCINT[7:0] pin toggles. The PCMSK2, PCMSK1 and PCMSK0 Registers
control which pins contribute to the pin change interrupts. Pin change interrupts on
PCINT23...0 are detected asynchronously"

optiboot (which has run on ALL the Uno boards) does not enable ANY interrupts. At least not on purpose.
PD0/PD1 would be used explicitly if the bootload was compiled to use a software uart (not likely.)

Thanks for the answers. Hopefully, if standard peripherals sold by sparkfun don't work anymore, we can expect a fix rapidly.

As a note, i do not use the SMD version of uno. This, then, seems to indicate that at least it would not be due to a faulty CPU batch and that if there is a routing mistake, it has to be the same on both boards.

edit: By the way, it seems that pulling up non-PWM pins block the boot, while PWM pins don't. Any clue?

westfw:
If you take the AVR out of one of the new and misbehaving boards, and put it in a Rev1 board, does it start behaving?

I tried that. Swapping AVR from a R1 UNO to R2 UNO does not change behavior. It is not related to AVR, looks like the board itself is the culprit.

foubarre:
I tried that. Swapping AVR from a R1 UNO to R2 UNO does not change behavior. [...]

a little confused here - can you just clarify: if you swap the 328p chips over, the R1 works (is not disrupted by a pullup on D7) while the R2 stops working with the pullup present?

this might suggest a problem in the area of the USB controller the UNO uses, where the presence of the pullup affects how the bootloader responds to incoming serial traffic from the 8U2. but this still depends on the bootloader "caring" that a pullup is present.

another thing to check on - is the 328p getting good power? that is a solid 5v, preferably monitored with a scope for any spikes. remembering that the power comes via a FET that is wired up in an arrangement that has been questioned in the past.

Sorry for confusion.

a little confused here - can you just clarify: if you swap the 328p chips over, the R1 works (is not disrupted by a pullup on D7) while the R2 stops working with the pullup present?

TRUE.
And i should add "R1 still works while R2 still does not"

is the 328p getting good power? that is a solid 5v, preferably monitored with a scope for any spikes. remembering that the power comes via a FET that is wired up in an arrangement that has been questioned in the past.

It fails the same way using the USB power or external power.
As USB is done to only use power once alimentation stabilized, it should be fine. Not tested, though.

AFAIU, FET is not implied when board is powered through usb, right?

foubarre:
[...]
AFAIU, FET is not implied when board is powered through usb, right?

quite the opposite (i think), the FET bridges between USBVCC and +5V. when USB power is present current flows through the body-diode of the FET, supplying power (less 0.6v) to the LM358. this checks to see if VIN is absent, and if it is absent turns on the FET. if VIN is present, the FET remains turned off, preventing flow from the external source back into the USB connector (which is a big no-no). this is in theory, there are conditions when it fails to work as designed.

looking at the schematics of the R1 and R2 UNO, the only material difference i can see is that the R2 has a pull-down resistor on the 8U2's CTS output (which just happens to be D7!), this pin being used to provide a reset signal from the Arduino IDE to the 328p.

try the following: short the RESET line (which is active low) of the 328p to +5V. easiest way to do this is to bridge between pins 1 and 3 on the "POWER" connector (i''m assuming you have the UNO schematics there). then see if things start working correctly.

ed: oh, and DO NOT press the reset button on the board while the above short is in place!!!

Sorry, it did not help.
What i did to short them is to insert a flat-ended screwdriver in the power connector, then test for shortage, then plugged USB.

however, i found something interesting... Not willing to burn my macbook air usb port, i tried various machines.
All gave incorrect result, whatever the power shortage status was, EXCEPT one which gave me constant valid result, without even shorting the power connector.

It is a gamer PC based on an asus rampage 3 extreme motherboard and i'm using the front usb connectors.
As far as i've seen, they are normal usb connectors.

I'm pretty puzzled, to be honest.

foubarre:
What i did to short them is to insert a flat-ended screwdriver in the power input, then test for shortage, then plugged USB [...]

oops, not quite what i meant. the link from RESET to +5V is to (while fitted) prevent the 8U2 from being physically able to reset the 328p. the UNO does not need to be connected to the USB port during this test, using the external power socket would be fine and look for the LED blinking (or not).

my reasoning is that it seems one possible cause of the problem you're seeing is the 8U2 repeatedly generating reset pulses that are stopping the 328p from running. assuming (1) no direct fault in the bootloader, and (2) no bug in the 328p silicon, the only three things that should be able to cause problems are (a) bad power, or (b) bad crystal, or (c) the RESET pin being pulsed or held low.

Ok. I'm happy i did not burn anything. Should have read better. (English not being my mother tongue, i should read better more often...)

Anyway, this did not succeed. I did a shunt between the 5V and reset pin of the board.

edit: Errr. as i said i should read better...
1 and 2 ought to be invalid because of the swap of CPUs that did not change results.

Power ought to be good, but i'll have to resort to scope to check that
Testing the cristal, i don't know how to, but i would be happy to. Any hint?
About the reset being pulsed or held low, i think the scope can also show this..

More tests coming along.

i'm still leaning a little towards wanting to consider some combination of:
(1) bad power - some design fault in the PCB meaning that on the R2 boards the 328p is not getting a clean enough supply to be able to correctly reset itself and start up when first connected to the supply,
and,
(2)a bootloader bug that only shows up when the 328p starts up from a 'bad' reset. i think it is VERY telling that you only see issues when a non-PWM-capable pin is tied high.

it's time to head off to bed over here (i'm in new zealand, christchurch to be precise) now that the earthquakes have quietened down for the night. but will check back tomorrow to see if anyone else has come up with other suggestions.

i've also posted a summary of the problem over on the adafruit forums, to see if anyone over there can shed any light:
http://forums.adafruit.com/viewtopic.php?f=25&t=21671

addendum: to check the crystal, use a scope to look for a clean train of pulses on pin 2 (XTAL2) of the 328p when the UNO is sitting in it's non-working state.

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.

Lefty

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.