Received: from PCH.mit.edu (18.7.21.50) by mail.efplus.com (192.168.0.8) with Microsoft SMTP Server (TLS) id 8.3.485.1; Wed, 26 Feb 2020 16:06:19 -0800 Received: from PCH.MIT.EDU (localhost.localdomain [127.0.0.1]) by PCH.mit.edu (8.14.7/8.12.8) with ESMTP id 01QNvRdq006900; Wed, 26 Feb 2020 18:57:35 -0500 Received: from outgoing-exchange-3.mit.edu (OUTGOING-EXCHANGE-3.MIT.EDU [18.9.28.13]) by PCH.mit.edu (8.14.7/8.12.8) with ESMTP id 01QNvQHL006896 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Wed, 26 Feb 2020 18:57:26 -0500 Received: from w92exedge4.exchange.mit.edu (W92EXEDGE4.EXCHANGE.MIT.EDU [18.7.73.16]) by outgoing-exchange-3.mit.edu (8.14.7/8.12.4) with ESMTP id 01QNucel004614 for ; Wed, 26 Feb 2020 18:56:47 -0500 Received: from w92expo22.exchange.mit.edu (18.7.74.76) by w92exedge4.exchange.mit.edu (18.7.73.16) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Wed, 26 Feb 2020 18:54:46 -0500 Received: from oc11exhyb2.exchange.mit.edu (18.9.1.98) by w92expo22.exchange.mit.edu (18.7.74.76) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Wed, 26 Feb 2020 18:57:21 -0500 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (104.47.56.177) by oc11exhyb2.exchange.mit.edu (18.9.1.98) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Wed, 26 Feb 2020 18:57:21 -0500 Received: from DM6PR02CA0096.namprd02.prod.outlook.com (2603:10b6:5:1f4::37) by CH2PR01MB5717.prod.exchangelabs.com (2603:10b6:610:40::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2750.22; Wed, 26 Feb 2020 23:57:19 +0000 Received: from DM3NAM03FT018.eop-NAM03.prod.protection.outlook.com (2603:10b6:5:1f4:cafe::a4) by DM6PR02CA0096.outlook.office365.com (2603:10b6:5:1f4::37) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2750.22 via Frontend Transport; Wed, 26 Feb 2020 23:57:19 +0000 Received: from mail-ed1-f41.google.com (209.85.208.41) by DM3NAM03FT018.mail.protection.outlook.com (10.152.82.200) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.15 via Frontend Transport; Wed, 26 Feb 2020 23:57:19 +0000 Received: by mail-ed1-f41.google.com with SMTP id dc19so949387edb.10 for ; Wed, 26 Feb 2020 15:57:18 -0800 (PST) From: RussellMc To: Microcontroller discussion list - Public. CC: ApptechNZ Sender: "piclist-bounces@mit.edu" Date: Wed, 26 Feb 2020 15:56:39 -0800 Subject: [EE]:: Body diode conduction insanity Thread-Topic: [EE]:: Body diode conduction insanity Thread-Index: AdXtAb06EV6TPDyCQ9qmJPrykY1XqQ== Message-ID: References: List-Help: List-Subscribe: , List-Unsubscribe: , In-Reply-To: Reply-To: Microcontroller discussion list - Public. Accept-Language: en-US X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Organization-AuthSource: TS500.efplus4.local X-MS-Has-Attach: X-Auto-Response-Suppress: All X-MS-Exchange-Organization-SenderIdResult: Pass X-MS-Exchange-Organization-PRD: mit.edu X-MS-TNEF-Correlator: received-spf: Pass (protection.outlook.com: domain of gmail.com designates 209.85.208.41 as permitted sender) receiver=protection.outlook.com; client-ip=209.85.208.41; helo=mail-ed1-f41.google.com; dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Vj8F6qjzGbposMUQp71M5p6Xh66WDBjg76iMz8ytiMo=; b=hgWENmgYyE9RMJfK+jzW6m8EepCFaMTnJpi/4bqQTyvndWC9LCiVxXCk12tewbhM+i 68i6jA7iqMjOSYvZaHu0ohc7mFc/RDyyHsdR6sO30jkbH2w2ejHD8aiD6DOIDB9DXiOE PYRcgWwouBsUqB+11fTKHo/wwOjbAN1E9rLbUbRAg12mk0gMXz6PlWnr7l84d23zmMKs sMYwVDPBD58OrLI/4OoUB4gP0W5Ro9p+corgb35SE4vgqyCDzCeEDwgl9OIIyVieShIf O2o0BKwWIgvUquxBYGHP2YGWJ3oEBcWn6WzxLcMIa8upJH6NSTOEj6ej3ssmw2KlIoIR iwpQ== authentication-results: spf=pass (sender IP is 209.85.208.41) smtp.mailfrom=gmail.com; mit.edu; dkim=pass (signature was verified) header.d=gmail.com;mit.edu; dmarc=pass action=none header.from=gmail.com;compauth=pass reason=100 errors-to: piclist-bounces@mit.edu list-id: "Microcontroller discussion list - Public." list-post: x-beenthere: piclist@mit.edu x-mailman-version: 2.1.6 x-received: by 2002:a17:906:af82:: with SMTP id mj2mr1018009ejb.84.1582761436754; Wed, 26 Feb 2020 15:57:16 -0800 (PST) x-topics: [EE] x-content-filtered-by: Mailman/MimeDel 2.1.6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Repost of a 2012 rant re not using body diodes as "protection" against overvoltage on device pins. Seems as worth reading now as it was then. How worthwhile that is I leave to the individual (except those who argue strenuously against the argument). Russell From: RussellMc Date: Fri, 27 Jan 2012 at 02:40 Subject: [EE]:: Body diode conduction insanity To: Microcontroller discussion list - Public. *Evil AVR app note that uses microcontroller body diodes to zero cross detect mains. Insanity writ large.* http://www.atmel.com/dyn/resources/prod_documents/doc2508.pdf The AVR IC designers must tear their hair out when their app note writers commit such lunacy. They effectively use 2 megohm input resistance (although they are not obviously aware of this from in-text comments). Diode currents of around +/- 240 x 1.414 / 2 m =3D~ 150 uA+ can be expected= .. Well above the "microamp range" that Microchip recommend in their not quite as bad but still stupid foray in figs 10-1 and 10-2 here. http://ww1.microchip.com/downloads/en/DeviceDoc/chapter%208.pdf Russell McMahon _____________________ * Copy and paste from my stack exchange rant here* http://electronics.stackexchange.com/questions/25691/measuring-frequency-of= -a-signal-above-5v-with-a-microcontroller PROTECTION DIODES: Many people are unaware of or just ignore the datasheet distinction between "Absolute maximum" ratings and recommended operating conditions. Absolute maximum ratings are those which the device is guaranteed to surviv= e without damage. Correct operation is not guaranteed. The PIC concerned allows Vdd + 0.3V on its pins as an absolute maximum rati= ng. Operation is not guaranteed during this condition. Most data sheets clearly specify that during normal operation input voltage= s should not exceed the ground to Vdd range. This datasheet may or may not ro so in its several hundred pages. It is still wrong to do so. Many people have thought that concerns about protection diode currents are baseless. Only some of them have rued the day they thought so and most have probably lived to rue it or not :-). Note that the (evil) Atmel application note here uses a 1 megohm resistor (connected to AC mains ! ) and the Microchip app note here - figs 10-1 10-2 at least has the grace to say " ... The current through the clamp diodes should be kept small (in the micro amp range). If the current through the clamping diodes gets too large, then you risk the part latching up." Atmels hundreds of uA is NOT "in the microamp range". BUT latch up is the least of your problems. IF you latchup the part (SCR action triggered by currents into IC substrate) the IC often turns into a smoking ruin and you realise that something may possibly be wrong. The problem with body diode currents is when you do NOT get an immediate smoking ruin. What happens is that the IC was never designed to accept current between input pin and substrate - the layer hat the IC is laid down on. When you raise Vin > Vdd the current effectively flows out of the ICV proper into a phantom fairyland that the iC is unaware of and that the designer did not and usually cannot design for. Once there you have small potential;s set up that are never normally there and current can flow back into adjacent circuit modes, of not quite adjacent nodes or even into locations some distance away depending on how big the currents are and what voltages are set up. The reason this is hard to describe and pin down is because it is totally undesigned and essentially undesignable. One effect is to inject currents into floating nodes that have no formal output path. These may act as gates for FETs - formal or accidental ones, that turn on or off semi-random parts of your circuit. Which parts ? When? How often? How long? How hard? Answer - who can tell / nobody can tell - its undesigned an undesignable. Q: Does this actually happen? A: Oh yes! Q: Have I seen it happen? A: Yes. I started what has now proved to be a 1+ decade crusade to make people aware of this (even though I should have been well aware of it) after being very badly bitten by it. I had a relatively simple async serial circuit that caused me no end of strife. Processor operation was intermittent or semi random. Code faulted sometimes and not other times. Nothing was stable. The problem? Body diode conduction, of course. I had copied a simple circuit from an application note supplied with a product and away we went. If you do this without due care it WILL bite you. If you do it with care and intelligence and design it may well not bite you. But may. This is akin to pulling over the centre line into ongoing traffic to overtake - done with care and not too often and leaving what may be good enough margins you will usually not die. If you do you will probably not be surprised :-). So it is with body diode conduction. Microchips 'microamp range" may be OK. Or not. Atmel's 1 megohm off mains is an accident waiting to happen. Suit yourself. --=20 http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist .