Reliability of Serial IO Expander like MCP23S17

Question

Background:

I am doing a re-design of an existing system moving from HC11 base with memory mapped I/O to an ARM Cortex-M3 with serial SPI/I2C I/O (opto-isolated inputs and relay outputs). I/O access will be via serial SPI or I2C to I/O expander chips (MCP23S17). 2 Chips per board for 32 I/O points each, and up to 4 boards can be stacked/interconnected via short ribbon cable for the SPI buss. The microprocessor board will be stacked on top of the main I/O board and have access to additional I/O boards via the SPI buss as mentioned above.

Question:

Is going this serial route, SPI to MCP23S17, going to be rock solid reliable in accessing the I/O points or will the serial nature just be too susceptible to noise and/or other related problems?

This is mission-critical control system running 24/7 7 days a week, polling the I/O say between 500Hz and 1kHz. I want the SPI bus speed to be around 2MHz, so not all that fast but also not slow.

In 20+ years with my current HC11 memory mapped design with the I/O being accessed over a 3ft 50pin ribbon cable, I have never had a single issue but I am concerned that moving to a serial SPI-based design could start causing all sorts of problems.

Would appreciate any of your thoughts and experience with this.

Answer 1

The MCP23S17 is reliable but some quirks are:

1. Vih is rather high (it is proportional to Vdd) so verify that whatever is driving any input pins will meet and exceed the Vih parameter.

2. It can miss interrupt-on-change events because reading the interrupt acknowledge register (GPIO or INTCAP) clears all eight bits of that port. If another interrupt-on-change occurs on a different pin of the same port during the read, by the time the read operation finishes (say within a 500us window) you've lost that information that another one happened. You can safely receive one interrupt-on-change event on each port at most, not eight.

3. The interrupt-on-change functionality can be edge sensitive (both edges) or level sensitive, but you can't pick rising edge only or falling edge only. In level sensitive mode if you acknowledge an interrupt-on-change event but the active level still persists, then you get a glitch on the interrupt line a few tens of nanoseconds long. This could get filtered out by your MCU or it may trigger a second interrupt so be careful.

4. Check the errata for an addressing issue relating to the HAEN bit of the IOCON register, there's a work-around Microchip describes for it. Not a show-stopper but the datasheet doesn't address it, only the errata does.

Answer 2

A properly designed SPI link should be fine; think about how many mission-critical systems run over busses like Ethernet or CAN. Nothing 'inherently' wrong with a serial communications link, but you can be smart about it in your design.

For example, at the software level, you can introduce robust error-handling, and do things such as re-reading values after a write to a register to ensure that what you wrote to it is what actually happened.

From a hardware point-of-view, you can look at some of the many app-notes out there for 'long-distance' SPI. Some of the strategies include converting to differential for the cable run, and then back to single-ended at the receiving node. Not that 3-feet is particularly "long", but differential is an easy way to buy yourself noise immunity.

Also consider system-level design; in the event of 'loss of comm', is that a detectable fault? Can you send a dumb heartbeat signal along the harness that will put the I/O into a "safe" state if it fails? These are a few extra wires, but you could probably cram all of this into a 9 or 15-pin D (or micro-D) type connection.