Pages: 1 2 3 [4] 5 6 ... 8   Go Down
Author Topic: Regression between uno and uno R2 VALIDATED. HARDWARE PROBLEM CONFIRMED  (Read 26558 times)
0 Members and 1 Guest are viewing this topic.
Left Coast, CA (USA)
Offline Offline
Brattain Member
*****
Karma: 361
Posts: 17294
Measurement changes behavior
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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

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

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

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

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

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

[...]
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)
« Last Edit: June 24, 2011, 12:30:57 am by robert rozee » Logged

Leighton Buzzard, UK
Offline Offline
Edison Member
*
Karma: 21
Posts: 1339
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

just to make sure I've been following this correctly

is this the suggested workaround?



* DiodeFix.jpg (711.07 KB, 506x479 - viewed 52 times.)
Logged

there are only 10 types of people
them that understands binary
and them that doesn't

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

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.
« Last Edit: June 23, 2011, 09:38:46 am by robert rozee » Logged

Left Coast, CA (USA)
Offline Offline
Brattain Member
*****
Karma: 361
Posts: 17294
Measurement changes behavior
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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:
/*
 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
« Last Edit: June 23, 2011, 12:12:03 pm by retrolefty » Logged

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

[...]
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.
« Last Edit: June 23, 2011, 12:26:39 pm by robert rozee » Logged

Left Coast, CA (USA)
Offline Offline
Brattain Member
*****
Karma: 361
Posts: 17294
Measurement changes behavior
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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


« Last Edit: June 23, 2011, 01:54:38 pm by retrolefty » Logged

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

[...]
[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.
« Last Edit: June 23, 2011, 11:08:38 pm by robert rozee » Logged

Left Coast, CA (USA)
Offline Offline
Brattain Member
*****
Karma: 361
Posts: 17294
Measurement changes behavior
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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
Logged

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

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

Global Moderator
Dallas
Offline Offline
Shannon Member
*****
Karma: 208
Posts: 12936
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

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

Leighton Buzzard, UK
Offline Offline
Edison Member
*
Karma: 21
Posts: 1339
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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
Logged

there are only 10 types of people
them that understands binary
and them that doesn't

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

Quote
would the same apply to FT232RL driven chips?
No.  But none of those seem to be exhibiting the problem...
Logged

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