Circuit is a Raspberry Pi 4A SPI master node talking with one MCP23S17 device. I'm testing the single-circuit version in a protoboard.

We are using A bank GPIOs for reading, and B bank GPIOs for writing. From them, two GPIOs will be used with wires, one belongs to the input bank and the other one belongs to the output pins group. So Out_1 and In_1 both will have one wire connected at each pin, as can be seen in the picture.

At the end of the wire it could be contact between out_1 wire and in_1 wire or not. So in_1 wire could be reading from out_1 pin or not connected to anything ('Z' state/open circuit).

The input pin is configured with an internal pull-up in order to read VDD when not connected.

Normally out_1 will ever be writing '0', so every time in_1 is connected to out_1 --> in_1 will ever read a '0' value.

The circuit can be seen in the following pictures, when it reads '1':

enter image description here

When it reads GND:

enter image description here

This circuit is working at 1 Mhz. As you can see MCP is fed with Raspberry supply pins. They don't need extra capacitors because the Raspberry provides 100 nF at their 3.3 V and 5 V pins.

In the pictures it can be seen that Reset and Address signals have no pull-up, because they will be by the moment to VDD or GND constantly, with any value change. Resistors will be added to the final design where Rst will come from another digital source, instead of VDD.

The application works making thousands of writing/reading in a loop.

It can be working fine during most of the time, for hours.

The problem:

Suddenly the device is reaching too high a temperature, I think it's close to getting burned. Here, reading fails. Even the two contiguous GPIO pins start changing their input values when they are not connected to anything.

When it ocurrs I can see how the multimeter reads 2.8 V instead of 3.3 V from the VDD Raspberry pin. So, it seems to be an extra current consumption, but I don't know from which pin and why.

This situation stops if the device is reset. After making a reset, the temperature falls back to normal and it works fine.

What could be happening? Why is the device getting this power consumption? Does it need resistors at address or reset pins?


simulate this circuit – Schematic created using CircuitLab

Added after posting and some new tests:

I have realized when overcurrent starts. By the moment during a week under test I can say when it happens: when I handle wires and push one of them into the GPIO input pin hole. My Python control software gives me feedback about when an input toggles its input value. I can see on the screen how when overheating has started, a long toggle-switching is produced before becoming stable. The longer the toggle time is, the closer is the start of the undesired behavior.

I have done a hardware debouncing to an input with a 1 μF capacitor and toggle has minimized until being almost completely avoided.

  • 10
    \$\begingroup\$ 1. Regardless of your opinion, you do need decoupling capacitors on the power supply pins of the IC. \$\endgroup\$
    – JRE
    Commented Jul 17, 2020 at 13:41
  • 4
    \$\begingroup\$ 2. The address and reset pins require external pull ups which you don't provide. \$\endgroup\$
    – JRE
    Commented Jul 17, 2020 at 13:43
  • 4
    \$\begingroup\$ 3. A schematic diagram is normally more useful than a wiring diagram. A wiring diagram or photo of the built circuit can be useful when looking for assmbly errors, but require a schematic to be truly useful. \$\endgroup\$
    – JRE
    Commented Jul 17, 2020 at 13:44
  • 1
    \$\begingroup\$ @JRE I agree with you on the bypass caps, it might be the reason why it fails. But the address pins are directly grounded, and reset is directly connected to VCC, so the pull-up resistors you mention would not do anything. \$\endgroup\$
    – Justme
    Commented Jul 17, 2020 at 14:02
  • 4
    \$\begingroup\$ Yes, you still need the capacitorson your breadboard despite there being capacitors on the Pi. You have long wires between the Pi and the breadboard. Long wires act (a bit) like inductors, so you need local capacitors on the breadboard. \$\endgroup\$
    – JRE
    Commented Jul 20, 2020 at 6:03

2 Answers 2


This circuit is working at 1 Mhz. As you can see MCP is fed with Raspberry supply pins. They don't need extra capacitors because the Raspberry provides 100 nF at their 3.3 V and 5 V pins.

This is incorrect -- bypass capacitors can't be placed just anywhere. Signals travel at the speed of light, and this causes locality to matter. In particular, for the lower frequencies and impedances that tend to matter for power supply connections, wire/trace length is proportional to inductance.

Your construction has significant inductance between chip supply pins and the nearest bypass: given the breadboard layout, maybe ~100nH. Considering logic ICs like this consume 10s to 100s of mA in mere ns, an inductance in the 10s of nH is required, to avoid it glitching its own supply voltage. A capacitor placed beside the IC and jumpered close by, or with long enough leads to stradde over the IC itself, will do. Avoid using premade jumpers of long lengths arching over the board; use short jumpers trimmed to length.

The stray inductance brings another problem: any ESD incident on the circuit, finds basically all paths through breadboard wires to ground. Supply and logic pins will both experience significant ESD current when struck, activating ESD diodes, and making CMOS latchup likely.

I have realized when overcurrent starts. By the moment during a week under test I can say when it happens: when I handle wires and push one of them into the GPIO input pin hole.

This act may support the conclusion of ESD-induced latchup: without ESD handling practices, it's likely that a wire in hand provides discharge path from body charge, into the IC.

Latchup occurs because the ESD clamp diodes aren't actually diodes, but have parasitic BJT behavior as well. In particular, both NPN and PNP are present, close enough to create an SCR. At low currents, simple clamping occurs (with some current sunk to GND and VCC simultaneously), but at high currents, enough multiplication occurs, the SCR behavior gets triggered, and latchup occurs. Latchup remains active until the power supply is removed.

You might also have corruption of state and shorting through grounded pins becoming set as output, or rapid toggling into debounce capacitors. These can also cause heating.


I don't know yet if this could be the optimal or final solution. But I have realized when overcurrent starts at my circuit.

By the moment during a week under test I can "say" when it happens: when I handle wires driving other logic state value and push one of them into the GPIO input pin hole.

My python control sw:

  • configures bank A as inputs with Rpull up, bank B as outputs that writes '0' value every time.

  • gives me feedback about when an input toggle its input value by console.

When overheating has started it has been showing how a long toggle-switching is produced before get the stable/final value. As long as toggle time is, too closer to start the undesired situation system is. That makes sense with CMOS literature about switching inputs and overheating.

I have done a hw debouncig to an input with a 1uF capacitor and switching has minimized until almost being completely avoided. But it seems not to trigger the overconsumption. I have not any more overconsumption after debouncing. At least one of the causes here seems to be this.

And so according with this discovering:

It seems to mean that I should be using a number of capacitors = 64 (1 capacitor for every GPIO pin on my board). At this point I don't know whether 64 capacitors is too much or not, it is good or not, etc. I don't use to see examples with one capacitor at every MCU GPIOs that will have more switching value time than my design.

I'm now working on this point.

  • 3
    \$\begingroup\$ You absolutely don't need those capacitors. Just use a resistor, say 100k, to pull each GPIO pin to ground or VCC. Or drive those pins as outputs. You must do one of those things: CMOS inputs don't like floating, not even Schmitt trigger inputs. \$\endgroup\$ Commented Sep 21, 2022 at 22:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.