Go Down

Topic: Regression between uno and uno R2 VALIDATED. HARDWARE PROBLEM CONFIRMED (Read 27 times) previous topic - next topic

robert rozee

#5
Jun 20, 2011, 10:47 am Last Edit: Jun 20, 2011, 10:49 am by robert rozee Reason: 1
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 must 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  :(

Claudius


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.



Claudius


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?

westfw

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?

robert rozee

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"

Go Up