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
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.
Is what really true?
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:
All I/O pins have protection diodes to both VCC and Ground...
All general I/O-pins have internal ESD protection diodes to GND and Vcc
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
Cheers
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.
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.
All I/O pins have protection diodes to both VCC and Ground...
At best, the statements are very unclear; at worst, the datasheets are all missing clarification of a very important point...
Cheers
This app note has a little more reset pin information.
AVR042: AVR Hardware Design Considerations
http://www.atmel.com/dyn/resourc...
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.
This app note has a little more reset pin information.
AVR042: AVR Hardware Design Considerations
http://www.atmel.com/dyn/resourc...
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
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.
Cheers
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.
See above.
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.
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
I was trying not to add AVR042 into the mix as it only confuses the matter further....
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.
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.
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.
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
