Regression between uno and uno R2 VALIDATED. HARDWARE PROBLEM CONFIRMED

Development Suggestions for the Arduino Project
#1

Sorry if this is seen as a repost, but after wandering around it seemed that this section was more appropriate.

We have been getting problems recently with arduino boards.

We use I-wire on pin7 for some ibutton reading and had the arduino R2 halting immediately on powerup. Pressing the reset button once after it hanged makes it boot correctly. 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') I have been trying on about 8 of the 40 i have in the office and all hang on startup with the resistor. I'm wondering if it's a design problem or just the serie.

Has anyone got any idea on what causes this behavior and how to solve it?

Thanks a lot.

#2

Sorry if this is seen as a repost, but after wandering around it seemed that this section was more appropriate.

If you remove the other thread no one will complain :)

#3

yes, certainly.

Does that mean that this place is more appropriate? I'm willing to kill that thread instead if i'm at the wrong section...

I would really love to have answers on this as i have to send prototypes pretty soon and i have no R1 to make everything work.

#4

this would seem to be pin 13 on the 328p, port D bit 7.

the problem could be that this pin has an alternative function during startup, which is inconsistent with it being pulled high. a simple solution is that the pin has an option to be configured with an INTERNAL pullup, and to make use of that feature. ie, once your code is running, configure the internal pullup instead of making use of an external one.

this doesn't trace down the initial problem, but does provide you with a simple workaround.

cheers, rob :-)

#5

Hello.

Problem is that programs don't even run. i don't know at the moment if it hangs at the bootloader or even before. As no led blink, i think it's before bootloader starts.

R2 ought to have changed only hardware, as far as i've seen. What bothers me is that original UNO works and i don't feel i do something nasty.

Hanging up a system with just a resistor looks serious enough. I wished i could get more attention from the arduino team. Do they come here at times, or is there an other place where to expose this problem?

#6

this is probably NOT the problem, but on the minutest chance it is... i've a feeling i read somewhere about the UNO's being shipped with an alternative bootloader, called "optiboot". this new bootloader is 1/4 the size (512 bytes) of the original (2k). i don't know, off hand, how you would tell which bootloader is present.

if your old UNO boards have the original 2k bootloader installed, while the newer ones have "optiboot" installed, this could account for the different behaviour you're seeing - and would place the blame for the failure squarely with the optiboot bootloader.

still, my original advice holds... use the internally configurable pull-up resistor on D7. or, if you [u]must[/u] use an external pullup, connect the top end of it to a spare output pin (instead of Vcc) that you can set high once your own code has taken control.

regarding the developers ever reading these posts: i've never seen any sign of them here :(

#7

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

I can confirm this... just struggled with this for a few hours!

I have an Arduino Uno R2 with a WiFly shield (which connects Digital Pin 7 to an IRQ line on the SC16IS750 with a 1K to 3.3V; see http://www.sparkfun.com/datasheets/DevTools/Arduino/WiFly_Shield-v17.pdf).

Exactly the same behaviour as described.

Works fine after loading a sketch over USB, but after power cycling the Arduino halts -- that is, the bootloader led sequence does not occur and the sketch fails to run. Pressing reset results in the expected bootloader led sequence and the sketch then runs. Severing the connection between the shield and the D7 pin on the Arduino corrects the behaviour.

#8

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?

#9

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?

#10

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"

#11

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.)

#12

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?

#13

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.

#14

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 [u]might[/u] 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.

#15

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?

#16

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!!!

#17

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.

#18

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 [u]possible[/u] 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.

#19

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.

#20

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 [u]non-PWM-capable[/u] 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.