1
\$\begingroup\$

I designed a system with RaspberryPi and STM32F407's, communicating with each other via SPI interfaces.

For the last 3 months, tests were OK but yesterday a RaspberryPi and 2 of STM32F407's SPI ports were burn out. I don't know why. Everything was working, I went to sleep, everything was burned out in the morning.

Here is the implementation sketch:

Topology sketch

Modules' real pictures

PCB's are 15 cm long. SPI lines are parallel. No chip-select lines are used. No termination resistance used. SPI frequency is 200 kHz. Power supplies are 5V 1A usb charger for RaspberryPi, LM2576 3.3V circuits (implemented by myself) converting 24V to 3.3V for MCU's.

I hot plugged my modules around 10 times with no problem (why hot plugging would be a problem with SPI?) although according to Wikipedia article, SPI is not hot pluggible.

  1. So, what could possibly caused that damage? Standing waves? Hot plugging? Or maybe power supply? How can I find the root of this issue?
  2. Do I need to use optic isolators (or cmos buffers?) for each of MCU unit?
\$\endgroup\$
2
  • \$\begingroup\$ What exactly do you mean by "burned out"? Was there physical damage? \$\endgroup\$
    – Dave Tweed
    Mar 16, 2014 at 14:25
  • \$\begingroup\$ It seems so. RaspberryPi's mcu was too hot to touch. \$\endgroup\$
    – ceremcem
    Mar 16, 2014 at 14:44

1 Answer 1

Reset to default
3
\$\begingroup\$

You have a very long SPI bus running across several PCBs. Not only is this not recommended for SPI — it was originally designed for chip-to-chip communications on a single PCB — you have it connected directly to your CPUs without any electrical buffering.

Any induced transient (which could include ESD while hot-plugging) on any of the bus lines could easily drive any of your CPUs into "CMOS latchup", in which a parasitic SCR is activated that essentially shorts Vdd to ground. Physical damage from the resulting temperature rise can be permanent.

SPI is particularly easy to buffer, since each of the lines is unidirectional. You should include such buffers on the next revision of each of your PCBs.

\$\endgroup\$
8
  • \$\begingroup\$ Do you think any electrical buffer (like 4050 or 74245 ) is enough or optical isolation is mandatory? \$\endgroup\$
    – ceremcem
    Mar 16, 2014 at 17:47
  • \$\begingroup\$ No, I don't think you need optoisolation. Any electrical buffer that's rated for a reasonable level of ESD should be fine. \$\endgroup\$
    – Dave Tweed
    Mar 16, 2014 at 19:02
  • \$\begingroup\$ I have tried to buffer with 4050 and MAX485 so far, but they can not successfully transmit the clock signal. I'll try some other ic's tomorrow. If I understand correctly, I don't need to be afraid of ESD if I use a buffer with ESD protection? Then I may hot plug my modules, right? \$\endgroup\$
    – ceremcem
    Mar 16, 2014 at 22:14
  • \$\begingroup\$ You won't damage them electrically, but there are other issues with your hot-plug scheme. Since you don't use the chip selects, which normally provide the byte alignment of the data on the SPI bus, you could plug in a module in the middle of a transaction, and it would be forever out of sync with the rest of the system. \$\endgroup\$
    – Dave Tweed
    Mar 16, 2014 at 22:44
  • \$\begingroup\$ I used 74HC244 for buffering and for the first few tests it was OK. I hot plugged my module several times and there is nothing burned out. The sync problem is not observed mostly, when it occurred my software took care of it. But then, interestingly the buffers are burned out. I replaced them, hot plugged my module and then all buffers burned out again. I'm out of the buffer chips, so I'll have to wait till tomorrow for more tests. \$\endgroup\$
    – ceremcem
    Mar 19, 2014 at 1:08

Your Answer

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

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