AVR40 and RESET ESD protection...

Go To Last Post
14 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Is this really true for the general case:
Atmel app note AVR040 http://www.atmel.com/dyn/resources/prod_documents/doc1619.pdf, specifically section 4.9 with special note of 4.9.2.

It doesn't seem to be mentioned in the datasheets I've been looking at... (ATmega328p etc.) though I may have missed it...

I'm working in a high noise environment, and it is a cause for concern...

Cheers

Nicko

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Is what really true? I don't see anything in the sections of the document that you listed that appear to be untrue.

If you are lett ing high noise into the /RESET pin during normal operations, an added diode would be the least of my worries. That amount of noise would cause sporadic resets and the app wouldn't be stable.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch wrote:
Is what really true?

...that whatever pin is /RESET is, unlike every other I/O pin, not fully ESD protected on most/all AVRs (those that have HV programming modes, anyway).

I just couldn't find it in the actual datasheets for the uPs, only in AVR040... seems like a big omission...

Edit: e.g. in section 13 (I/O-Ports) of the ATmega328P datasheet:

Quote:
All I/O pins have protection diodes to both VCC and Ground...

AVR040 in section 4.9.1 states:
Quote:
All general I/O-pins have internal ESD protection diodes to GND and Vcc
then in 4.9.2 states:
Quote:
During parallel programming, a 12V signal is connected to the Reset pin. There is therefore no internal protection diode from Reset to VCC; there is only one from GND
to Reset
Either the datasheet is wrong or AVR040 is misleading as /RESET can also be a general I/O pin - does the diode get disconnected when the pin is /RESET? Why is this not mentioned in the datasheet?

Cheers

Nicko

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
1.1.5 PC6/RESET
If the RSTDISBL Fuse is programmed, PC6 is used as an I/O pin. Note that the electrical characteristics of PC6 differ from those of the other pins of Port C.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch wrote:
1.1.5 PC6/RESET
If the RSTDISBL Fuse is programmed, PC6 is used as an I/O pin. Note that the electrical characteristics of PC6 differ from those of the other pins of Port C.
Indeed - If you take 1.1.5 as a whole, you could easily take that sentence to refer to the one following regarding its use as /RESET - there is no mention I can find in the whole datasheet of the lack of ESD protection on that pin. In fact, as I mentioned in the quotes above, the explicit statement is used in section 13.1:
Quote:
All I/O pins have protection diodes to both VCC and Ground...
This is therefore a direct contradiction to what is in 1.1.5 if AVR040 is correct (which it seems to be).

At best, the statements are very unclear; at worst, the datasheets are all missing clarification of a very important point...

Cheers

Nicko

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This app note has a little more reset pin information.
AVR042: AVR Hardware Design Considerations
http://www.atmel.com/dyn/resourc...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

1) There is no protection diode on /RESET. For sure to the high side.
2) No matter how much it bothers you, 1) is still true.
3) I don't see why it is of deep concern. If a concern, add a diode as in the document you referenced.
4) The datasheet is probably a carryover from the good-old-days when there was no RSTDISBL on that series.
5) If you have a design that is routinely violating Absolute Maximum Ratings, protection diode or not, you are cruisin' for a bruisin' IME. But suit yourself. I've had several apps over the years where our control boards were put into machines with unsnubbed contactors and the like. You hit the AVR lines--I/O, Gnd, and Vcc--hard enough with noise spikes and your AVR >>will<< do weird things. Supress things down to a mild roar and operation is fine.

I samples a few datasheets, and none lay it out any better. (IIRC the same situation applies to the amount of current allowed through the protection diode.) Perhaps you can suggest wording to Atmel to add to all AVR datasheets.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Mike B wrote:
This app note has a little more reset pin information.
AVR042: AVR Hardware Design Considerations
http://www.atmel.com/dyn/resourc...
I was trying not to add AVR042 into the mix as it only confuses the matter further - AVR040 recommends a diode & 1K resistor + 4n7 capacitor; AVR042 recommends the diode, a resistor of 4K7 or 10K (depending) and does not specify the value of the cap, it does however throw the idea of the addition of a zener into the mix (not mentioned in AVR040 which is supposed to the the guide to ESD!).

The fact that AVR040 and AVR042 don't correspond very well is another annoyance, but does not change my basic concern that the datasheets are incomplete on this matter, and they are supposed to be the definitive definition of the functionality of a given device.

Cheers

Nicko

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch wrote:
1) There is no protection diode on /RESET. For sure to the high side.
2) No matter how much it bothers you, 1) is still true.

It doesn't "bother" me - its an omission that I at least regard as surprising given that explicit statements are given in the datasheet which are contradicted elsewhere.

Quote:
3) I don't see why it is of deep concern. If a concern, add a diode as in the document you referenced.
You probably aren't operating in my environment, so you maybe wouldn't see the relevance of the issue. I am operating close to 500,000V discharges. It's an EMI-rich environment, to say the least, and whilst we do a lot of the standard protection stuff, omissions like this have the potential (pun) to be very significant indeed. Everything, especially issues like this, matters...
Quote:
4) The datasheet is probably a carryover from the good-old-days when there was no RSTDISBL on that series.
A rationale, certainly, but not a valid excuse. "Cut-n-Paste", anyone?
Quote:
5) If you have a design that is routinely violating Absolute Maximum Ratings, protection diode or not, you are cruisin' for a bruisin' IME. But suit yourself. I've had several apps over the years where our control boards were put into machines with unsnubbed contactors and the like. You hit the AVR lines--I/O, Gnd, and Vcc--hard enough with noise spikes and your AVR >>will<< do weird things. Supress things down to a mild roar and operation is fine.
See above.

Quote:
I samples a few datasheets, and none lay it out any better. (IIRC the same situation applies to the amount of current allowed through the protection diode.) Perhaps you can suggest wording to Atmel to add to all AVR datasheets.
I'll certainly raise it with Atmel - I (and many others) have made corrections to their data sheets before, and I've generally found them pretty responsive and grateful for the input. The current limit (I believe its about 1mA) is also a bit of a magic number, but I believe that has been addressed before.

Cheers

Nicko

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

You probably aren't operating in my environment, so you maybe wouldn't see the relevance of the issue. I am operating close to 500,000V discharges. It's an EMI-rich environment, to say the least, and whilst we do a lot of the standard protection stuff, omissions like this have the potential (pun) to be very significant indeed.

And then you go on to say

Quote:

See above.

No, I don't operate in that particular environment. But I'll stand behind my statement, based on 100+ production AVR designs in industrial and commercial environments:

Quote:

5) If you have a design that is routinely violating Absolute Maximum Ratings, protection diode or not, you are cruisin' for a bruisin' IME. But suit yourself. I've had several apps over the years where our control boards were put into machines with unsnubbed contactors and the like. You hit the AVR lines--I/O, Gnd, and Vcc--hard enough with noise spikes and your AVR >>will<< do weird things. Suppress things down to a mild roar and operation is fine.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello, Nicko -

I don't want to condone sloppy and confusing documentation. Its never acceptable.

But.... when you look at the Absolute Maximum ratings and see that the RST pin is spec'd differently from all the others, is that not enough to tell you that it really is different. When you see the maximum voltage rating on the RSP is higher than the other pins, is it not a rational conclusion that there really is no protection diode on that pin? Thats enough for me.

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

nickds1 wrote:
I was trying not to add AVR042 into the mix as it only confuses the matter further....
I was not defending the content, only pointing out a slightly different source of information. Ignoring or omitting information might be convenient for you, but not very helpful when trying to figure things out. All I can say is from our perspective, it is what it is. Only ATMEL can clarify the information discrepancies if they choose to do so. However, you are getting good, experience based, practical advice here on the forum.

BTW, ATMEL has a history of cut-n-paste errors in their documentation. My experience is some data sheets get immediate attention to fix errors and some data sheets never get fixed. It is a mixed bag. However, if you don't take it up with ATMEL and point it out, it is not totally their fault if it does not get fixed.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

They can't put an ESD diode from /reset to Vcc; if it was there, you would pull Vcc to 12v during HV programming and fry stuff. If you are not going to use HV programming on your board, feel free to add a diode.

If you are in such an EMI-rich environment, you need to suppress the ESD *BEFORE* it gets to the processor. You should not rely on chip's ESD structures in that case but should strive to keep it off the board and away from anything sensitive.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

n1ist wrote:
They can't put an ESD diode from /reset to Vcc; if it was there, you would pull Vcc to 12v during HV programming and fry stuff. If you are not going to use HV programming on your board, feel free to add a diode.
Yes, that point is made very clear in AVR042 and anyway, was never the issue (see below).

Quote:
If you are in such an EMI-rich environment, you need to suppress the ESD *BEFORE* it gets to the processor. You should not rely on chip's ESD structures in that case but should strive to keep it off the board and away from anything sensitive.

I'm obviously completely aware of the need to keep everything away from the uP - it is, as we say in England, a "statement of the bl*eding obvious", so whilst I appreciate everyone banging on about it, it is the first thing we did (and always do) and was mentioned in one of my previous posts in this thread.

The key issue is that for years this has been missing in any obvious way from the ATmega datasheets - hints to it may be hiding in the occasional obtuse sentence etc. and I don't want to re-iterate all that's been said above.

When in an extremely hostile environment, you use belt & braces - everything you can do contributes to the overall reliability of the system. It's disingenuous to state that you shouldn't let the EMI get to the uP in the first place - if that was a genuine approach, (reductio ad absurdum) why bother at all with ESD protection on any of the I/O pins? If one pin is more vulnerable than the others, that point should be made explicitly rather than implicitly.

This is most definitely not a directed personal grumble at anyone in particular in this thread, but sight seems to have been lost of the original issue - contradictions in the datasheets vs. the app notes, missing/incomplete descriptions, and a seeming general intent on shooting the messenger.

My original question was about clarification of the ESD protection on the /RESET pin - I think/hope we can now all agree that the documentation is incomplete and contradictory, and consequently Atmel have been informed...

Cheers

Nicko