Pages: [1] 2 3 ... 8   Go Down
Author Topic: Regression between uno and uno R2 VALIDATED. HARDWARE PROBLEM CONFIRMED  (Read 21893 times)
0 Members and 1 Guest are viewing this topic.
Offline Offline
Newbie
*
Karma: 0
Posts: 25
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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.
« Last Edit: June 30, 2011, 03:01:09 am by foubarre » Logged

Global Moderator
Netherlands
Offline Offline
Shannon Member
*****
Karma: 170
Posts: 12482
In theory there is no difference between theory and practice, however in practice there are many...
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Quote
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 smiley
Logged

Rob Tillaart

Nederlandse sectie - http://arduino.cc/forum/index.php/board,77.0.html -
(Please do not PM for private consultancy)

Offline Offline
Newbie
*
Karma: 0
Posts: 25
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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

Christchurch, New Zealand
Offline Offline
Jr. Member
**
Karma: 0
Posts: 69
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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   :-)
Logged

Offline Offline
Newbie
*
Karma: 0
Posts: 25
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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?
Logged

Christchurch, New Zealand
Offline Offline
Jr. Member
**
Karma: 0
Posts: 69
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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  smiley-sad
« Last Edit: June 20, 2011, 03:49:39 am by robert rozee » Logged

Offline Offline
Newbie
*
Karma: 0
Posts: 4
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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.


Logged

Offline Offline
Newbie
*
Karma: 0
Posts: 4
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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?
Logged

SF Bay Area (USA)
Offline Offline
Tesla Member
***
Karma: 106
Posts: 6378
Strongly opinionated, but not official!
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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?
Logged

Christchurch, New Zealand
Offline Offline
Jr. Member
**
Karma: 0
Posts: 69
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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"
Logged

SF Bay Area (USA)
Offline Offline
Tesla Member
***
Karma: 106
Posts: 6378
Strongly opinionated, but not official!
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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

Offline Offline
Newbie
*
Karma: 0
Posts: 25
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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?
« Last Edit: June 21, 2011, 05:32:33 am by foubarre » Logged

Offline Offline
Newbie
*
Karma: 0
Posts: 25
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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

Christchurch, New Zealand
Offline Offline
Jr. Member
**
Karma: 0
Posts: 69
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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.
« Last Edit: June 21, 2011, 07:51:48 am by robert rozee » Logged

Offline Offline
Newbie
*
Karma: 0
Posts: 25
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Sorry for confusion.

Quote
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"

Quote
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?
Logged

Pages: [1] 2 3 ... 8   Go Up
Jump to: