3
\$\begingroup\$

I need to protection data lines of a PIC32 micro-controller (SPI and parallel) running at ~10 MHz, from shorting to ground/Vcc or mis-wiring.

I usually (in low speeds) use series resistors to limit current and it worked well, but of course this does not work now because of the speed.

I am thinking to use line buffer/inverter (something like 74LVC04) this will save the MCU but the buffer will get damaged.

I searched many logic families (ACT , HCT , LVC etc..), but none provide short circuit protection.

I there a better solution?

Edit After Comments: This is a development board for testing and validation, due to coding mistakes pins can be configured incorrectly . or mis-wired , connecting MCU output to target output instead of input.

Edit #2: A PTC (0603L004) might be a solution however it is slow !

| improve this question | | | | |
\$\endgroup\$
  • \$\begingroup\$ "Miswiring": so, this is an external bus. Does it go through connectors? Where does it go? What's the distance? What kind of data do you transport over there? How many parallel lines? \$\endgroup\$ – Marcus Müller Apr 5 at 22:58
  • \$\begingroup\$ It's probably best to describe your use case, overall. "miswiring" sounds like something you avoid using connectors that can't be plugged in incorrectly. \$\endgroup\$ – Marcus Müller Apr 5 at 23:02
  • \$\begingroup\$ Did you check the micros reference manual? Typically the micro would have its own protection. Are you trying to protect something other than the micro? \$\endgroup\$ – Carl Gilbert Apr 5 at 23:05
  • \$\begingroup\$ @Marcus, I edited the question. Carl . the micro can supply abound 20mA , but it is not protected so it will not do current limiting. \$\endgroup\$ – ElectronS Apr 5 at 23:14
  • 2
    \$\begingroup\$ Ahh. Well perhaps you can first configure as IO. Them set the output briefly and read the result. If it sits at 0 when you drive a 1 or 1 when you drive a 0 then refuse to engage the SPI. \$\endgroup\$ – Carl Gilbert Apr 5 at 23:23
5
\$\begingroup\$

CMOS drivers have an inherent current limit set by the drain-source ‘on’ resistance of the output driver FETs, Rds(on). You can infer this from the datasheet based on Vo(h) and Vo(l) for a given output current.

As an example, the PIC32 datasheet list Vo(l) as 0.36V at 6mA, which corresponds to an Rds(on) 60 ohms. That's kind of a weak driver. Shorting it to 3.3V would give 55mA, which is more than the datasheet allows (16mA), a pretty tight limit. That said, a short on one pin won't necessarily damage the part.

The bigger problem often is ESD damage. Stuff that goes off board can benefit from additional TVS diodes to increase the ESD robustness.

| improve this answer | | | | |
\$\endgroup\$
  • \$\begingroup\$ best answer so far. Good point you raised about the RDSon , ESD can be managed since there is so many TVS arrays readily available. So maybe I would add a small resistor in series such that it won't affect speed (47 ohm ?), but will help in increasing Rds On to guarantee that a short won't damage the part, what do you think ? \$\endgroup\$ – ElectronS Apr 6 at 13:51
  • \$\begingroup\$ The series resistance introduces a trade off of limiting vs. speed. At 60 ohms the output impedance is just about right for driving a board trace (60-65 ohms typical for a non-controlled line on 4L stack up.) Adding more will result in a mismatch in mist cases, and rise time will be affected. \$\endgroup\$ – hacktastical Apr 6 at 15:45
6
\$\begingroup\$

OK, in all honesty: then the purpose of the development board is to learn to avoid these mistakes.

The solutions to this particular problem (needing error-resistant high-speed off-board communications) usually involve transition to a specific far-reach bus.

Your "problem" has a "solution" that would make your original problem, talking to peripherals, so much more complex that it's not really a "solution" any more.

If your peripheral can destroy your controller, then take care to not wire it incorrectly. That's typically not really hard, compared to other engineering pitfalls. For example, you'd design an adapter board that has one side very clearly labeled "signal" and one side labeled "output", and if possible, two different connectors on each. Problem solved.

| improve this answer | | | | |
\$\endgroup\$
  • \$\begingroup\$ thank u for the answer , but for learning purposes i want to study a solution not a walk around or prevention . maybe specific IC that solves my problem simply . for example there are many RS485 transceivers that has such protections and more . However i have not found "yet" something similar for SPI or parallel ports \$\endgroup\$ – ElectronS Apr 5 at 23:52
  • 2
    \$\begingroup\$ But you're not learning anything about a real-world problem: In a proper design, on-board miswirings are no problem. If you have an off-device bus, yes, something like RS-485 is the right solution. But you don't. Hence, not having that is the right solution here. If you want to learn about an off-board bus, you need to specify what kind of bus (that's all the questions I've asked in my first comment under your question), then you'd decide what kind of bus. \$\endgroup\$ – Marcus Müller Apr 5 at 23:58
  • \$\begingroup\$ @ElectronS RS485 as a topology is meant for long-distance milti-drop network, so there is expectation for exposed wires being hooked up to equipment by just about any regular Joe. Interfaces like SPI are usually internal geared towards trained or semi-knowledgeable technicians to wire, or have polarized connectors that only go in one way. \$\endgroup\$ – Dmitri S Apr 6 at 3:11
  • \$\begingroup\$ @DmitriS , I do understand your point In a finished product this is not an issue . but consider the following , This development board has the unused pins connected into a simple header ( like arduino ) , if another person wants to use this board to test his eeprom that he has on a breadboard . he can easily wire something in wrong manner and my question was about how to prevent that. \$\endgroup\$ – ElectronS Apr 6 at 13:59
  • \$\begingroup\$ @ElectronS I don't think there's a solution to that problem that isn't way more complex than the complete system you have so far or severely flawed in flexibility. You're trying to solve an issue that is none. Dedicated, keyed connector. If they wire that up incorrectly, really not your fault. If you work with electronics, you need to get basic low-wire-count connections right. \$\endgroup\$ – Marcus Müller Apr 6 at 14:16
3
\$\begingroup\$

I am an electrical engineer. I have worked on microprocessor-based designs of a lot of products. I have occasionally miswired things (more times than I would like to admit). Also, at some point we have to give our hardware to firmware engineers and they wire things up wrong all the time, too. I have never seen a GPIO get fried due to being short-circuited to VCC or GND or to another output. Obviously I don't recommend doing it on purpose, but I have done it more times than I can count, and had FW engineers do it wrong, too. I don't think you need to worry about it unless you are going to expose the output to a voltage greater than VCC or less than GND.

The only thing I have done on occasion is used external logic to make sure that the FW team can't accidentally create a "forbidden state." (Like turning on the high and low side of a bridge simultaneously to create shoot-through).

| improve this answer | | | | |
\$\endgroup\$
  • 1
    \$\begingroup\$ thank u , really thank for restating my point , that during development mis-wiring happens especially if this is not a finished product and wiring is not in a finalized state . I feel relieved that GPIOs shorting doesn't fry the port or the chip. \$\endgroup\$ – ElectronS Apr 6 at 13:45
2
\$\begingroup\$

The problem with modern MCUs is the tiny size of the FETs, and the enormous local-heating temperature rise rates.

I recall computing dTemp/dTime of 1,000 degrees per microsecond for such (tiny) FETs, with many milliWatts dissipated in a square micron or two, and the large thermal resistance of cubes of silicon that are only 1 micron on a side.

==================================

For over-temperature protection, any temp-sensor needs to be within 10 microns of the hot-spot. If the hot-spot is deep submicron output FET, short channel for high drive, the FET can self-destruct before high temperature is detected.

Practical solution? At high temperatures, the FET becomes less conductive. Or detect the overtemperature and turn off the FETs (area expensive, to do that).

I recall stories of era-1995 MCUs that self-destructed when outputs shorted.

| improve this answer | | | | |
\$\endgroup\$
  • \$\begingroup\$ So do you mean there is no practical solution in silicon ? Sorry but I really didnot get the answer \$\endgroup\$ – ElectronS Apr 6 at 13:47
0
\$\begingroup\$

One way to protect is to galvanically isolate the bus from the MCU by using digital isolators, example. These work well at high speeds and are more reliable than for example optocouplers. There are also specialized parts specifically intended to be used for SPI, I2C etc.

Though this solution is mainly used when you expect the secondary to be noisy and want to avoid EMI, voltage surges, ground currents and other nasty stuff from hitting your MCU directly.

| improve this answer | | | | |
\$\endgroup\$
  • \$\begingroup\$ for your solution to work , the isolators should be short circuit protected , otherwise this doesnot change anything \$\endgroup\$ – ElectronS Apr 6 at 13:41
0
\$\begingroup\$

Perhaps you can first configure as IO. Them set the output briefly and read the result. If it sits at 0 when you drive a 1 or 1 when you drive a 0 then refuse to engage the SPI.

I'm also an EE but mostly I write software. I agree with one of the previous commenters that said you should protect anything that leaves the board from ESD. So TVS diodes should definitely be present. If any of the pins in the connector have more than 5V then you should protect your other pins from that higher voltage as well.

| improve this answer | | | | |
\$\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.