0
\$\begingroup\$

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

We are using A bank GPIOs for reading, and B bank GPIOs for writting. 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 at 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 being not connected to anything ('Z' state/open circuit).

Input pin is configured with internal R pull up in order to read VDD when not connected.

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

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

enter image description here

When reads GND:

enter image description here

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

At pictures it can be seen that Reset and Address signals has no R 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.

Application works making thousands of writing/reading in a loop.

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

The problem:

But suddenly the device is reaching too much temperature, I think it's closer to get burn. Here, reading fails. Even the two contiguous GPIO pins starts changing its input values when they are not connected to anything.

When it ocurres I can see how the multimeter reads 2.8v instead 3.3V from VDD Raspberry pins. 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 to normal and it works fine.

What can be happened? Why is the device getting this consumption? Would does it need to put resistors at address or reset pins?

schematic

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 sw gives me feedback about when an input toggle its input value. I can see by screen how when overheating has started, a long toggle-switching is produced before get the stable. As long as toggle time is, then so closer to start the undesired behavior.

I have done a hw debouncig to an input with a 1uF capacitor and toggle has minimized until almost being completely avoided.

Thanks in advance.

\$\endgroup\$
18
  • 2
    \$\begingroup\$ 1. Regardless of your opinion, you do need decoupling capacitors on the power supply pins of the IC. \$\endgroup\$ – JRE Jul 17 '20 at 13:41
  • 1
    \$\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 Jul 17 '20 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 Jul 17 '20 at 14:02
  • 1
    \$\begingroup\$ Do you really have the power wires jammed into the same breadboard holes as the IC? Please post a photo of your setup. \$\endgroup\$ – Bruce Abbott Jul 17 '20 at 14:15
  • 1
    \$\begingroup\$ You can monitor the current intake by placing your multimeter in current mode in series with the MCP23S17. Are in_1 and out_1 connected if the heating happens? How did you configurate the "unused" pins? As inputs or as Outputs? Did you enable the pullups for the unused inputs? Background is that non terminated inputs can start floating which can result in undefined behaviour. \$\endgroup\$ – Christian B. Jul 18 '20 at 9:30
0
\$\begingroup\$

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.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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