Regression between uno and uno R2 VALIDATED. HARDWARE PROBLEM CONFIRMED

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.

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

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.

excellent piece of research work there
especially since you found the real problem

well done, sir!

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' :

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

retrolefty:
[...]
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.

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.

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

retrolefty:

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.

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

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. :wink:

Robert posted a more detailed explanation on the adafruit boards:

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.

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.

westfw:
[...]
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)

just to make sure I've been following this correctly

is this the suggested workaround?

DiodeFix.jpg

mmcp42:
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.

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.

/*
 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

retrolefty:
[...]
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.

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

Lefty

retrolefty:
[...]
[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.

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