Do the MCP23S17 GPIO pins need protection against latch up ESD within this circuit?

Question

I wrote about this system before. I will focus my questions now on "ESD protection" direction.

I have an SPI based system in which a Raspberry talks with a GPIO expender device using SPI communication. The chip reads and/or writes '0'/'1' and send it to the Raspberry by bus.

The expander GPIOs circuit is a very simple circuit, but somedays a dangerous overconsumption/overheating (it almost burns) is triggered randomly after hours of correct operation. This stops when I reset the device. After this, the device has normal behaviour and normal consumption. Nowadays system is being connected and tested on a protoboard. So, wiring or lab material may be affecting a little or a lot.

Some people suggest that this behaviour seems to be a "latch up" caused by ESD. Otherwise it could be caused by voltage spikes, positives spikes or negatives GND ones. So, they told me that my GPIOs need to be protected with resistors, diodes and capacitors. But I don't see any example with diodes, Cs and Rs protecting inputs/outputs in other microcontroller or microprocessor based projects. The most I have seen are series resistors at some of the GPIO pins.

My circuit is too much simpler than those I have seen:

8 expander pins will be inputs. The rest will be outputs.
Expander outputs will be writing '0', never '1'.
Expander inputs has an internal Rpull up that put input at 3.3V when not connected.
I put a wire at every output and this wire could be connected directly to the inputs or not. So when read the 8 input pins, those who are connected to the inputs will read '0', and the rest, will read '1'.
An input would read these 3 scenarios:
- '1' (when not connected),
- '0' output writing (if they are connected)
- '0' = GND (if a GND point makes direct contact with an input).

A particular characteristic of this system is that GPIOs will not be configured as inputs or output for the rest of the times. So during one execution a pin can be configured as an input during initialization, but at the next execution the same pin could be configured to be an output.

This overheating phenomena doesn't happens more than once or twice per day. But I'm afraid that once would be enough to destroy the system.

At final PCB design GPIOs pins will be traced through the board achieving a 64-pin connector. Input and output will be connected through a wire that will connect -or not- two of the 64-pin connector pins by human connection during execution. This way, a circuit between one input and one output could be closed. But there could also be open circuits between the rest of inputs and outputs.

I have added 10K Rs at every device GPIO and I'm using a 100nF between VDD and GND. It seems not to happen anymore two days ago, but I would like to ensure my GPIOs if the circuit really needs.

Does this circuit need GPIO protection? Are these resistor enough?

If you did not have any bypass caps over the supply pins at the chip, that alone can cause all kinds of issues. But since you tried so many things at once, it is impossible to know what will help and what does not. I would have tried to figure out whether the two pins were accidentally set both to outputs, as then it is not a latchup caused by ESD, but maybe programming or communication error. — Justme, Jul 29 '20 at 12:16
Ups! sorry I forgot drawing it, but there is a 100nF capacitor! so sorry! — Suvi_Eu, Jul 29 '20 at 12:28
@Justme I've read a lot of literature about this the last 3 days, and one of the ways for protecting in front of just what you say: programming errors and inputs being configured as outputs, was R series. So I put series resistors at every GPIO pin. It has two functions: current limitation in case of mistakes and improvement against ESD. Someone suggested me to use from 10K up to 200K. But I know there is users that has been used 200Ohms when inputs have push buttons — Suvi_Eu, Jul 29 '20 at 12:52
There seems some confusion. Let me clarify. (1) ESD usually destroys components when a human handling the components (a) before the component is inserted into the circuit, AND (b) the human is not earthed and he at the same time carries electrostatic charge. If your components are already in circuit, then there is no ESD problem. / to continue, ... — tlfong01, Jul 29 '20 at 13:24
Perhaps you are talking about two other things: (1) power mains surge. When there is a black out because of mains overloading (what you say "over consumption", too many air cons say) tripping over MCB. And when everybody switches on/off at the same time afterwards, there might be surges/spikes from building's nearby sub station. These spikes might be over 220V's peak and resets the Rpi. Usually there should be no harm to Rpi because it gets only 5V power from adapter, not directly from mains, / to continue, ... — tlfong01, Jul 29 '20 at 13:31
And there is another thing called "back EMF". If you are using Rpi to control inductive loads, like motor, solenoid or fan, perhaps by using 5V relay or SSR. Then when switchin off (a) the relay, and/or (b) the motor or solenoid, there might be a back EMF which is a voltage spike, sometimes a couple of time of the original power supply, causing current flow back to the Rpi's circuit. This back EMF is usually minimized by using (i) "flyback" diode, (ii) optoisolation circuits. But the spikes might travel through the ground lines and trigger/reset the Rpi. / to continue, ... — tlfong01, Jul 29 '20 at 13:37
And "latching up" is another thing. Take Rpi for example, if one Rpi GPIO pin is in input mode, and the GPIO pin is connected through a series resistor to a 5V source. Then there is a 5% chance that "latching up" might happen, frying the Rpi's GPIO pin circuit, or shortening the Rpi's life. / to continue, ... — tlfong01, Jul 29 '20 at 13:40
To get a rough idea of "latching up", you might like to read my answer to the following question: (1) "Rpi3 might have been fried by wrongly connected DHT11 temparature sensor - Rpi SE Latching up Q&A": https://raspberrypi.stackexchange.com/questions/96560/rpi3-might-have-been-fried-by-wrongly-connected-dht11-temparature-sensor/96563#96563. Cheers. — tlfong01, Jul 29 '20 at 13:46
some random comments. (1) If you are using MCP23S17, then you are using Rpi's MOSI, MISO, CS to talk to MCP23S17. If what you are referring as GPIO, are MCP23S17's GPIO pins, then don't worry, because any spike, back EMF stuff will first fry MCP23S17, and Rpi hiding behind should be "safe". (2) Usually when a Rpi or MCP23S17 GPIO is in output mode, and you want to protect it from shorting to ground, or shorting to another GPIO output pin and so they are fighting each other, then the usual trick is to use a series resistor, say 330R or 470R. / to continue, ... — tlfong01, Jul 29 '20 at 13:58
Using 10K is OK if your GPIO is to control a MOS device with high impedance input. But if the device is BJT, then the biasing resistance is usually 220R to 1k, then using 10k series to protect GPIO is a bit overdoing. Just casually talking aloud, my apologies for the typos. Ah, bed time. See you tomorrow. — tlfong01, Jul 29 '20 at 14:03
Ah, I forgot that your Rpi also uses GPIO pins to set the address pins (A0 to A2) of the MCP23S17, but that should not cause any problem. A safe way is just tie those A0 to A2 pins direct to Vcc and/or Ground. Cheers. — tlfong01, Jul 29 '20 at 14:09
(1) One more thing, about the MCP23x17 reset pin. When playing with MCP23x17, I found that the chip from time to time go crazy, and I need to push the manual reset button which I install because I find very useful in debugging. I do suspect that MCP23x17 is very noise sensitive, so might go crazy if your SPI/I2C connecting wires are very long (> 60cm). (2) Another thing is that I find it a good idea of not connecting MCP23x17's interrupt pin direct to Rpi. Instead you use Rpi to loop the MCP23s17 interrupt status registers. Cheers. — tlfong01, Jul 30 '20 at 01:35
@tlfong01I'm afraId that human users will do the wires connections. So according to you ESD could be happen easily. Is it? — Suvi_Eu, Jul 30 '20 at 05:49
@tifong well, as I said MCP GPIOs OUTPUTS will write '0' and outputs could be wire-connected to the MCP GPIOs inputs (detecting contact between two wires connection) or not (not connected to anything = detecting isolation between two wires). Inputs will be connected to outputs. So, despite a single pole wires it is a CMOS technology. For sure, every chip address will be the same during the entire life cicle so I will configure them by VCC and GND. We don't need INTs for our application. And my last comment: continue.. — Suvi_Eu, Jul 30 '20 at 06:23
is that something was triggering the overheating after working fine during hours and most of people says to me that it seems a latch up due spikes or ESD. When I have 1uF capacitor within VDD-GND it happened twice. Suddenly started getting too hot, consumptions goes from 3W to 6W (so seems a short circuit consumption). It only stops when MCP reset is done (it is one of the things that happens when latch up occures). I changed 1uF for 100nF and it seems not to happen after 2 days working. The cause of triggering the undesired situation is unknown for me. Thanks a lot for your time — Suvi_Eu, Jul 30 '20 at 06:50
@tlfong01 I want you to clarify one more thing: When I talk about GPIOs I'm not refering to Raspberry GPIOs, so I mean MCP device GPIOs. Overheating is happening to MCP device and I would like to prevent my PCB components going fryed. System needs not to easily fail at this way. — Suvi_Eu, Jul 30 '20 at 06:51
(1) About ESD thing. You might have noticed that the vendors usually ship components in metallic plastic bags, and also on metallic sponges. That is for anti static. The operators in the assembly and testing factories wear antistatic writs bands like this: "AliExpress Adjustable Anti Static Bracelet PVC Wrist Electrostatic ESD Discharge Cable Strap Hand with Grounding Wire": https://www.aliexpress.com/popular/ground-strap.html. I am a hobbyist playing with cheap components, and I never bother, because the chances of catching the ESD virus is very very small. — tlfong01, Jul 30 '20 at 07:05
It is in the old days when electronic components were expensive that people bothered. Or you stay in a very dry country, wearing poly/plastic/nylon clothes then you need to bother. Of course everybody has a chance of struck by lighting. Perhaps you should google further for a piece of mind. — tlfong01, Jul 30 '20 at 07:10
(2) I always recommend newbies NOT to use the Rpi's 5V or 3V rail to power MCP23S17 or other peripheral devices, but use an external power supply, at least for prototyping stage. This way, if MCP23S17 gets crazy, the Rpi still sits happily. So I just manually reset MCP23S17 and no need to reset Rpi, the shows goes on. — tlfong01, Jul 30 '20 at 07:17
(3) What you are saying about ***overheating*** is a bit worrying. MCP23S17 cannot handle big currents. I usually use buffer chips to handle big currents. If you are overloading all the 16 GPIO output pins with big current, then you will be in big trouble. Let me check the MCP23S17 datasheet to confirm. I will be back in a minute. BTW, I am a bit long winded, so let us go to the chat room and carry on later. — tlfong01, Jul 30 '20 at 07:22
Let us [continue this discussion in chat](https://chat.stackexchange.com/rooms/111212/discussion-between-tlfong01-and-eugenia-suarez). — tlfong01, Jul 30 '20 at 07:28

tlfong01 · Answer 1 · 2020-08-29T01:16:23.863

Question

How come my MCP23S17 GPIO extender gets very hot and goes crazy?

/ to continue, ...

Answer

Part 1 - Test setup

I would suggest to start with a smaller version of the user requirements. For example, instead of making things very flexible, any pin can be input or output, you can in the testing phase, let 8 pins input only, and another pins output only.

PA0~7 set to input mode

PB0~7 set to output mode

Only when find the fixed input/output mode of the pins OK in testing, then you generalize the program.

mcp23017_test_v0.2_2020aug0101 PUBLIC

Part 2 - Clarification on ESD and Latching up

You might have noticed that the vendors usually ship components in metallic plastic bags, and also on metallic sponges. That is for anti static.

The operators in the assembly and testing factories wear antistatic writs bands like this:

AliExpress Adjustable Anti Static Bracelet PVC Wrist Electrostatic ESD Discharge Cable Strap Hand with Grounding Wire.

I am a hobbyist playing with cheap components, and I never bother, because the chances of catching the ESD virus is very very small.

It is in the old days when electronic components were expensive that people bothered. Or you stay in a very dry country, wearing poly/plastic/nylon clothes then you need to bother. Of course everybody has a chance of struck by lighting. Perhaps you should google further for a piece of mind.

(Ref A.2) ESD equipment that improves safety & workplace protection- AntiStat

Part 3 - Recommendation to use external power supply for MCP23S17

I always recommend newbies NOT to use the Rpi's 5V or 3V rail to power MCP23S17 or other peripheral devices, but use an external power supply, at least for prototyping stage.

This way, if MCP23S17 gets crazy, the Rpi still sits happily. So I just manually reset MCP23S17 and no need to reset Rpi, the shows goes on.

Part 4 - Possible causes of overheating

What you are saying about overheating is a bit worrying.

MCP23S17 cannot handle big currents. I usually use buffer chips to handle big currents. If you are overloading all the 16 GPIO output pins with big current, then you will be in big trouble.

I skimmed the datasheet and made a summary:

(1) Total power = 700 mW

(2) Max current VSS pin = 150 mA

(3) Max current into VDD pin = 25 mA

(4) Input clamp current = ±20 mA

(5) Output clamp current = ±20 mA

(6) Max output current sunk by any output pin = 25 mA

(7) Max output current sourced by any output pin = 25 mA

So you see, if you load 6 GPIO pins with 25mA, then total current is over the Vss pin 150mA limit. I usually the 8 big guy chip ULN2803A to do all the heavy work. Each of the 8 big guys can handle 500mA, ...

You seem to use 10Ω for series limiting/protecting resistor. You might like to do the calculations to make sure the individual GPIO and total Vcc current limit is not exceeded.

Part 5 - Pair/Swap Testing and Programming

It is often a good idea to use more than two samples to do pair/swap testing. Often a component might be bad on arrival and or damaged by careless wiring or testing. So often is only by swap comparing and contrast you find careless wiring mistakes. You can use MCP23s08 or MCP23017 for cross testing. It is only the setup part that is different in the I2C and SPI verions of MCP23x17. The main operation functions are identical for MCp23SS17 and MCP23017 017. Taking pictures from time to time is a good documentation for later reference.

/ to continue, ...

References

Part A - Datasheets and articles

(A.1) MCP23S17/MCP23017 Datasheet - MicroChip

(A.2) ESD equipment that improves safety & workplace protection- AntiStat

(A.3) Clean Power for Every IC, Part 1: Understanding Bypass Capacitors - Robert Keim, AAC 2015sep21

(A.4) Clean Power for Every IC, Part 2: Choosing and Using Your Bypass Capacitors - Robert Keim. AAC 2015sep27

(A.5) Adafruit I2C 16-Channel 12-bit PWM/Servo Driver - $15

(A.6) PCA9685 PWM Controller Datasheet - NXP

(A.7) mcp23s17 Datasheet - Microchip

(A.8) AliExpress MCP23S17 Module

(A.9) TaoBao MCP23S17 Module

(A.10) Logical level converter (ULN2803, TBX/TSX0102/4/6/8 etc) 1/2

(A.11) Logical level converter (ULN2803, TBX/TSX0102/4/6/8 etc) 2/2

(A.12) TVS, MOV Clamping Diode - Liz London 2019mar16

(A.13) (TVS) Transient Voltage Suppression Diode - Wikipedia

(A.14) ESD Protection Diodes (TVS Diodes) - Toshiba

(A.15) ESD Protection by Design of Chips and Microcircuits - Online Library, Wiley

(A.16) ESD (Electrostatic discharge) - Wikipedia

(A.17) Decoupling caps, PCB layout - Olin Lathrop , EE SE, 2011jun07, viewed 80k times

Part B - Forum Discussions

(B.1) Why is the MCP23S17 device getting too much hot suddenly and randomly Raspb 4A? - Eugenia Suarez EE SE 2020jul17

(B.2) Does I need MCP23S17 GPIO pins protection against latch up ESD within this circuit? - Eugenia Suarez, EE SE, 2020jul29

Part C - Schematics

(C.1) mcp23s17_test_2020jul3002 CircuitLab Schematic - tlfong01 2020jul3001

(C.2) mcp23017_test_v0.2_2020aug0101 PUBLIC tlfong01 2020aug01

Appendices

Appendix A - Bypass and Decoupling Capacitors - Robert Keim, AAC

(A.3) Clean Power for Every IC, Part 1: Understanding Bypass Capacitors - Robert Keim, AAC 2015sep21

(A.4) Clean Power for Every IC, Part 2: Choosing and Using Your Bypass Capacitors - Robert Keim. AAC 2015sep27

Introduction

It is not inconceivable that a dedicated, successful engineering student would graduate from college knowing almost nothing about one of the most pervasive and important components found in real circuits: the bypass capacitor. Even experienced engineers may not fully understand why they include 0.1 µF ceramic capacitors next to every power pin of every IC in every circuit board they design.

This article provides information that will help you to understand why bypass capacitors are necessary and how they improve circuit performance, and a follow-up article will focus on details related to choosing bypass capacitors and the PCB layout techniques that maximize their efficacy.

Solution

it is convenient that such a serious problem can be effectively resolved with a simple, widely available component. But why the capacitor? A straightforward explanation is the following: A capacitor stores charge that can be supplied to the IC with very low series resistance and very low series inductance.

Thus, transient currents can be supplied from the bypass capacitor (through minimal resistance and inductance) instead of from the power line (through comparatively large resistance and inductance). To better understand this, we need to review some basic concepts related to how a capacitor affects a circuit.

First, though, a brief note about terminology: The components discussed in this article are regularly referred to as both “bypass capacitors” and “decoupling capacitors.”

There is a subtle distinction here—“decoupling” refers to reducing the degree to which one part of a circuit influences another, and “bypass” refers to providing a low-impedance path that allows noise to “pass by” an IC on its way to the ground node.

Both terms can be correctly used because a bypass/decoupling capacitor accomplishes both tasks. In this article, however, “bypass capacitor” is favored in order to avoid confusion with a series decoupling capacitor used to block the DC component of a signal.

A Standard Approach

The foregoing analysis helps us to understand a classic bypassing scheme:

a 10 µF capacitor within an inch or two of the IC, and

a 0.1 µF ceramic capacitor as close to the power pin as possible:

The larger capacitor smooths out lower-frequency variations in the supply voltage, and the smaller capacitor more effectively filters out high-frequency noise on the power line.

If we incorporate these bypass capacitors into the 8-inverter simulation discussed above, the ringing is eliminated and the magnitude of the voltage disturbance is reduced from 1 mV to 20 µV, ...

Appendix B - Grounding Problem and Solution

(1) Ground loop problems and how to get rid of them - Tomi Engdahl 2013

(2) RpiZero Power Supply through 40 pin Power/GPIO Header or microUSB connector

(3) Rpi GPIO Push Button Circuit Grounding Problem

Appendix C - Old MCP23S17/ MCP23017 Proto Board for Testing

I am thinking of using my old MCP23S17 or MCP23017 to do some tests. Looking at the messy wiring of my old MCP23017 board, now I remember why last time I gave up working on SPI MCP23S17 and switched to I2C MCP23017, because the DIY wiring is very messy, and difficult to do hardware troublshoot. For I2C MCP23S17, there are cheapy breakout borads, sayhing me much time doing wiring.

Appendix D - MCP23s17 protoboard setting up notes

Appendix E - Testing SPI 00, 01, 10, 11, 12 Loopback and repeat send one byte OK

# Program:
#   spi_loopback_v55.py  tlfong01  2020aug03hkt1220
#
# Function:
#   1. SPI one byte loopback
#   2. SPI repeatedly send one byte
#
# System Config: 
#   Rpi4B buster (r2020may23), python 3.7.3 (r2019dec20), thonny v3.2.7 (r2020jan22)
#   $ date Thu 25 Jun 2020 04:36:13 PM HKT
#   $ uname -a Linux raspberrypi 4.19.118-v7l+ #1311 SMP Mon Apr 27 14:26:42 BST 2020 armv7l GNU/Linux
#   $ ls /dev/ttyUSB* /dev/ttyUSB0
#   $ ls /dev/ttyS0 /dev/ttyS0
#   $ ls /dev/ttyAMA0 /dev/ttyAMA0

# Test Function Definitions:
#
# Test 1 - loopBackTest() - SPI port send and receive one byte.
# Function - Send one byte to MSOI and read it back from MISO.?
# Setup - Connet MOSI pin to MISO pin to form a loop.
#
# Test 2 - repeatSendByte() - SPI port repeatedly send out single bytes. ?
# Function - Repeat many times sending a byte, pause after each byte.

# 1. SPI ports setup notes
# To enable SPI and setup SPI 10, 11, 12 ports, add these two lines to /boot/config.txt
#   dtparam=spi=on
#   dtoverlay=spi1-3cs
# To list SPI devices
#   pi@raspberrypi:~ $ ls /dev/spi*
#   /dev/spidev0.0  /dev/spidev0.1  /dev/spidev1.0  /dev/spidev1.1  /dev/spidev1.2

# 2. Notes of loopback function
#   Call example - testLoopbackOneByte(spiPort00)
#   Function     - send byte 0x5b to SPI MOSI and read byte from MISO
#   Setup        - must connect MOSI pin to MISO pin to loop back
#   Note         - 1. Only checks if MISO echoes MOSI, CS0, CS1, CS2 is not checked
#                  2. To check if SPI 0, CS0, CS1, or SPI1 CS0, CS1, CS2, need a scope to display repeat send bytes 

from time import sleep
import spidev

# *** Setup SPI Ports ***

spiPort00 = spidev.SpiDev()
spiPort00.open(0,0)
spiPort00.max_speed_hz = 100000

spiPort01 = spidev.SpiDev()
spiPort01.open(0,1)
spiPort01.max_speed_hz = 100000

spiPort10 = spidev.SpiDev()
spiPort10.open(1,0)
spiPort10.max_speed_hz = 100000

spiPort11 = spidev.SpiDev()
spiPort11.open(1,1)
spiPort11.max_speed_hz = 100000

spiPort12 = spidev.SpiDev()
spiPort12.open(1,2)
spiPort12.max_speed_hz = 100000

# *** Define SPI Functions ***

def spiSendRecvOneByte(spiPort, sendByte):
  sendByteArray = [sendByte]
  recvByteArray = spiPort.xfer(sendByteArray)  
  return recvByteArray

def loopBackOneByte(spiPort, sendByte):
  recvByteArray = spiSendRecvOneByte(spiPort, sendByte)
  recvByte      = recvByteArray[0]

  print('\nBegin testLoopbackOneByte(),....')
  #print('')
  print('   sendByte = ', hex(sendByte))
  print('   recvByte = ', hex(recvByte))
  #print('')
  print('End testLoopbackOneByte(),....')
  return

def repeatSendOneByte(spiPort, sendByte, pauseTimeBetweenBytes, repeatCount):
  print('\nBegin repeatSendByte(),....')
  print('  Now use a scope to display the SPI signals, MOSI, MISO, CSn, ...')
  for i in range(repeatCount):
    spiSendRecvOneByte(spiPort, sendByte)
    sleep(pauseTimeBetweenBytes)
  print('End   repeatSendByte().')
  return

# *** Test Funtions ***

def testLoopbackOneByte(spiPort, dataByte):
  loopBackOneByte(spiPort, dataByte)
  return

def testRepeatSendOneByte(spiPort, dataByte, pauseSeconds, repeatTimes):
  repeatSendOneByte(spiPort, dataByte, pauseSeconds, repeatTimes)
  return
 
# *** Main ***

# *** Test SPI Loopback Functions, Comment out not required tests ***

print('\n*** testLoopbackOneByte(spiPort00, 0x5b) ***', end = '')
testLoopbackOneByte(spiPort00, 0x5b)

#print('\n*** testLoopbackOneByte(spiPort01, 0x5b) ***', end = '')
#testLoopbackOneByte(spiPort01, 0x5b)

#print('\n*** testLoopbackOneByte(spiPort10, 0x5b) ***', end = '')
#testLoopbackOneByte(spiPort10, 0x5b)

#print('\n*** testLoopbackOneByte(spiPort11, 0x5b) ***', end = '')
#testLoopbackOneByte(spiPort11, 0x5b)

#print('\n*** testLoopbackOneByte(spiPort12, 0x5b) ***', end = '')
#testLoopbackOneByte(spiPort12, 0x5b)


# *** Test SPI Repeat Send One Byte Functions, Comment out not required tests ***

# *** SPI 00, 01 Repeat Send One Byte ***

#print('\n*** testRepeatSendOneByte(spiPort00, 0x5b, 0.001, 200000) ***', end = '')
#testRepeatSendOneByte(spiPort00, 0x5b, 0.001, 200000)

#print('\n*** testRepeatSendOneByte(spiPort01, 0x5b, 0.001, 200000) ***', end = '')
#testRepeatSendOneByte(spiPort01, 0x5b, 0.001, 200000)

# *** SPI Repeat Send One Byte 10, 11, 12 ***

#print('\n*** testRepeatSendOneByte(spiPort10, 0xb5, 0.001, 200000) ***', end = '')
#testRepeatSendOneByte(spiPort10, 0xb5, 0.001, 200000)

#print('\n*** testRepeatSendOneByte(spiPort11, 0xb5, 0.001, 200000) ***', end = '')
#testRepeatSendOneByte(spiPort11, 0xb5, 0.001, 200000)

#print('\n*** testRepeatSendOneByte(spiPort12, 0xb5, 0.001, 200000) ***', end = '')
#testRepeatSendOneByte(spiPort12, 0xb5, 0.001, 200000)


# End of program


''' Smple output tlfong 01 2020aug03hkt1219

>>> %Run spi_loopback_v54.py

*** testLoopbackOneByte(spiPort00, 0x5b) ***
Begin testLoopbackOneByte(),....
   sendByte =  0x5b
   recvByte =  0x5b
End testLoopbackOneByte(),....

*** testLoopbackOneByte(spiPort01, 0x5b) ***
Begin testLoopbackOneByte(),....
   sendByte =  0x5b
   recvByte =  0x5b
End testLoopbackOneByte(),....

*** testLoopbackOneByte(spiPort10, 0x5b) ***
Begin testLoopbackOneByte(),....
   sendByte =  0x5b
   recvByte =  0x5b
End testLoopbackOneByte(),....

*** testLoopbackOneByte(spiPort11, 0x5b) ***
Begin testLoopbackOneByte(),....
   sendByte =  0x5b
   recvByte =  0x5b
End testLoopbackOneByte(),....

*** testLoopbackOneByte(spiPort12, 0x5b) ***
Begin testLoopbackOneByte(),....
   sendByte =  0x5b
   recvByte =  0x5b
End testLoopbackOneByte(),....
>>> 
 
Python 3.7.3 (/usr/bin/python3)
>>> %Run spi_loopback_v54.py

*** testRepeatSendOneByte(spiPort00, 0x5b, 0.001, 200000) ***
Begin repeatSendByte(),....
  Now use a scope to display the SPI signals, MOSI, MISO, CSn, ...

────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
Python 3.7.3 (/usr/bin/python3)
>>> %Run spi_loopback_v54.py

*** testRepeatSendOneByte(spiPort01, 0x5b, 0.001, 200000) ***
Begin repeatSendByte(),....
  Now use a scope to display the SPI signals, MOSI, MISO, CSn, ...

────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
Python 3.7.3 (/usr/bin/python3)
>>> %Run spi_loopback_v54.py

*** testRepeatSendOneByte(spiPort10, 0xb5, 0.001, 200000) ***
Begin repeatSendByte(),....
  Now use a scope to display the SPI signals, MOSI, MISO, CSn, ...

────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
Python 3.7.3 (/usr/bin/python3)
>>> %Run spi_loopback_v54.py

*** testRepeatSendOneByte(spiPort11, 0xb5, 0.001, 200000) ***
Begin repeatSendByte(),....
  Now use a scope to display the SPI signals, MOSI, MISO, CSn, ...

────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
Python 3.7.3 (/usr/bin/python3)
>>> %Run spi_loopback_v54.py

*** testRepeatSendOneByte(spiPort12, 0xb5, 0.001, 200000) ***
Begin repeatSendByte(),....
  Now use a scope to display the SPI signals, MOSI, MISO, CSn, ...
End   repeatSendByte().
>>> 
 
'''
 
# *** End ***

Appendix F - Repeat send byte scope screen captures

Appendix G - Dual MCP23S17 Proto Boards Setup

End of answer

Yes, I was doing my tests in a testing phase in which port A is only inputs and Port B only output. I've read your comment about using Raspberry rails for voltage supply and it sounds interesting. You are the first person that has refered to this fact. I was using an external source 2 days ago and no overheating appears from that day. I'm too much thankful for your great and detailed description. What you say about 3 point. Over current appears when overheats. This is anormal consumption. My writing and reading operations has less than 1mA current consumption. I still reading thw whole post. — Suvi_Eu, Jul 31 '20 at 08:36
Yes, one more reason of not using Rpi's 5V power rail is: (1) If you set many MCP23S17 GPIO pins with big loading high at the same time, there will be a sudden big draw of current, causing a dip at the Rpi power rail, say if lower than 4.5V, Rpi might go crazy and anything can happen. You see I am using a very big cap, 10,000uF by pass capacitor to keep the power supply from fluctuating. (2) One trick you can do is not to switch on/off GPIO pins all at the same time, but ***sequentially, pause 1~10 millisecond one after another***, so the big current rush will be many times smaller. — tlfong01, Jul 31 '20 at 12:57
You might also notice that I am using voltmeter to monitor the power supply, polyfuse and slow fuse to protect over current, and the red power switch, which is sort of "the railway train driver's dead man's handle," Whenever I smells burning plastic, or white smoke rising, I will flip the red switch as fast as lighting, like the kung fu fighting guy.https://www.youtube.com/watch?v=jhUkGIsKvn0 :) — tlfong01, Jul 31 '20 at 13:49
I ain't any kung fu figher, and my hands are trembling, almost always too late to react when seeing any white smoke, or smelling plastic. So I fry chips often. I searched my lab report and found one fried MCP23017 (Don't ask me how many MCP23017 I have fried!): https://www.raspberrypi.org/forums/viewtopic.php?f=37&t=231984&p=1420714&hilit=mcp23017+white+smoke+tlfong01#p1420722. Cheers. — tlfong01, Aug 01 '20 at 03:44
Thanks! But my circuit must not have high consumption, the whole 16 pins consumption are getting as much as 0.25mA. I'm afraid the crazy consumption sounds as a internal short circuit (MCP clamping diodes or TRTs that shouldn't go on but they turns on and GND-VDD became shorted). But the question was: why or what are doing this? So people suggested me to be CMOS technology "latch up" problems. — Suvi_Eu, Aug 03 '20 at 10:07
A couple of short questions. (Q1) Do you have another wired proto board to do swap testing? (Q2) Do you have more than one MCP23S17 chips to do swap testing? (Q3) Did you once power MCP23S17 or other devices with 5V, and connect Rpi GPIO pins to those devices (might cause latching up)? (Q4) Do you have a complete schematic showing all the possible connections, such as which GPIO can connect to which GPIO, or ground. (Q5) Do you have a complete program listing, or a function hierarchy chart, showing which functions related to MCP23S17? — tlfong01, Aug 03 '20 at 13:16
I understand that you might not like to show your program listing to the public, because it is company confidential. (Q6) Is it possible for to switch to SPI 23S08, or I2C MCP23008 or MCP23017. I have been playing with MCP23x08 and MCP23x17 because I often got stuck somewhere and could not find the reason, so I switch from I2C to SPI or back, just to check out if I missed something important. (Q7) Is it possbile for you to switch to I2C PCA9685 PWM controller? — tlfong01, Aug 03 '20 at 13:23
Sorry for the long list of suggestions and typo errors. Just thinking aloud brainstorming. BTW, one more thing, just to repeat, if you have ESD or latch up, almost always the result is instant death, and not recoverable. So your random, intermittent over heating and freezing is not likely to be latching up, but perhaps related to software, just wild guess, not sure at all. Good luck and cheers. — tlfong01, Aug 03 '20 at 13:24
Yet one more thing. Some time ago I found that the SPI pins of my Rpi3B+ was fried, bit everything else still working OK. Since then I always test two SPI buses at the same time, so you see I am testing SPI, 00. 01, 10, 11, 12 at the same time. I usually start with SPI 0,0 and to troubleshoot, I switch to SPI 1,0 to compare and contrast. Perhaps you can also try SPI 10, 11, 12 or even SPI 3, 4, 5 etc. — tlfong01, Aug 03 '20 at 13:35
I don't understand why your total MCP23S17 loading is only 0.25mA. Is it driving ULN2803A which in turn drives relays for AC220V big current AC induction motors? Then you might have huge level surges and need to use TVS diodes to suppress them. You might also need to use optical isolation to prevent surges/noises feeding back via the ground lines. Then you might consider ***Total optical isolation*** at the relay/SSR side. See this post for more details: https://electronics.stackexchange.com/questions/505318/how-to-properly-use-a-relay-module-with-jd-vcc-from-arduino-raspberry. Cheers. — tlfong01, Aug 04 '20 at 04:51
Hi @tlfong01, We are using 3.3V for MCP supply. a) no, we don't. b) no, we have only one and it is 3.3V. c) No, VDD Raspberry Pi pins are connected before powering all. So it's nonticed that overheating appears hours after being working fine with no control sw execution stop. d)e) the complet schematic is what I load. Wires are connected during execution as it must be this way in a real operation. users will take the end of wire and put it over other points (that will receive input wires throught connectors). Port A = inputs, PORT B = outputs. I will try to share the python code soon. — Suvi_Eu, Aug 05 '20 at 12:05
I'm using high level abstaction functions from MCP23S17.py open source library. About your consumption doubt I think it is an obvious thing. 3.3V/100KOhms = 35uA (Internal Rpull up = 100K). Since output loads are the inputs of the same device a small total consumption will be happening. — Suvi_Eu, Aug 05 '20 at 12:08
Many thanks for your clarification. There are still some more things I need to clarify, eg. the ***3.3V/100k = 35uA current***. I have the feeling that we might have a strong disagreement here. I think I need to think hard before I present my argument. — tlfong01, Aug 05 '20 at 12:16
Just a quick note about ESD and Latching up. You might like to read Ref A1.5 in your free time. Nothing urgent or import though. This article is helpful to me because I only know perhaps only 20% of the whole picture or jigsaw puzzle of the ESD and Latch up BTW, I look back at your old comments and I think that you might have read similar articles and therefore have be seeing 50% or more of the picture. Have a great weekend. Cheers. — tlfong01, Aug 05 '20 at 13:39
Thanks @tlfong01, what do you mean with Ref A1.5? Is it the article title? I have spent some days trying to reproduce the latch up triggering but it did not come back again any more, even with a great thunder storm, and nothing wrong happened. I was using Raspberry source, but problem did not occure. I have put osciloscope at Vin in order to see whether voltage falls or not at some moment. But it did not, too. The only thing I'm not doing is to touch wires with my hands. Maybe when I handle proto with my hands Vin wires has experienced some kind of no contact and so, Vin was having glitches. — Suvi_Eu, Aug 14 '20 at 05:50
I need to see a bit more and try with touching wires. This is my next step. I need to see if Vin have fallen when "latch up" triggers. But I also will read the document if I found it. Thanks. — Suvi_Eu, Aug 14 '20 at 05:51
@Eugenia Suarez, Just a quick reply. (1) Sorry, "Ref A 1.5" is a typo, should read "A.15" in my reference list. (2) I think "latching up" is like a snow mountain avalanche, or breaking the camel's back with the last straw. You won't be able to detect the trigger or legging breaking (mos junction breaking down inside the chip) until it is too late. (2) Eg, if you connect a Rpi GPIO pin with a series resistor, say, even 10M Ohm to 5V, current sink at GPIO pin might be very very small, but breaking down a junction does not need a big current, it is the small "crack" that expands to big disaster. — tlfong01, Aug 14 '20 at 08:02
Or you can try the following: "Seven Debugging Steps - @Tony Stewart Sunnyskyguy EE75": https://electronics.stackexchange.com/questions/516359/problem-in-the-output-current-of-an-pnp-current-mirror. (1) Investigate (2) Measure everything relevant (3) Compare with component specs (4) Continue until error (5) Analyze (6) Fix (7) Validate if not Repeat. Have a great weekend. Or try me lazy troubleshooting guy's one and only one troubleshooting trick.Good luck and cheers. — tlfong01, Aug 16 '20 at 03:47
I once played with a hobbyist toy Guiger counter kit, generating over 2kV. Perhasp that can crate static electric charge for you. Or just EMI, not sure: Refs 1: How can a DC spark create EM waves? https://electronics.stackexchange.com/questions/517219/how-can-a-dc-spark-create-em-waves — tlfong01, Aug 19 '20 at 01:34
+1. Nice detail. || Re " ... the chances of catching the ESD virus is very very small." -> Modern ICs tend to be less prone tp ESD damage that in 'the good old days' BUT ESD can still be problematic in some environments. One can be 'lucky' and not realise it and a change of environment can then wreak havoc. Using eg Butyl Rubber (used for roofing) sheets as a bench mat - and cheaper still the outer packing sheets, gives a low ESD benchtop. Carpet can be nasty - a butyl rubber floor mat can help. (Long ago we had a very large %age of EPROM failures - found to be due to ESD. — Russell McMahon, Aug 19 '20 at 06:43

Do the MCP23S17 GPIO pins need protection against latch up ESD within this circuit?

1 Answers1