BMOW title
Floppy Emu banner

Short Circuit Current Experiments

A couple of weeks ago I shared some thoughts about an automated tester for Yellowstone boards, including how to test for short circuits. One of the questions that grew out of the resulting discussion was whether short circuits could only be detected by functional test failures (test results don’t match expected results) or if they could also be directly detected by measuring the supply current. A second question was how large the short circuit currents would typically be. I’ve recently done some tests to help answer these questions.

There are several different kinds of shorts that we need to think about:

  • shorts between power supplies, where short circuit current flows whenever the power is on
  • shorts between a signal and a power supply, where short circuit current only flows for certain signal values
  • shorts between two signals, where short circuit current only flows for certain pairs of signal values
  • shorts where the current source comes from the device being tested
  • shorts where the current source comes from the equipment that’s connected to the device

Most of Yellowstone’s external IOs pass through 74LVC245 buffers. All of the tester’s IOs will pass through MCP23S17 port expanders. So I intentionally short-circuited some samples of both chips, alone and then together, to see what would happen. Here’s what I found.

  • 74LVC245 with a 3.3V supply, and one logical high output short-circuited to ground: 70 mA short-circuit current
  • 74LVC245 with one logical low output short-circuited to 3.3V: 110 mA
  • MCP23S17 with a 5V supply, and one logical high output short-circuited to ground: 30 mA short-circuit current
  • MCP23S17 with one logical low output short-circuited to 5V: 50 mA
  • 74LVC245 logical high output short-circuited to MCP23S17 logical low output: 50 mA
  • 74LVC245 logical low output short-circuited to MCP23S17 logical high output: 30 mA

These currents are all large enough that it should be possible to reliably measure and detect them as deviations from the normal supply current (expected to be something in the range of 100 to 200 mA). So is this a good approach? Will it work? I’m going to try it and see, and if it’s successful then the tester will be that much more useful. If it’s not successful, I won’t have lost anything but some time and a few dollars worth of parts.

Why do this at all? Isn’t functional testing enough, with the assumption that any short circuit will cause a test failure somewhere? I say… maybe. In a perfect world, any short circuit would result in a functional test failure, but I don’t live in a perfect world. If I can do something to help detect shorts that functional tests missed, or that don’t result in test failures 100 percent of the time, I think that’s a good thing.

For how long do I need to measure the current? If the tester changes some IO values, waits a microsecond, and then measures the new supply current, is that enough? Or will capacitors on the voltage supplies smooth out the current from short circuits, so that microsecond-level measurements aren’t useful and I need to wait milliseconds or longer to get useful data? I’ll just have to try it and see.

If I measure the current, which current should I be measuring? I’m not quite sure. It might seem that I should measure the 5V supply current for the Yellowstone board (the device being tested). That would catch problems where there’s a short circuit between two elements on the Yellowstone board, whether they’re signals or supplies. It would also catch problems where a Yellowstone input signal was shorted to 3.3V or 5V, creating short-circuit currents whenever the connected equipment tries to drive a logical low to the input. But it wouldn’t catch problems where a Yellowstone input was shorted to ground.

In a case like that, short circuit current would flow whenever the connected equipment tries to drive a logical high value to the input. But since the current would be coming from the connected equipment, and not the Yellowstone board, measuring the Yellowstone supply current wouldn’t help. Maybe this is a rare enough case that I shouldn’t worry about measuring these currents, and I can just assume any such problems will be caught by a functional test.

Read 1 comment and join the conversation 

1 Comment so far

  1. Tux2000 - September 14th, 2021 11:07 am

    “Why do this at all? Isn’t functional testing enough, with the assumption that any short circuit will cause a test failure somewhere? I say… maybe. In a perfect world, any short circuit would result in a functional test failure, but I don’t live in a perfect world. If I can do something to help detect shorts that functional tests missed, or that don’t result in test failures 100 percent of the time, I think that’s a good thing.”

    I’ve already commented that. Let me repeat:

    1. Measure supply voltage and supply current in idle (all pins except supply and GND at high impedance), compare the latter with a known-good sample. Power the DUT from a current-limited supply, so that the magic smoke won’t escape. That’s all analog measurements that a pure digital circuit will need.

    2. Have the DUT generate test patterns (walking 0, walking 1, alternating 0/1, all 0, all 1, etc) on as much output pins as possible. Have the tester generate the respective patterns on all inputs of the DUT. Compare the generated pattern with the expected pattern. Make sure that the inputs have pull-ups while expeding a 0, and pull-downs while expecting a 1. That will detect any broken lines and any relevant shorts on all DUT inputs and outputs. For that, you need a different FPGA configuration just for testing. Once the test is done, you reprogram the FPGA with the final configuration.

    When implemented right, this is a 100% test, it will literally test every pin.

    You need between two (UART, I²C) and four (SPI) lines between the tester and the DUT, so you can’t explitictly test those lines. But the test will report tons of errors when the communication fails, because the patterns won’t be generated and/or won’t be read back.

Leave a reply. For customer support issues, please use the Customer Support link instead of writing comments.