Arduino Forum

Development => Suggestions for the Arduino Project => Topic started by: foubarre on Jun 17, 2011, 06:53 pm

Title: Regression between uno and uno R2 VALIDATED. HARDWARE PROBLEM CONFIRMED
Post by: foubarre on Jun 17, 2011, 06:53 pm
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.
Title: Re: Possible regression between uno and uno R2 ?
Post by: robtillaart on Jun 17, 2011, 08:35 pm
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 :)
Title: Re: Possible regression between uno and uno R2 ?
Post by: foubarre on Jun 17, 2011, 09:04 pm
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.
Title: Re: Possible regression between uno and uno R2 ?
Post by: robert rozee on Jun 19, 2011, 02:43 pm
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   :-)
Title: Re: Possible regression between uno and uno R2 ?
Post by: foubarre on Jun 20, 2011, 09:33 am
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?
Title: Re: Possible regression between uno and uno R2 ?
Post by: robert rozee on Jun 20, 2011, 10:47 am
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  :(
Title: Re: Possible regression between uno and uno R2 ?
Post by: Claudius on Jun 21, 2011, 04:40 am

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.


Title: Re: Possible regression between uno and uno R2 ?
Post by: Claudius on Jun 21, 2011, 04:56 am

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?
Title: Re: Possible regression between uno and uno R2 ?
Post by: westfw on Jun 21, 2011, 09:30 am
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?
Title: Re: Possible regression between uno and uno R2 ?
Post by: robert rozee on Jun 21, 2011, 11:07 am
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"
Title: Re: Possible regression between uno and uno R2 ?
Post by: westfw on Jun 21, 2011, 11:45 am
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.)
Title: Re: Possible regression between uno and uno R2 ?
Post by: foubarre on Jun 21, 2011, 12:30 pm
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?
Title: Re: Possible regression between uno and uno R2 ?
Post by: foubarre on Jun 21, 2011, 02:34 pm

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.
Title: Re: Possible regression between uno and uno R2 ?
Post by: robert rozee on Jun 21, 2011, 02:49 pm

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.
Title: Re: Possible regression between uno and uno R2 ?
Post by: foubarre on Jun 21, 2011, 03:12 pm
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?
Title: Re: Possible regression between uno and uno R2 ?
Post by: robert rozee on Jun 21, 2011, 03:33 pm

[...]
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!!!
Title: Re: Possible regression between uno and uno R2 ?
Post by: foubarre on Jun 21, 2011, 05:02 pm
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.
Title: Re: Possible regression between uno and uno R2 ?
Post by: robert rozee on Jun 21, 2011, 05:30 pm

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.
Title: Re: Possible regression between uno and uno R2 ?
Post by: foubarre on Jun 21, 2011, 06:02 pm
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.
Title: Re: Possible regression between uno and uno R2 ?
Post by: robert rozee on Jun 21, 2011, 06:25 pm
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 (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.
Title: Re: Possible regression between uno and uno R2 ?
Post by: retrolefty on Jun 21, 2011, 06:56 pm
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
Title: Re: Possible regression between uno and uno R2 ?
Post by: foubarre on Jun 21, 2011, 07:12 pm

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
Title: Re: Possible regression between uno and uno R2 ?
Post by: westfw on Jun 21, 2011, 10:15 pm
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...)
Title: Re: Possible regression between uno and uno R2 ?
Post by: foubarre on Jun 22, 2011, 11:39 am
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 (http://arduino.cc/en/Tutorial/ArduinoISP) was outdated, but got this error http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1287836171 (http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1287836171) )
Title: Re: Possible regression between uno and uno R2 ?
Post by: robert rozee on Jun 22, 2011, 02:02 pm
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.
Title: Re: Possible regression between uno and uno R2 ?
Post by: foubarre on Jun 22, 2011, 02:45 pm
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.
Title: Re: Possible regression between uno and uno R2 ?
Post by: foubarre on Jun 22, 2011, 03:49 pm
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.
Title: Re: Possible regression between uno and uno R2 ?
Post by: foubarre on Jun 22, 2011, 04:00 pm
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.
Title: Re: Possible regression between uno and uno R2 ?
Post by: robert rozee on Jun 22, 2011, 04:02 pm
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?
Title: Re: Possible regression between uno and uno R2 ?
Post by: foubarre on Jun 22, 2011, 04:05 pm
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
Title: Re: Possible regression between uno and uno R2 ?
Post by: robert rozee on Jun 22, 2011, 04:05 pm
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.
Title: Re: Possible regression between uno and uno R2 ?
Post by: foubarre on Jun 22, 2011, 04:07 pm

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?

i agree that reset is pretty ugly, however there seems to be only very negligible difference between signals with and without the resistor...
Title: Re: Possible regression between uno and uno R2 ?
Post by: robert rozee on Jun 22, 2011, 04:12 pm
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.
Title: Re: Possible regression between uno and uno R2 ?
Post by: foubarre on Jun 22, 2011, 04:21 pm

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... :)
Title: Re: Possible regression between uno and uno R2 ?
Post by: robert rozee on Jun 22, 2011, 04:32 pm
:-)   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?
Title: Re: Possible regression between uno and uno R2 ?
Post by: foubarre on Jun 22, 2011, 04:43 pm

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?
Title: Re: Possible regression between uno and uno R2 ?
Post by: robert rozee on Jun 22, 2011, 04:53 pm
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.
Title: Re: Possible regression between uno and uno R2 ?
Post by: foubarre on Jun 22, 2011, 05:36 pm

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

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

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.
Title: Re: Possible regression between uno and uno R2 ?
Post by: mmcp42 on Jun 22, 2011, 05:40 pm
excellent piece of research work there
especially since you found the real problem

well done, sir!
Title: Re: Possible regression between uno and uno R2 ?
Post by: retrolefty on Jun 22, 2011, 05:42 pm
Quote
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' :

Quote
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
Title: Re: Possible regression between uno and uno R2 ?
Post by: robert rozee on Jun 22, 2011, 06:14 pm

[...]
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.
Title: Re: Possible regression between uno and uno R2 ?
Post by: foubarre on Jun 22, 2011, 06:19 pm
Quote
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.

If it does, it's easy for new design to add two via around the diode to shunt it easily using a basic wire, or even add an open pad to be shunt with solder.

By the way, some diods seem to anihilate the reset for programming, so choosing the right one matters a bit.
Title: Re: Possible regression between uno and uno R2 ?
Post by: retrolefty on Jun 22, 2011, 06:42 pm
Quote
If it does, it's easy for new design to add two via around the diode to shunt it easily using a basic wire, or even add an open pad to be shunt with solder.


But wouldn't that also shunt out the reset's pull-up resistor to Vcc, which would then cause direct connection from Vcc to the high voltage pulse/level used in HV parallel programming mode?

Lefty
Title: Re: Possible regression between uno and uno R2 ?
Post by: robert rozee on Jun 22, 2011, 07:02 pm

Quote
If it does, it's easy for new design to add two via around the diode to shunt it easily using a basic wire, or even add an open pad to be shunt with solder.


But wouldn't that also shunt out the reset's pull-up resistor to Vcc, which would then cause direct connection from Vcc to the high voltage pulse/level used in HV parallel programming mode?

Lefty


i think he meant to say "in series with", with the jumper shorted by default.

re: not all diodes working - it will need to be a small-signal one, such as a 1N914, 1N4148, etc. a power diode such as a 1N4002 will potentially not clamp quick enough, allowing the HV pulse to still get through. other power diodes may, as you've seen, swamp a valid reset pulse.
Title: Re: Possible regression between uno and uno R2 ?
Post by: westfw on Jun 22, 2011, 09:46 pm
I'd be happier if I understood how the changes in the schematic (a pull-down resistor on the other side of autoreset cap) end up causing/allowing this spike...  (I also don't understand the motivation for ADDING that resistor in the first place,
so ...  I dunno.)

PD7 is involved in high-voltage parallel programming; it's (renamed PAGEL) supposed to be tied to 0 to enter HV programming mode (which is somewhat backward from the observed behavior.  But it certainly seems reasonable that HV excursions on RESET could trigger SOMETHING.)

None of the HV programming shields I've seen involve using that programming while the chip is mounted IN the arduino; they all move it to a separate socket.  HCV programming involves 9+ pins, including the crystal pins, so it's not really meant to work with the AVR "in circuit."
Title: Re: Possible regression between uno and uno R2 ?
Post by: retrolefty on Jun 22, 2011, 10:01 pm
Quote
None of the HV programming shields I've seen involve using that programming while the chip is mounted IN the arduino; they all move it to a separate socket.  HCV programming involves 9+ pins, including the crystal pins, so it's not really meant to work with the AVR "in circuit."


Looking over the one such HV programmer shield I saved a link to, you are correct, not used to program the arduino mounted processor but rather a second one you install onto the shield. So maybe the external clamping diode is a good 'fix'. But like you, I sure would like to understand better the failure mechanism and why the pull-down resistor was deemed desirable with the board revision.

Auto-reset is sure a nice feature, but it's sure had it's share of side effects over the years.  ;)
Title: Re: Possible regression between uno and uno R2 ?
Post by: westfw on Jun 22, 2011, 11:09 pm
Robert posted a more detailed explanation on the adafruit boards:
Quote
the UNO R2 has a 1k pulldown resistor on the CTS output of the 8U2. upon power being applied, the 0.1uF capacitor (C5) is charged up to 5 volts via this resistor (RN2D) and the 10k pullup (RN1D) on the RESET line. when the 8U2 finishes resetting and the code within it starts up, the CTS output is configured and set to HIGH - the 0.1uF capacitor is 'stacked up' on top of this.

so with CTS set high, a pulse of close to 10 volts is injected into the 328p's RESET pin.

It sounds like this spike probably ocured during auto-reset of the older boards, but is "new" at power-on in the R2.
Title: Re: Possible regression between uno and uno R2 ?
Post by: Claudius on Jun 23, 2011, 06:10 am

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


Following up on my earlier "me too" post to this thread, can confirm that adding a 1N4148 between RESET and +5V has fixed the problem my Uno R2 board is experiencing also.

Thanks foubarre for the scope work, and robert rozee for your intuition.
Title: Re: Possible regression between uno and uno R2 ?
Post by: robert rozee on Jun 23, 2011, 12:27 pm

[...]
It sounds like this spike probably occurred during auto-reset of the older boards, but is "new" at power-on in the R2.


you are correct, it's been sitting there as a latent issue right from when a 0.1uF capacitor was first introduced as a mechanism for resetting the 328p via the serial/usb interface. up until now the reset pulse has always been short enough (controlled via the Arduino IDE software) to prevent the capacitor charging up sufficiently to cause the behaviour we are seeing now.

i believe that with ALL Arduinos, a long reset pulse via comms (ie, setting DTR or CTS low, as appropriate, for any length of time, the releasing it) will result in a lockup condition the same as the one we are seeing with the UNO R2.

(later edit: it looks like the high-voltage pulse on the reset line is primarily a trouble at powerup time)
Title: Re: Possible regression between uno and uno R2 ?
Post by: mmcp42 on Jun 23, 2011, 01:29 pm
just to make sure I've been following this correctly

is this the suggested workaround?

Title: Re: Possible regression between uno and uno R2 ?
Post by: robert rozee on Jun 23, 2011, 04:05 pm

just to make sure I've been following this correctly

is this the suggested workaround?



that looks like it, except the net is called RESET on the pdf schematics i have here, not RST. as a rework, i'd suggest the easiest place to apply as rework is under the 6-pin POWER connector, where the pads are clearly labelled.

note that if i were to be asked to produce a solution for a new revision of the pcb (an R3), then rather than using a diode i would be inclined to use an NPN transistor across the reset switch, a 10k pulldown on the base, and base also connected to one end of the 0.1uF capacitor via a small current-limiting resistor (1k would likely do, so can recycle RN2D into this new role), and then invert the  function of the CTS line in the 8U2 software. i'd tie one of the spare pins of the 8U2 low, and use this as a means of detecting in software the difference between an R1/R2 and an R3 pcb.
Title: Re: Possible regression between uno and uno R2 ?
Post by: retrolefty on Jun 23, 2011, 06:38 pm
Quote
i believe that with ALL Arduinos, a long reset pulse via comms (ie, setting DTR or CTS low, as appropriate, for any length of time, the releasing it) will result in a lockup condition the same as the one we are seeing with the UNO R2.



It's been my experience that the auto-reset will generate a board reset just by changing the state of the DTR control signal, a complete pulse is not required, just a change of state (an edge transition). I'm pretty sure that the IDE does send a complete pulse, DTR on (for some unknown length of time?) followed with DTR off.

Here is my observation using my windows terminal program ( Brey terminal). I load this simple sketch into my Seeeduino mega board that simply sends back any character it receives and also in setup gives an indications that it has seen a reset.

Code: [Select]
/*
loop back test
*/
int inByte = 0;         // incoming serial byte

void setup()
{
 // start serial port at 57600 bps:
 Serial.begin(57600);
 Serial.println("Restarted");
}  
void loop()
{
 // if we get a valid byte, send it back out:
 if (Serial.available() > 0) {
   // get incoming byte:
   inByte = Serial.read();
   Serial.print(inByte, BYTE);            
 }
}


Now the Brey terminal program has a button called DTR that when clicked turns DTR on and when clicked again turns DTR back off. So I start the sketch and open the Brey terminal program the sketch starts, prints the Restarted message once and then any character I send I see back in the receive window. Now clicking the DTR button on causes a board reset and I see the Restarted message, and then loop back characters work if sent, all with the DTR signal still active on. Clicking the DTR button off again causes a board reset once again. At no time can I cause a 'board lock-up' by manipulating the DTR signal, but of course I'm not cycling the board's power.

So I think the .1ufd cap generates a short differential pulse to the arduino's reset pin on any DTR signal transition. It's doesn't care how long the DTR pulse is on, or if it's a on to off transition or off to on transition, or how long the signal remains at either state.

Not sure if that has any bearing on the power-up problem seen here, but I thought it might be useful to share my observations of the actual board auto-reset function's characteristic in practice with direct manipulation of the DTR signal.

So is that of any use for in analyzing this failure mechanism?

PS: It seems to me based on older arduino board schematics that the very first development used the RTS signal to generate the auto-reset pulse and later used both the RTS and DTR signals when sending a board reset from the IDE. I don't know if the latest IDE version still also sends a RTS along with the DTR or just the DTR. No where have I seen the use of the CTS signal used and that would not make sense as CTS would be a signal received by the PC comm port, not sent out the comm port to the arduino board? It gets back to the DTE and DCE definition and signal direction of the RS-232 control signals.

Lefty
Title: Re: Possible regression between uno and uno R2 ?
Post by: robert rozee on Jun 23, 2011, 07:24 pm

[...]
No where have I seen the use of the CTS signal used and that would not make sense as CTS would be a signal received by the PC comm port, not sent out the comm port to the arduino board? It gets back to the DTE and DCE definition and signal direction of the RS-232 control signals.

Lefty


you are correct about the signal direction. the pin used on the 8U2 just happens to be labelled CTS on the UNO R2 schematic, and (i believe) is being used as a raw output (via its PD7 function). i've called it CTS throughout the discussion simply to avoid any confusion with the PD7 pin on the 328p.

would you mind connecting a 4k7 resistor from one of the non-PWM digital pins to +5V on your arduino board, then repeating the experiment you outlined (including asserting then releasing DTR)? remember: the lockup condition only occurs when there is a pullup present on one of the non-PWM digital pins.

it is also possible, since your Seeeduino Mega does not use a 328p (it uses the 1280), that no lockup will occur. so far we've only been testing with boards that use the 328p, and other atmel processors may behave quite differently.
Title: Re: Possible regression between uno and uno R2 ?
Post by: retrolefty on Jun 23, 2011, 08:45 pm
Quote
would you mind connecting a 4k7 resistor from one of the non-PWM digital pins to +5V on your arduino board, then repeating the experiment you outlined (including asserting then releasing DTR)? remember: the lockup condition only occurs when there is a pullup present on one of the non-PWM digital pins.

it is also possible, since your Seeeduino Mega does not use a 328p (it uses the 1280), that no lockup will occur. so far we've only been testing with boards that use the 328p, and other atmel processors may behave differently.


Very interesting observations to report. First I changed to my 'official' Arduino 2009 328 based board that uses the FTDI USB converter (just like my Seeeduino mega board) but unlike the Uno's 8u2 converter chip.
Adding no pull-up resistor, the 2009 board works exactly the same as the Seeeduino mega board as far as being able to reset the board by either turning the DTR signal on or off, and not being able to cause any kind of lock-up (but still not trying to power cycle the board).

Then I added a 4.7k pull-up to pin 12 and tried testing DTR again, same behaviors as before.

Moved the pull-up to:
Pin 2, same behavior as pin 12 or with no pull-up.
Pin 4, different behavior, I can cause a reset turning on DTR but then turning off DTR does not cause a
        board reset?
Pin 7, same as pin 4, not able to cause a reset turning off DTR only turning it on cause board reset.
Pin 8, same as Pins 12 and 2, was able to reset both turning on and off DTR

Interesting no? Showing some auto-reset differences if using a 4.7k pull-up but only on none-pwm pins 4 & 7.  The schematic for the 2009 board shows no pull-down resistor used on the FTDI DTR signal output pin.
I'm not sure what any of this means. I wouldn't have expected to see a change in behavior based on what non-pwm pins have a external pull-up resistor or not? As what I'm seeing has nothing to do with using a 8u2 converter chip, (with a pull-down resistor or not) and not using the Uno's bootloader code, I'm not sure if what I have has anything to do with what you are dealing with?

So I tried a simple power cycling test with just one of the 'strange' pins, pin 4 using the 4.7k pull-up resistor. I closed my terminal program and unplugged my arduino from the USB. I then plugged in the 2009 board and then opened up brey terminal selected the proper comm port 5 and guess what, no Restart message and no loop back function! the board appears to be locked up. Normally opening the brey terminal session on the correct port causes any attached arduino board to reset, but not in this case with a external pull-up resistor on pin 4? If I then turn on DTR I get a board restart message and loop backs work. Also if starting in this 'lock-up' mode, if I press the boards reset switch I get a Restart message and loop-backs work and then it's back to where I can reset the board by turning on DTR but not cause a reset when turning DTR off.

So what does it all mean? All I can state is that it appears that the Arduino auto-reset function is not a great robust design and can be effected by having external pull-up resistors wired to certain pins and that the 'strange' behavior(s) can be seen on power-up or by not resetting the board by turning off DTR. This second symptom is probably not something anyone would notice using the arduino IDE as I'm pretty sure it uses a complete DTR on, delay, DTR off to reset a board, never using a DTR on to off transition to try and reset the board. So I'm pretty sure it's all just a hardware bug being effected by the use of the auto-reset circuit as I can't think of any common software component we share in the testing I just did.

Your thoughts?

PS edit: By the way I highly recommend the Brey terminal program for any Windows users out there. It's a free standalone exe program that needs no installtion steps (I carry a copy around in a memory stick) and has tons of features useful for testing serial devices including arduino boards. http://sites.google.com/site/terminalbpp/

Lefty


Title: Re: Possible regression between uno and uno R2 ?
Post by: robert rozee on Jun 24, 2011, 06:04 am

[...]
[using] my 'official' Arduino 2009 328 based board that uses the FTDI USB converter
[...]
I tried a simple power cycling test with just one of the 'strange' pins, pin 4 using the 4.7k pull-up resistor. I closed my terminal program and unplugged my arduino from the USB. I then plugged in the 2009 board and then opened up brey terminal selected the proper comm port 5 and guess what, no Restart message and no loop back function! the board appears to be locked up.
[...]
Your thoughts?

Lefty

(i think i have preserved your original meaning in the above quote, please correct me if i am wrong)

my thoughts are: a complex set of results!! reading through the portions of the 328p datasheet that relate to high-voltage (parallel) programming, it seems that on an arduino board there is no good to be had from a high-voltage pulse ever getting onto the RESET pin. that 0.1uF capacitor, without a suitably placed diode (or other solution), accomplishes just this (HV pulse) on occasion.

as you've found, there is much weird behaviour to be observed, going well beyond the simple lockup seen in the UNO R2. since this is all 'out of spec' operation of the 328p, i'm inclined to simply say that a diode does need to be fitted to ALL arduino boards. i am confident now that with a diode fitted you will see: asserting (setting low) DTR causing a reset, releasing DTR doing nothing, no unexpected lockups or other odd behaviour irrespective of the presence of pullups on any of the digital pins.
Title: Re: Possible regression between uno and uno R2 ?
Post by: retrolefty on Jun 24, 2011, 06:45 am
Quote
i'm inclined to simply say that a diode does need to be fitted to ALL arduino boards. i am confident now that with a diode fitted you will see: asserting (setting low) DTR causing a reset, releasing DTR doing nothing, no unexpected lockups or other odd behaviour irrespective of the presence of pullups on any of the digital pins.



Just for closure I did a temporary installation of a simple 1N914 signal diode between reset and +5vdc pins on the shield connectors on my Arduino 2009 board, and everything operated as you suggested it would. No problems, no 'lock-ups' and the only change from original stock condition is that turning DTR off no longer generates a board reset, which is as it should be anyway.

I agree that this should be a permanent change made to all boards, but I suspect that may not happen, and doesn't help the 100K+ boards already out in the wild both made by arduino and the tons of other makers of compatible designs. I have noticed in some micro boards schematics in the past such a diode used in their reset circuitry, even when not utilizing a on-the-run reset feature. It was usually associated with a series resistor/cap network used to make the power on reset condition last a little longer to allow board voltages to stabilize before the cap charged high enough to release the reset condition. I always assumed the diode was to help discharge the cap at power off to allow proper start-up reset if a power off, then on, was performed too quickly.

My main concern with this fault mechanism is how often it may be responsible for otherwise illogical symptoms or problems that people report. I would think that any applications that utilized external pull-up resistors on 'critical' pins and rely on running properly upon first powering up, could be vulnerable for misdiagnosis.

Well at least some of us now are aware that and why a reset diode is required for stable and reliable operation.

Thanks for sharing the problem with us, the community at whole learns from such sharing.

Lefty
Title: Re: Possible regression between uno and uno R2 ?
Post by: westfw on Jun 24, 2011, 07:49 am
I'd be inclined to get rid of the "auto-reset cap" entirely (and thus not need a diode, or the new resistor) in favor of a direct connection from the m8u pin to the m328 RESET pin.  Since the m8u is programmable to behave however we want, we could just have it normally leave that output "floating" (at the mercy of the existing pullup and reset switch on the m328 side), and have it momentarily output a LOW signal when it sees the appropriate USB/Serial behavior...

Adding a part to fix the problem caused by the last part you added, which was added to fix the problem from the part added before that...  Not good for the bottom line!
Title: Re: Possible regression between uno and uno R2 ?
Post by: Coding Badly on Jun 24, 2011, 08:27 am
Quote
PS edit: By the way I highly recommend the Brey terminal program for any Windows users out there


I like it too with one caveat... at higher baud rates it drops data.  This is especially troublesome when trying to log data.
Title: Re: Possible regression between uno and uno R2 ?
Post by: mmcp42 on Jun 24, 2011, 11:15 am

I'd be inclined to get rid of the "auto-reset cap" entirely (and thus not need a diode, or the new resistor) in favor of a direct connection from the m8u pin to the m328 RESET pin.  Since the m8u is programmable to behave however we want, we could just have it normally leave that output "floating" (at the mercy of the existing pullup and reset switch on the m328 side), and have it momentarily output a LOW signal when it sees the appropriate USB/Serial behavior...

Adding a part to fix the problem caused by the last part you added, which was added to fix the problem from the part added before that...  Not good for the bottom line!



would the same apply to FT232RL driven chips?
this includes seeeduino and those with external FTDI
Title: Re: Possible regression between uno and uno R2 ?
Post by: westfw on Jun 24, 2011, 11:19 am
Quote
would the same apply to FT232RL driven chips?

No.  But none of those seem to be exhibiting the problem...
Title: Re: Possible regression between uno and uno R2 ?
Post by: mmcp42 on Jun 24, 2011, 11:21 am

Quote
would the same apply to FT232RL driven chips?

No.  But none of those seem to be exhibiting the problem...


can you explain why they wouldn't have the same problem?
Title: Re: Possible regression between uno and uno R2 ?
Post by: robert rozee on Jun 24, 2011, 01:54 pm


Quote
would the same apply to FT232RL driven chips?

No.  But none of those seem to be exhibiting the problem...

can you explain why they wouldn't have the same problem?


have a look back at reply #53 from retrolefty (and the following couple of messages). he saw some aberrant behaviour from an Arduino board that had an FT232 fitted, it just took a little more digging to expose it. so the problem is not exclusive to the UNO, but in the case of the UNO R2 more obvious in its manifestation.
Title: Re: Possible regression between uno and uno R2 ?
Post by: retrolefty on Jun 24, 2011, 07:19 pm
Quote
No.  But none of those seem to be exhibiting the problem...


Quote
he saw some aberrant behaviour from an Arduino board that had an FT232 fitted, it just took a little more digging to expose it. so the problem is not exclusive to the UNO, but in the case of the UNO R2 more obvious in its manifestation.


If you read back over my prior posts you will see that I could consistently make the 328 chip power up into some kind of 'locked-up' condition, by just by having a 4.7k pull-up resistor wired to pin 4 and plugging the board into the PC usb and then a PC terminal program was opened. The PC would report a valid USB connection being established, but the sketch (the simple serial loopback test) would NOT start automatically. The symptom would not be present if the pull-up resistor is removed and the testing redone. So it takes a combination of starting with a inital power-up of the board and then opening some application that attempts to auto-reset the board, it fails on first attempt and only a manually forced auto-reset or a manual button reset clears the condition. Without the pull-up or with a diode installed the problem can't be recreated.

This was on a bog standard 'official' Arduino 2009 board using a FTDI chip. Pressing the manual reset button would successfully restart the sketch (or generating a DTR on signal would also 'un-lock' the board) without having to quit the PC serial terminal application.


 A diode is a simple and effective fix, but how to get that info out to the arduino community at large (both users and manufacturers) and having to consider this kind of a possible failure mode when trying to help others having weird unexplainable/illogical problems that may or may not be related to this failure mode, will I suspect be a challenge for a long time to come.

It's kind of like the 'lost my bootloader' reports we use to get frequently in the past. Reburning the bootloader would often get the user back in business, but I don't recall anyone ever being able to recreate a lost bootloader condition on purpose by something written in a sketch and uploaded?  


Lefty  
Title: Re: Regression between uno and uno R2 VALIDATED. HARDWARE PROBLEM CONFIRMED
Post by: foubarre on Jun 30, 2011, 10:10 am
First words for some time on the subject. Now that the problem is confirmed, validated, checked and a solution has been found, what is the next step?
I, for sure, want next boards i'll purchase not to exhibit this problem and i would hate having to solder diods on each and every of them.

This situation pours some pretty cold water on heat and excitation that comes out of the arduino project. Hardware is open, everything is nice and fun but when things derail it seems that there is no-one to handle them.
Did the creators finally turned into carton box pushers and only get interested in making money out of the project?
This is pretty far from how the other open communities react. In fact, the lack of reaction is the most disturbing problem to my eyes.

How do we make sure this problem is taken in account seriously? I would like the arduino team to communicate on this.
Title: Re: Regression between uno and uno R2 VALIDATED. HARDWARE PROBLEM CONFIRMED
Post by: mbanzi on Jul 02, 2011, 06:16 pm
hello foubarre

Consider that there are thousands of topics on this forum, it's impossible for us to be able to track all of them but on the website there are instructions on how to get in touch with us quickly (i.e. email team (at) arduino.cc or through twitter like you did)

email us a summary of the problem and we'll take immediate action if needed.

Quote
Did the creators finally turned into carton box pushers and only get interested in making money out of the project?

I think this is a particularly unfair statement. We're always  responsive when there are issues and we've always adhered to our open source principles even when we could have made an easy buck......

m
Title: Re: Regression between uno and uno R2 VALIDATED. HARDWARE PROBLEM CONFIRMED
Post by: foubarre on Jul 02, 2011, 07:13 pm
Summary is easy and has been sent as pm, i will let you read the full details and scope captures in the pages of this thread.

Please post followups as this is going to cause lots of headaches to users around the globe.
Title: Re: Regression between uno and uno R2 VALIDATED. HARDWARE PROBLEM CONFIRMED
Post by: westfw on Jul 06, 2011, 11:46 pm
Quote
This is pretty far from how the other open communities react.

Not really.   Difficult bugs take time to address.  All hardware bugs are difficult.
For example, this arduino-related gcc issue took 7 months for the compiler gurus to say that they weren't going to fix it.:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38342
(and gcc is a pretty shining example of open-source-software.  There's a LOT of stuff out there written by students, released on a lark, and essentially abandoned when they graduated and got a real job.  Shucks, "winavr", the packaging of gcc and related tools for AVR development on windows, was nearly abandoned.)
Title: Re: Regression between uno and uno R2 VALIDATED. HARDWARE PROBLEM CONFIRMED
Post by: robert rozee on Jul 23, 2011, 06:05 pm
does anyone know if there has been any action from the 'powers that be' over this - it's been a couple of weeks now, long enough to identify and quantify the problem, and verify the fix. i do note that a number of folks around the place are reporting problems with UNOs not talking to their PCs, and wonder how many are linked to reset issues covered in this thread.
Title: Re: Regression between uno and uno R2 VALIDATED. HARDWARE PROBLEM CONFIRMED
Post by: westfw on Jul 23, 2011, 11:30 pm
I've submitted http://code.google.com/p/arduino/issues/detail?id=572
I don't know for sure if that's a good place to submit HW bugs, but I don't see an official alternative.
Title: Re: Regression between uno and uno R2 VALIDATED. HARDWARE PROBLEM CONFIRMED
Post by: robert rozee on Jul 31, 2011, 01:49 pm

I've submitted http://code.google.com/p/arduino/issues/detail?id=572
I don't know for sure if that's a good place to submit HW bugs, but I don't see an official alternative.


well, a week has passed, and apart from someone confirming the reset problem on a duemilanove (!) the google code 'issues' page (above) has fallen silent. i really do find myself wondering if anyone who should care does?

am also seeing various folks on here and elsewhere having major problems talking to their arduinos, and nobody offering any concrete solutions. it seems to me that hooking up an arduino to your PC should be straightforward and simple. for each platform (windows, linux, mac) there should be a simple procedure to test drivers and hardware, that works independently of the arduino IDE - for instance loop back RxD and TxD and run a small program that simple writes text and verifies it returns to provide a 100% confirmation of driver + serial hardware.

i wonder if at least some of the strife folks are seeing is their 328 processor being incapacitated (in a not-easily reversible way) by a spike on the RESET line followed by 'random' data sent to the arduino as the IDE tries to communicate.
Title: Re: Regression between uno and uno R2 VALIDATED. HARDWARE PROBLEM CONFIRMED
Post by: foubarre on Aug 09, 2011, 10:46 am
I had some communication with the arduino team, which by the way confirmed a R3 uno that will include a diod fix.

I, too, would like an open discussion on that matter. At least a public sign of activity on this topic would be a nice move. Silently correcting a problem is not really what an open source project should do imho.
Title: Re: Regression between uno and uno R2 VALIDATED. HARDWARE PROBLEM CONFIRMED
Post by: ThatBozGuy on Aug 09, 2011, 09:08 pm

I had some communication with the arduino team, which by the way confirmed a R3 uno that will include a diod fix.

I, too, would like an open discussion on that matter. At least a public sign of activity on this topic would be a nice move. Silently correcting a problem is not really what an open source project should do imho.


Could someone describe the diode fix, can someone participating sum up?
Title: Re: Regression between uno and uno R2 VALIDATED. HARDWARE PROBLEM CONFIRMED
Post by: retrolefty on Aug 09, 2011, 09:13 pm
Quote
Could someone describe the diode fix, can someone participating sum up?


Wiring a diode from the reset pin to +5vdc (cathode lead to +5v) clamps any voltage higher then +5vdc going to the reset pin. This prevents the +10vdc pulse from the auto-reset cap from causing the problem stated in this thread. It's treating the symptom rather then the cause, but is simple and effective.

Lefty
Title: Re: Regression between uno and uno R2 VALIDATED. HARDWARE PROBLEM CONFIRMED
Post by: ThatBozGuy on Aug 09, 2011, 09:23 pm
Thanks lefty,This in replacement of the pullup resistor in the same configuration?
Title: Re: Regression between uno and uno R2 VALIDATED. HARDWARE PROBLEM CONFIRMED
Post by: retrolefty on Aug 09, 2011, 10:54 pm

Thanks lefty,This in replacement of the pullup resistor in the same configuration?


No, pull-up resistor remains. The diode serves a voltage clamping function, but it can't provide a pull-up voltage.

Lefty
Title: Re: Regression between uno and uno R2 VALIDATED. HARDWARE PROBLEM CONFIRMED
Post by: ThatBozGuy on Aug 10, 2011, 12:39 am
Thanks again lefty, just wanted to confirm.
Title: Re: Regression between uno and uno R2 VALIDATED. HARDWARE PROBLEM CONFIRMED
Post by: guf75 on Aug 11, 2011, 03:56 pm
I have posted a photo showing the modification on this thread:
http://arduino.cc/forum/index.php/topic,68936.0.html (http://arduino.cc/forum/index.php/topic,68936.0.html)

Guillaume
Title: Re: Regression between uno and uno R2 VALIDATED. HARDWARE PROBLEM CONFIRMED
Post by: Coding Badly on Aug 11, 2011, 07:54 pm
Quote
This prevents the +10vdc pulse from the auto-reset cap from causing the problem stated in this thread ... consistently make the 328 chip power up into some kind of 'locked-up' condition


Quote
Enter Programming Mode ... 3. Wait 20 - 60 ?s, and apply 11.5 - 12.5V to RESET.


I suspect the "locked-up" condition is parallel programming mode.  I wonder if that's how the bootloader gets erased?
Title: Re: Regression between uno and uno R2 VALIDATED. HARDWARE PROBLEM CONFIRMED
Post by: retrolefty on Aug 12, 2011, 12:24 am

Quote
This prevents the +10vdc pulse from the auto-reset cap from causing the problem stated in this thread ... consistently make the 328 chip power up into some kind of 'locked-up' condition


Quote
Enter Programming Mode ... 3. Wait 20 - 60 ?s, and apply 11.5 - 12.5V to RESET.


I suspect the "locked-up" condition is parallel programming mode.  I wonder if that's how the bootloader gets erased?



As good a theory as any. I always wondered how bootloaders got corrupted, because as far as I know there is no way a arduino sketch can blow up a bootloader?
Lefty

Title: Re: Regression between uno and uno R2 VALIDATED. HARDWARE PROBLEM CONFIRMED
Post by: tim7 on Aug 15, 2011, 12:33 am

Quote
Could someone describe the diode fix, can someone participating sum up?


Wiring a diode from the reset pin to +5vdc (cathode lead to +5v) clamps any voltage higher then +5vdc going to the reset pin. This prevents the +10vdc pulse from the auto-reset cap from causing the problem stated in this thread. It's treating the symptom rather then the cause, but is simple and effective.


I just came across this thread after acquiring an Uno R2.  The coupling capacitor used for the auto-reset feature kind of bugs me:  disabling auto-reset (as required by certain applications) involves overloading - albeit briefly - the the pin on the ATmega8U2.  As does the proposed diode-clamp.

This situation calls for a proper solution.  Switching the reset pin via a transistor entails no risk of voltage spikes, doesn't impede high-voltage programming, and can be disabled with a simple short.  Excuse the scribble:

(http://timgiles.free.fr/forumpics/reset.jpg)

The disadvantage is that the logic of the auto-reset signal is inverted (high -> reset).  Of course this can be corrected in the 8U2 firmware, but it's not a solution for boards which use external serial interfaces.  These boards could use a second transistor to invert the auto-reset signal.  Any thoughts?
Title: Re: Regression between uno and uno R2 VALIDATED. HARDWARE PROBLEM CONFIRMED
Post by: westfw on Aug 15, 2011, 11:30 am
For auto-reset to work correctly, it has to cause a reset pulse only during the transition of the signal from the 8u.  that's because the host side software doesn't "toggle" the pin, it just changes the state as a result of "opening" the virtual serial port.  If  you're willing to make the host-side software specifically arduino-aware, you can just connect the 8u pin direction to the 328 reset pin, and use some other SW mechanism to create the reset pulse...
Title: Re: Regression between uno and uno R2 VALIDATED. HARDWARE PROBLEM CONFIRMED
Post by: retrolefty on Aug 15, 2011, 06:50 pm
Quote
that's because the host side software doesn't "toggle" the pin, it just changes the state as a result of "opening" the virtual serial port.


I thought the arduino IDE (or is it AVRDUDE?) did perform an explicit DTR pulse right before performing the upload operation, rather then just relying only on the opening of the comm port by the OS?

Lefty

Title: Re: Regression between uno and uno R2 VALIDATED. HARDWARE PROBLEM CONFIRMED
Post by: tim7 on Aug 15, 2011, 07:25 pm
Ah, good point Westfw.  Ok, here's another version.  This one requires no modification of the 8U2 soft, and is also compatible with other commonly used serial interfaces.

It uses 3 extra components over the current version of the Uno: two 10k resistors and a transistor.  The other components are already available at suitable positions on the board, including the op-amp.  The reset pulsing remains exactly as on the Uno-R2, but the LM358 can withstand any over-voltage glitches applied to its input.  The transistor allows external signals to be applied to the Reset pin without risk of damage.

-Tim
(http://timgiles.free.fr/forumpics/reset-v2.jpg)
Title: Re: Regression between uno and uno R2 VALIDATED. HARDWARE PROBLEM CONFIRMED
Post by: Coding Badly on Aug 15, 2011, 10:50 pm
Quote
I thought the arduino IDE (or is it AVRDUDE?)


AVRDUDE is the culprit.

Quote
did perform an explicit DTR pulse


The Windows version pulses DTR and CTS for the "arduino" programmer type; the type used by Arduino 0022. 

I'll investigate the *nix version tonight.
Title: Re: Regression between uno and uno R2 VALIDATED. HARDWARE PROBLEM CONFIRMED
Post by: robert rozee on Sep 08, 2011, 06:16 pm
any more progress on this one? or is europe still on holiday?!
Title: Re: Regression between uno and uno R2 VALIDATED. HARDWARE PROBLEM CONFIRMED
Post by: foubarre on Sep 13, 2011, 12:26 pm

any more progress on this one? or is europe still on holiday?!

Nope,nope.
And due to lack of communication, the uncertainty it casts on the projects running on arduino, i've jumped off the boat.
I certainly don't want to be lost in the wild with a provider. Even if i had some discussions with the team.
Good luck everyone.

{EDIT}
To be specific, i choose other hardware not because the huge merits of arduino decreased. It is still a great platform, with lots of great things to offer. However, it was not the right choice for me, in my particular context.
I've had some discussions with the team, which helped me knowing their progress on the issue. We have some different vision about communication, that's all.
Title: Re: Regression between uno and uno R2 VALIDATED. HARDWARE PROBLEM CONFIRMED
Post by: robert rozee on Oct 19, 2011, 03:02 pm

any more progress on this one? or is europe still on holiday?!


bump... once again, has there been any further progress? i still see postings all over the place from folks who can't program their UNO, etc boards, and nearly zero mention of adding a diode between RESET and 5V being offered. now i know that this diode will not fix every failure being reported, but i do strongly feel that adding a diode will help at least some people.

Title: Re: Regression between uno and uno R2 VALIDATED. HARDWARE PROBLEM CONFIRMED
Post by: mbanzi on Oct 19, 2011, 03:14 pm
robert

can you send me a PM with links to all these posts that you are seeing?

There will be a post on the blog on friday about this

m
Title: Re: Regression between uno and uno R2 VALIDATED. HARDWARE PROBLEM CONFIRMED
Post by: robert rozee on Oct 19, 2011, 03:55 pm

can you send me a PM


PM sent - i think! can you let me know if it made it to you ok?

cheers,
rob   :-)

Title: Re: Regression between uno and uno R2 VALIDATED. HARDWARE PROBLEM CONFIRMED
Post by: avr300 on Oct 22, 2011, 08:25 pm
Thanks Rob.

Certainly cured the problem for another board here as well.
Title: Re: Regression between uno and uno R2 VALIDATED. HARDWARE PROBLEM CONFIRMED
Post by: bperrybap on Oct 24, 2011, 07:56 pm

Quote
I thought the arduino IDE (or is it AVRDUDE?)


AVRDUDE is the culprit.

Quote
did perform an explicit DTR pulse


The Windows version pulses DTR and CTS for the "arduino" programmer type; the type used by Arduino 0022. 

I'll investigate the *nix version tonight.



AVRDUDE is not the culprit.
The issue is that the Arduino hardware needs a reset pulse and is (was) using DTR as
the stimulus for that reset pulse yet DTR is level/state driven signal.

DTR is not a generic i/o pin with respect to serial communications but rather has a well
defined behavior. Its normal behavior is that it is used to detect the presents of device.
So therefore it is not a pulse but a logic level signal that indicates that a device is
connected or it isn't.
Normally most operating systems try to provide the standard DTR behavior.
This means that DTR will be one level when the serial port is not open and another level when
the port is opened. Again, this is not a pulse but a logical level signal to indicate to the other end
that something is attached and "listening".
This even works if multiple processes/applications open the serial port. The state will
change when the first open occurs and revert back when the last close occurs.

Now while most operating systems provide the standard DTR behavior, most also
allow overriding this standard behavior. Some allow manual control of DTR and
some allow disabling the automatic DTR state changes when the port is opened/closed.

As far as having DTR directly controlled by things like AVRDUDE to create a pulse
vs a logical level signal, while it can be done,
this is not particularly a good idea as it requires depending on non standard behavior of DTR and
often requires modifying the standard operating system behavior to make this work.
Remember that since DTR is controlled by the operating system, the OS would have to be told
about the non standard behavior and permanently configured to use that behavior
on each serial port that connects to an Arduino, because by the time an application like AVRDUDE is up
and running the OS by default may have already changed the state of the DTR signal.
i.e. the OS has control of the DTR signal when the serial port is opened which is before
the application can modify the DTR signal level.

While many OS's like Windows and LInux can be told to use non standard DTR behavior,
the way it is done is different (even between different versions of windows)
and can require using command line tools (on linux) or registry edits (on widows) to
ensure that the changes are permanent.
I would simply not recommend going down that route particularly since there are other s/w based solutions.

RTS which is/was also used for auto reset also has a standard behavior. But in the case
of RTS, it is much easier to control manually from an application given the standard/normal behavior for
RTS signal levels will not change states when the serial port is opened/closed.
RTS by default is used for hardware flow control.
As long as hardware flow control will never be used or enabled, then RTS is a much
better choice as things like generating a pulse for a an arduino reset.
The only potential issue when using RTS is that if hardware flow control is enabled
and the AVR is slamming the port with data, the RTS signal might get asserted
which would end up reseting the Arduino board rather than expected behavior
of flow control.

Now why wasn't RTS used vs DTR from the beginning?
Good question, this is because to use RTS required software changes to the IDE
and/or AVRDUDE. Auto-reset could be "kludged" in using DTR with no changes
to the IDE or AVRDUDE. So people could solder a capacitor on their board
and enjoy the "magic".

Where it gets interesting is when using a standard FTDI USB to serial adapter
cable. These cables bring out the RTS signal but do not bring out the DTR line.
So in order to use them, you have to toggle RTS.

To accommodate using RTS the IDE was modified to toggle the RTS line on
the serial port before starting up AVRDUDE in case the auto-reset depended
on RTS vs DTR. (DTR would still be driven by the OS and not AVRDUDE).

In the mean time, AVRDUDE has now been extended to support
an arduino programmer type that knows how to toggle RTS (maybe DTR too?)
for auto reset.


Going forward, there are several solutions possible but in my mind you
shouldn't use hardware to solve a problem that can easily be solved in software.

So the current state of things is that the IDE toggles RTS  before calling AVRDUDE.
This allows DTR or RTS to be sued for AutoReset.
Th latest AVRDUDE also has an arduino programmer type that knows how to toggle RTS
for AutoReset.
So given that RTS can now be used and avoids some of the DTR issues,
why use DTR for any new designs?
Also now that that there is a programmable part instead of a FTDI chip
you have complete control over the signal that controls the AVR reset line
and should not need to depend on the auto-reset cap "kludge" for the reset pulse.



My suggestion:

Simplify the hardware *not* make it more complicated.
This can be solved with Arduino board changes but mainly software changes to the 8U2 Code.

- 8U2 needs to either switch over to monitoring RTS instead of DTR or
  it needs to be state driven off the DTR signal.
  i.e. if DTR is still used, then pulse the auto reset output signal when DTR drops vs
  mirror the DTR state.

- Hook the 8U2 signal directly to the reset pin of the AVR. (remove the .1uf cap or short it out)

So my suggestion is to modify the 8U2 code and then replace C5 with a zero ohm resistor
so that the board does not have to be re-spun.
It becomes a simple ECO to change the board stuffing from a capacitor to a zero ohm resistor.

--- bill


Title: Re: Regression between uno and uno R2 VALIDATED. HARDWARE PROBLEM CONFIRMED
Post by: pjrc on Oct 24, 2011, 11:20 pm
It might be difficult to add anything to the 8u2 firmware, since it currently fills all but 6 bytes of the available space.
Title: Re: Regression between uno and uno R2 VALIDATED. HARDWARE PROBLEM CONFIRMED
Post by: bperrybap on Oct 25, 2011, 12:16 am
I haven't looked at the code or the USB messages involved yet,
but if the DTR and RTS state come across in the same message, then
simply switching from using DTR to RTS might not use up any more code space.

If you switch from DTR to RTS then you can eliminate the capacitor since
the IDE and/or AVRDUDE can toggle RTS when an autoreset is needed.
(vs DTR which normally drops low and stays low while the port is opened)

UPDATE:
It looks like the same status message is used to communicate RTS state as DTR state.
So it appears that changing from using DTR to RTS will not consume any additional code space.
It is merely looking at a different bit in memory.
Code: [Select]
bool CurrentDTRState = (CDCInterfaceInfo->State.ControlLineStates.HostToDevice & CDC_CONTROL_LINE_OUT_DTR);

This single line would change to look at CDC_CONTROL_LINE_OUT_RTS instead.

So my recommendation for resolving this would be to change the 8U2 code to use
RTS state instead of DTR state, because it can be toggled by the host software.
In order to use this software fix, you have to eliminate the capacitor. The easiest
way to do that is to replace C5 with a zero ohm resistor.
These two changes when combined, will avoid having to respin the board.
(but maybe you do use a resistor rather than 0 to avoid potential shorts with the
reset button or other circuitry driving the reset line)

Now as an alternative, I'd actually modify the code to flip the direction of the port bit rather
than control the data bit itself since it really only needs to yank the line low for reset.
In other words, I would flip between driving the pin low and using the pin as an input
for a "high".
This way the output pin is not consuming any extra power by fighting the external pullup resistor
on the AVR reset line.

This change also would not consume any additional code space but would
actually save a few bytes of code as the init portion would no longer have to set the
AVR_RESET_LINE_PORT bit to 1 or set the AVR_RESET_LINE_DDR  bit to be output.
The defaul values of 0 and input are what is needed.

Then when it is time to pull the reset pin low, all you have to do is set the port bit to be an output.
To set it high, make the port bit an input.
The external resistor on the AVR reset line will handle pulling the signal back up.

Not driving the pin high but flipping to input mode avoids any potential shorting issues
with the reset button as well.


--- bill
Title: Re: Regression between uno and uno R2 VALIDATED. HARDWARE PROBLEM CONFIRMED
Post by: robert rozee on Oct 25, 2011, 05:26 pm
the biggest problem is backwards compatibility - the IDE still needs to be able to communicate with EVERY existing arduino board out there, containing various bootloaders, firmware, and hardware configurations.

the whole auto-reset is an admirable intention that has, over time, and with various 'tweaks' become an absolute nightmare. the problem has been compounded by attempts to stick to a single codebase across several OS platforms, each OS with it's own level of access to and support for the usb and/or serial hardware.

personally, i'd do away with the auto-reset completely. instead i'd use a far more robust manual reset system:

1. IDE pops up a window saying "PRESS and HOLD reset button..." with a counter going from 5 seconds down to 0
2. IDE then closes that window and pops up another window saying "RELEASE reset button NOW".

during the above two steps the IDE would send repeatedly a query command to the bootloader, monitoring for a bootloader response. when the correct response came back the IDE would know that a communications channel with the bootloader had been established. if no response is seen within 5 seconds of the second window being popped up, a 3rd window could be popped up saying "Unable to Communicate". all very simple.

if someone is bright enough to program an arduino, they should be bright enough to press and release a single button as instructed!
Title: Re: Regression between uno and uno R2 VALIDATED. HARDWARE PROBLEM CONFIRMED
Post by: bperrybap on Oct 25, 2011, 07:23 pm

the biggest problem is backwards compatibility - the IDE still needs to be able to communicate with EVERY existing arduino board out there, containing various bootloaders, firmware, and hardware configurations.


Exactly.
That is why any prosed fix to UNO should be 100% backward compatible with the currently shipping
0022 and 1.0RC host software.
The proposal I suggested, required no changes to any host software.
It is changes that are isolated to the UNO board hardwre and 8U2 software.
It makes the UNO work like boards that use the official FTDI data cable by changing its auto-reset
to use RTS vs DTR.
(official FTDI data cables, don't bring the DTR signal out on the connector, they use RTS instead)

And while the proposal I made may not be the final solution,
I still believe that there is a solution for UNO that would not require re-spinning the board.
I think the key is what to insert in place of the c5 capacitor that is currently in series with the
auto-reset signal.
A diode? A resistor?  Some sort of resistor probably makes the most sense since
it will prevent shorts to the RTS line from people either grounding or setting RESET to VCC.


Quote


the whole auto-reset is an admirable intention that has, over time, and with various 'tweaks' become an absolute nightmare. the problem has been compounded by attempts to stick to a single codebase across several OS platforms, each OS with it's own level of access to and support for the usb and/or serial hardware.

personally, i'd do away with the auto-reset completely. instead i'd use a far more robust manual reset system:

1. IDE pops up a window saying "PRESS and HOLD reset button..." with a counter going from 5 seconds down to 0
2. IDE then closes that window and pops up another window saying "RELEASE reset button NOW".

during the above two steps the IDE would send repeatedly a query command to the bootloader, monitoring for a bootloader response. when the correct response came back the IDE would know that a communications channel with the bootloader had been established. if no response is seen within 5 seconds of the second window being popped up, a 3rd window could be popped up saying "Unable to Communicate". all very simple.

if someone is bright enough to program an arduino, they should be bright enough to press and release a single button as instructed!



It sounds like you are assuming a particular method of uploading (a serial based bootloader).
and that the IDE has full control over the bootloader protocol.
If so, both of those assumptions are either incorrect or too limiting.
The IDE allows using many methods of uploading including ISP and proprietary methods like Teensy.
These alternate methods have no issues with auto-reset.
Even in the case of using a serial based bootloader, the IDE does not control the serial data
transfer. That is all handled by AVRDUDE.
So now you are talking about a much bigger change that involves not only coming up with a new
handshake and upload protocol but also potentially either moving all the upload functionality into the IDE
or adding additional functionality to AVRDUDE.

Also, take a close look where the reset button is located particularly on the official
arduino boards. How are you going to press that button when a shield in in place?


I believe that downloading from the IDE should "just work" rather than require people to hold
their mouth just right and have to push buttons on the Arduino board at just the right time
to initiate the download.


So, at this point, I believe it will be much easier to simply correct auto-reset issues that exist
once and for all in the Arduino hardware and software rather than dream up entirely new download mechanisms.


While auto-reset may have issues, IMHO, most are self inflicted by a lack of understanding of how DTR and RTS really work
and a lack of coordinating the host software to properly use the control lines.
I also believe that the majority of people are not experiencing auto-reset issues.
Yes there are many auto-reset issues with trying to use the Arduino as and ISP
but most users are not doing that and most of those issues can be traced back
not providing adequate auto-reset control on the board.
i.e. using DTR and not providing something as simple as a jumper to disable auto-reset.

There seems to be a bias to keep trying to solve the problem by throwing hardware at a problem
that needs to be solved by taking a different approach which probably involves software.

The key to having a reliable auto-reset is to have full control over the Arduino's reset line
by the host software.

While DTR can be used to control auto-reset, it is ugly and problematic because DTR is a level based signal and
the host application often does not have full control over the DTR line.
i.e. the OS usually controls and alters the DTR line state before the host application could ever take control.

IMHO, using RTS is the long term answer as it can be better controlled than DTR.
Since it can be toggled by the host software when needed/as needed,
there is no need to have hardware on the Arduino board attempt to make a pulse from a falling edge
level based signal.
The problem then reduces to how to keep the auto-reset signal from colliding with other
signal sources that drive the RESET line locally on the board.

All the Aduino IDE OS's currently supported allow controlling RTS  from the host software.

The existing IDE and AVRDUDE both now have the ability to control the RTS line
and do toggle RTS for those Arduino board implementations that use RTS instead of DTR.
The current IDE toggles RTS which allows boards that use DTR or RTS to function even
when using older AVRDUDE that does not have the arduino programmer type that knows
how to toggle RTS.
So backward and forward compatibility is pretty well covered right now.

To me the ideal solution for auto-reset is to use RTS instead of DTR since applications
have much better control over RTS.

In addition, to accommodate those with very special needs for disabling autoreset, provide a jumper.
For a board like an official Arduino board like an UNO, if it were up to me, I'd put
a set of holes for a 2 pin header that has a trace between them. That way if a person
really wants to disable auto-reset for good, they can cut the trace.
If they want to use a jumper, they cut the trace and solder in a 2 pin header.
That way the less technical folks get a nice easy to use auto-reset from the IDE with no jumpers
and those with special needs can perform a simple "hack" to get what they need.

With a solution like that, you continue to get auto-reset for normal sketch downloading
and those that want to use the arduino as an isp can simply cut a trace, install a header/jumper
and disable auto-reset whenever they want/need to.
Also, when using RTS instead of DTR, you won't get the Arduino board reseting
when you open the serial port. You only get a reset during a download.


--- bill



Title: Re: Regression between uno and uno R2 VALIDATED. HARDWARE PROBLEM CONFIRMED
Post by: justjed on Oct 26, 2011, 03:17 am
Irrespective of the rest of this,

For a board like an official Arduino board like an UNO, if it were up to me, I'd put
a set of holes for a 2 pin header that has a trace between them. That way if a person
really wants to disable auto-reset for good, they can cut the trace.
If they want to use a jumper, they cut the trace and solder in a 2 pin header.

Yes. That would be nice.
Title: Re: Regression between uno and uno R2 VALIDATED. HARDWARE PROBLEM CONFIRMED
Post by: Claudius on Oct 26, 2011, 05:45 am

There will be a post on the blog on friday about this


Was this posted to the Arduino Blog, or elsewhere? Didn't find any mention on the Arduino Blog, and looking forward to seeing this through.
Title: Re: Regression between uno and uno R2 VALIDATED. HARDWARE PROBLEM CONFIRMED
Post by: Folknology on Nov 11, 2011, 01:54 pm
One simple solution to this issue for all Arduinos out in the field is a simple 2 pin jumper with a 5V6 Zener diode fitted (BZX55B5V6-TR ~ 3 cents), along with clear polarity markings for fitting across pins 5 & 6 of the ISP header. Such a solution could be posted 1st class folded in thin cardboard inside a standard envelope for next to nothing for those who want it. Of course it would need to be tested, I don't have such a zener diode handy.

In terms of implementation one would need to mount the zener on the side of the open jumper because:
1) It needs to be low profile (not interfere with shields etc..)
2) It then acts as a physical polariser, the zener physically prevents it being fitted around the incorrect way as it hits pins 3 and 4.

regards
Al
Title: Re: Regression between uno and uno R2 VALIDATED. HARDWARE PROBLEM CONFIRMED
Post by: john1993 on Oct 28, 2012, 04:02 pm
im not sure if this issue has been discussed in a more recent threads. google directed me here. links to any other discussions, if any, would be appreciated.

first arduino team deserves commending for developing such an excellent software platform and showing great care in publishing fixes for these kind of problems. as an ee having designed and produced thousands of arduino and other avr devices (commercial and hobby) many similar cases of boot failure have cropped up. imo direct connect of reset is a bad idea for reasons mentioned. ive seen that cap save butt in more than one setup.  the diode fix is the way to go. an even simpler remedy is just replace the 10k with a diode. i suspect that resistor serves little purpose anyway and has caused failure itself in some cases. swapping resistor with diode requires no changes to avrdude, gui, 8u, or arduino pcbs and has solved the problem of that hv spike for me. if there are unseen drawbacks in this approach please comment as im preparing to turn out another batch of units.

btw i understand arduino company has upgraded new board design but is there a more public link/sticky for the thousands of legacy users who run into this? i have some people who need more direct and non-technical info than this thread.
Title: Re: Regression between uno and uno R2 VALIDATED. HARDWARE PROBLEM CONFIRMED
Post by: justjed on Oct 28, 2012, 11:31 pm

i have some people who need more direct and non-technical info than this thread.


This is a technical problem, and I don't know that there's any way to state it more simply and directly than in this post:
http://arduino.cc/forum/index.php/topic,64256.msg472562.html#msg472562
and http://code.google.com/p/arduino/issues/detail?id=572

Applies to Uno through R2, and Duemilanove, AFAIK.

So, patch your Arduino, if applicable, as shown in the circuit drawing.
Title: Re: Regression between uno and uno R2 VALIDATED. HARDWARE PROBLEM CONFIRMED
Post by: john1993 on Oct 29, 2012, 08:47 am
thanks for the reply. yes, technical forum and fine for guys like you and me. unfortunately majority are non-technical, at least in hardware. so pics and less discsussion would be better. i guess ill have to put together such a package to email those with boot problems. looks like swapping the resistor with diode is a better fix anyway.
Title: Re: Regression between uno and uno R2 VALIDATED. HARDWARE PROBLEM CONFIRMED
Post by: westfw on Oct 29, 2012, 09:20 am
Quote
swapping the resistor with diode is a better fix anyway.

This is equivalent to not having a pullup on RESET, isn't it?   Believed to work, but not particularly recommended.

Isn't the 10k resistor part of a resistor network on Uno boards?  That makes "simply replacing it with a diode" a bit problematic.

I diode from reset to +5V can easily be inserted in the "power" connector; no soldering required.  It'd get a bit trickier if there are shields involved.

Inserting the diode the wrong way probably breaks autoreset AND ISP programming, but not permanently (?)
Title: Re: Regression between uno and uno R2 VALIDATED. HARDWARE PROBLEM CONFIRMED
Post by: john1993 on Oct 30, 2012, 12:14 am

Isn't the 10k resistor part of a resistor network on Uno boards?  That makes "simply replacing it with a diode" a bit problematic.

I diode from reset to +5V can easily be inserted in the "power" connector; no soldering required.


all avr have a pu on the reset line so the 10k strikes me as redundant. i never use it on homegrown projects. however your comments about the resistor pak and using the connector are right on and obviously best solution for customers. thanks.
Title: Re: Regression between uno and uno R2 VALIDATED. HARDWARE PROBLEM CONFIRMED
Post by: westfw on Oct 30, 2012, 07:15 am
So, do like this?
Title: Re: Regression between uno and uno R2 VALIDATED. HARDWARE PROBLEM CONFIRMED
Post by: CrossRoads on Oct 30, 2012, 04:10 pm
That's what is recommended on pages 4-5 here.
I used 10k pullup & diode in all my designs now. Not the cap tho.
Title: Re: Regression between uno and uno R2 VALIDATED. HARDWARE PROBLEM CONFIRMED
Post by: pico on Oct 30, 2012, 05:27 pm
So just out of interest, what was the "official" fix in the R3 Uno? (I know, I could just dig up and compare schematics, but I'm lazy -- sorry.)
Title: Re: Regression between uno and uno R2 VALIDATED. HARDWARE PROBLEM CONFIRMED
Post by: CrossRoads on Oct 30, 2012, 08:47 pm
Diode was added.
Title: Re: Regression between uno and uno R2 VALIDATED. HARDWARE PROBLEM CONFIRMED
Post by: john1993 on Oct 30, 2012, 11:21 pm

So, do like this?


yes, i now realize thats the best solution. if shield is needed the diode can be installed on it or on the bottom of the uno. thanks for the photo, its just what i needed for those who cant read schematics or dont solder..

btw i did try leaving out the cap on some of my minimal bbb type boards. it worked in most cases but failed with some serial usb dongles. sometimes due to timing issues and other failures caused by polarity. with cap and diode it works all the time so now i mount both on the dongle. this way even a bare chip (literally zero external components) can be programmed via the ide or avrdude alone.
Title: Re: Regression between uno and uno R2 VALIDATED. HARDWARE PROBLEM CONFIRMED
Post by: pico on Oct 31, 2012, 12:54 am

Diode was added.


Zener to 0V, or ordinary to +5V?
Title: Re: Regression between uno and uno R2 VALIDATED. HARDWARE PROBLEM CONFIRMED
Post by: CrossRoads on Oct 31, 2012, 02:23 am
Cathode to +5. Anode to reset pin.
Any spikes on the reset pin are shunted to the +5V supply.
I use 1N4158.
Title: Re: Regression between uno and uno R2 VALIDATED. HARDWARE PROBLEM CONFIRMED
Post by: pico on Oct 31, 2012, 02:47 am
Thanks