Broken SPI Pins on Electron

I’m trying to get multiple (up to 16) RC522 RFID readers to work with the Electron using a custom made PCB. Generally, it works great - I’ve had success with connecting 8 of them sharing the same SPI bus, but with individual SS (slave select) lines to each reader using a shift register and a customized RC522 library.

However, at random intervals the SPI bus will simply stop working on the particular Electron. It seems to be permanent and I have to use a new one (I’ve been through 3 Electrons so far). Everything else on the Electrons still work fine, even the other SPIs (SPI1 and SPI2). I’ve tested the circuit with a multimeter to find electrical problems, but I haven’t been able to identify any problems - there are no short circuits, and the pins are only exposed to 3.3V as far as I can tell. The behavior of the SPI pins after they are “broken” is that they simply output a flat 3.3V with no working SPI communication with the RFID readers, until I either change to one of the other SPI buses (using a breadboard) or install a new Electron on the PCB, and everything works great again for a while with the exact same firmware and hardware setup. I haven’t been able to pinpoint exactly when the problem arises, but generally it will work fine for a few days.

I’m using the standard SPI bus on pins A5, A4 and A3.

Any idea of what could cause (potential) damage to the SPI pins from this setup, assuming there is no excessive voltage on the pins? Or alternatively, anything that could interfere with the SPI pins (clock speed or similar) that can make them go into this state - and stay that way, even after reflashing the firmware?

Btw., these are the readers I’m using: Getting the RFID-RC522 to work! [SOLVED]

Thanks!

Hi @anders1

This sounds like an ESD (electrostatic discharge) problem to me. People create static electricity (many thousands of volts sometimes) and when you get that little shock from touching metal, that static electricity is discharged into whatever you touch. If what you are touching when it discharges has electronics in it, the electronics can be permanently damaged.

The path by which ESD gets in can be hard to find. Products can be tested for ESD problems.

Are there long wires to the readers? That is another thing that can make ESD problems worse.

1 Like

Thanks for your reply, @bko ! I did consider electrostatic discharge - and while it definitely is a possibility, I don’t think it caused it in this case since I was careful not touching any electronics while testing. Also, it seems weird that ESD would consequently cause the SPI pins to fail specifically.

However, one thing I discovered is that I might by mistake have enabled multiple slaves at the same time in code (setting all slave select pins to LOW, which enables all RFID readers, possibly causing a bus conflict). Do you think that (one instance of) activation of multiple slaves simultaneously could cause damage or synchronization issues that persist even after correcting the code mistake?

So ESD sounded plausible simply because only the SPI pins have failed. Usually ESD or some other electrical problem is only way something like that can happen.

SPI can be a parallel wired or a daisy-chain wired protocol but either way, the MOSI pin of the Electron should only be connected to inputs on the other devices so no conflict should be possible. Maybe you have some other wiring problem? The MOSI pin on the RF522 is shared with D6/Addr0 functions so maybe the readers get into a non-SPI mode somehow.

It sounds like you have blown-out the lower N-FET in the output which makes the outputs not able to be pulled low. You could test this by putting test code on one of the “bad” Electrons on a breadboard and checking the voltage of the A5 output as a GPIO pin. Just a write a simple program to drive A5 high for ten seconds and then low for ten seconds and you can check it with a scope or voltmeter, but I think you’ll find it does not pull low.

If you don’t find an obvious problem, I would suggest trying a 100ohm series resistor on MOSI and SCK between the Electron and the other devices.

1 Like

Thanks again, @bko! I tried your suggestion of testing the A5 (MOSI) pin - and quite accurately, it is never pulled low. One Electron stays at 3.3V, and another only drops to around 0.9V. The other SPI pins on the other hand work fine.

So what do you think could have caused the damage to A5? ESD again?

Thanks so much for your help on this, it’s very appreciated!

You could show us a picture of your wiring and we might be able to help more.

It pretty much has to be a wiring problem or ESD, I think.

1 Like

It’s a rather complex PCB, but I will see if I can upload a picture later!

Can you explain how you knew that the problem was the A5 pin and not any of the other SPI pins?
Also, do you know how much it would approximately take to destroy a pin? I measured that by default, the RC522 output 0.9V on the MOSI line when not it use, simply when powering it up. Could that be a problem, or does the voltage have to increase beyond 3.3V?

Thanks again!

The MOSI pin (A5) is just the most likely to have its failure cause a total failure of SPI. It could have been the SCK pin or both.

Let’s imagine that all of your RF522’s are doing approximately the same thing at the time in the failure case. If they are all trying to pull MOSI high due to some failure and the Electron is trying to pull MOSI low, then it is 16-to-1 against the Electron and the Electron’s N-FET output transistor is going to blow out. That is why the 100ohm resistor in series works–it gives the 3.3V difference a place to go (as heat from the resistor) when there is a conflict.

That doesn’t explain why there is a conflict, which is why your wiring is important.

1 Like

That makes sense, thanks a lot @bko ! I took your suggestions into account - added 100 ohm resistors on SCK and MOSI lines on the current PCB and temporarily did some shielding with isolation tape to protect from ESD as much as possible. In the final version, the PCB manufacturer can hopefully coat the boards so they are more permanently protected.

Anyway, it has worked beautifully ever since - very stable, and even more so when lowering the clock frequency (I know that there’s a lot of wiring going on, which increases the load capacitance, but it seems that the lower speed compensates for that - even at 50 kHz they still read really quickly!)

1 Like