SPI, MCP23S17 and LA probe difficulties

[WaveyDipole]

I wasn't quite sure which category to fit this. It relates to Microcontrollers but relates specifically to the SPI bus and the MCP23S17 chip. It covers issues with the LA probe on my new MSO5000 series scope so does it fall under Test Equipment? It seems that both LA probe and possibly two microcontroller boards have faults, so Dodgy Technology perhaps? In the end I decided it was more generally "Technical Stuff", but too technical to be General discussion and probably not Beginner. However, if its in the wrong place, then by all means, mods, please move to the appropriate category.

In short, I have been having some problems communicating with an MCP23S17 chip via SPI. The story starts over a year ago, I purchased an MCP23S17 and set up a test jig on a breadboard, built a test program, uploaded it to a Mega 2560 and was pleased when all worked as it should. I then added the routines to a particular project. I then started work on the I2C version (MCP23017) and got this working to a point, but it proved unreliable. Eventually, for some reason the MCP23017 gave up. I then reverted to working with the SPI version (MCP23S17) which promptly got fried as well. No magic smoke, no heat. Just stopped working. I don't know why they both got fried, but suspected maybe an overload.

More recently I purchased a new MCP23S17 along with some 270 ohm current limiting resistors to use on the GPIO outputs. So far I have only connected up some LEDs on the PORT A side of the MCP23S17 and the chip was hooked up on the breadboard to a Nano. I loaded up the previously wortking test program but none of the LEDs would light up. (Option 1 should light up Led 8 on GPIO 7, option 2 should light up Leds 2-8, option 0 should turn them all off). I therefore set about investigating this further which became a bit of a saga.

I hooked up the SPI pins to my new MOS5000 oscillscope using an LA probe, the eBay one purchased from the US:

https://www.ebay.co.uk/itm/224648789536

This is the first time I have had the occasion to use it since receiving it in January. I then configured the LA, trigger and SPI decoder. The result looked rather weird. The second byte was being broken up into 3 values and the third into two. The CS signal had spikes which coincided with the split point of the values. An analog channel was attached to the CS signal and although there was some noise, it was at no more than 100mV (dupont wires + probe ribbon cable probably contribute) which was well below the threshold of 2.7V so should not have been causing the spikes. CS was moved from pin 10 to pin 8, but with the same result.

The Nano was then swapped out for a spare LG8F328P board which has the same pinout. The spikes on CS were gone, but the numbers were all wrong and the MOSI signal trace looked completely wrong.

A UNO dev board was hooked up instead of the LG8 and the LA waveforms now looked a lot more convincing, but the numbers for the sent bytes were still all wrong.

At this point I should perhaps explain that writing to the MCP23S17 requires a group of 3 bytes - a command byte(read/write), a register byte (port A, port B, or other register to write to), and finally a data byte. During startup, the program sends a total of six write commands which should result in 18 bytes being sent. The output shows only 5 bytes and after the last byte, the pins are left in the wrong state. The byte sequence should be:

0x40, 0x0A, 0x08
0x40, 0x00, 0x01
0x40, 0x0C, 0x01
0x40, 0x01, 0xFF
0x40, 0x0D, 0xFF
0x40, 0x12, 0x80

Instead, the decoder shows random data so for the next step, MISO and MOSI were disconnected from the MCP23S17 chip to eliminate interferance due to a problem with the MCP23S17. The result was unchanged.

The analog probe was now moved from CS to the MOSI channel. The analog pattern did not match the LA trace. Manually comparing the analog trace to the clock did yeild the correct bit values however:

0x40, 0x0A, 0x08
0x40, 0x00, 0x01
...

So what was the issue with the decoder? Probe wire D1 was disconnected from MOSI and attached to the CLK signal to which D2 was already connected. This should have resulted in the same trace appearing on both channels but the traces were very different. Another unused channel (D4) was connected to the same clock signal for comparison. This resulted in two identical traces on D2 and D4, but a completely different trace on D1. Clearly there is a problem with LA channel D1!

So channel D4 was now connected to MOSI and the decode reconfigured to use that channel instead of D1. Now finally the decoding showed the expected data being sent to the MCP23S17, but unfortunately still no response from the GPIO pins/LEDs.

So there are a number of issues:

a) The Nano clearly has some kind of fault resulting in spikes on the GPIO pins
b) The LG8F328P may also be faulty, but might be worth re-testing now that the problem with channel D1 has been identified.
c) UNO appears to be working OK.
d) channel D1 is not working properly. Is this down to the probe or the MSO5000? How do I test this?
e) MCP23S17 still does not respond to commands. Faulty or fake? Or problem with sketch?

I have attached the sketch (with comments removed) in case anyone spots anything missing or wrong, but this sketch did work before. I should probably point out that A0, A1 and A2 are connected to GND (LOW) so configured for address 0. There is no other SPI device on the bus. Although the Arduino is being configured with an interrupt being attached to pin 2, it is currently disconnected and not being used. INTA on the MCP23S17 is not connected.

I did noit expect to spend so much time on this today, but this is what happened. Obviously, I will need to test all of the LA channels somehow.

Image 1: Nano with spikes on CS
Image 2: LG8F328P with odd MOSI signal
Image 3: UNO with data incorrectly decoded
Image 4: UNO with wrong signal on MOSI (MOSI, CLK and CLK2 all attached to and should be showing clock signal)
Image 5: UNO finally with correct decoding

[dobsonr741]

Can you post a picture of the test setup, along with the schematics? Neither the MCP or the Nano should be dodgy. The variable parts are the wiring, the ground references, the power, and properly setting up the MCU’s GPIO in/output.

I had a similar moment with an MCP23017 when it started overheat only after I turned the rotary encoder it was attached to it. It turned out the interrupt out pin of the MCP was connected to a GPIO on the MCU I initialized as an output. Usually, it comes down to little silly things like this.

[WaveyDipole]

I agree, all things being equal, neither the Nano nor the MCP should be dodgy. I have attached a diagram and photo of the breadboard. The diagram is pretty simple and shows a Nano as per original layout. The photo shows a Uno substituted in the last test. The pinout on the MCU is exactly the same. The wires on the middle left (lower left of the MCP23S17) are the probe connections.

PS, I tested another SPI connected peripheral on the UNO wand it worked just fine, so SPI on the UNO seems to be working properly.

[WaveyDipole]

Item (d), the LA probe channel, appears to be solved. There was a faulty resistor on the input to the channel. It has been replaced and the channel now seems to be displaying the signal correctly. Decoding also now works correctly with MOSI on D1.

The MCP23S17 still does not respond to the data being sent to it via SPI. Since the UNO works fine over SPI with the SD Card reader, it does seem that the problem is with the MCP23S17 end.

UPDATE: item (b) is also now resolved. Having fixed the probe, the correct MOSI signal can now be read from SPI bus on the LG8F328 board. Still no joy with the MCP23S17 though!

[dobsonr741]

The first thing I used to test with failing SPI if I swapped MISO/MOSI. Very easy to see on oscilloscope, if master and slave try to drive the same line. At the same time, the two inputs stay silent and floating. Assuming CS and CLK are in order.

[WaveyDipole]

Hmm. Tried that. Reversed the MISO/MOSI connections at the Arduino end. The attached is the result. The LA shows the signal sent on MOSI to MISO on the MCP is echoed back from MOSI to the MISO and the Arduino. However the analog channel connected to MOSI shows that the returning signal is distorted and a sort of mix of the clock and MOSI signals at lower amplitudes. It didn't however result in either line being silent.

CS and CLK do both appear to be in order.

BTW, does anyone know whether it is possible to save the LA and decoder config on the MSO5000 so I don't have to set it up every time? I couldn't see anything in the manual. My only other thought was to write a Python script to send SCPI commands over TCP/IP.

[Ground_Loop]

Have you tried slowing down the SPI clock?  It looks like you're running close to the 10 MHz max speed which is really fast for a solderless breadboard.  Have you zoomed into the spikes to see if they are just spikes.  Can you separate the power supplies?

[dobsonr741]

Are you sure the MISO and CLK not shorted or pulled by a resistor to CLK? The CS glitch during the digital trace in the middle of first byte does not look good either.

I suggest getting the analog traces clean first. Don’t even look at the digital ones. Proper swing from GND to the rail, good enough edges, not much overshoot needs to pass first on all 4 signals. Properly framed CS around the transmission as well.

[WaveyDipole]

Yes, I have slowed down the clock. The board itrself runs at 16MHz but I have the following in the sketch:

Code: [Select]

SPI.setClockDivider(SPI_CLOCK_DIV8);

That should work on Nano and Uno. Whether it does on a Logc Green board is another matter, but it should slow down the clock to 2MHz. However, on seeing your comment, I reduced the speed further to 1MHz with:

Code: [Select]

SPI.setClockDivider(SPI_CLOCK_DIV16);

The chip then sprung to life! The really weird thing is that it has been working ever since, even though I have set the clock back to DIV8. It even now works when tested on DIV4 and DIV2....Uh?

Are you sure the MISO and CLK not shorted or pulled by a resistor to CLK? The CS glitch during the digital trace in the middle of first byte does not look good either.

Even though I have the experiment set up on what should be a reasonable quality breadboard from RS, its possible, I suppose, that this could be a breadboard or jumper wire problem. I did re-check and wiggle wires at various stages as was suggested earlier, to make sure they were seated properly, but didn't find anything obviously amiss. AFAIKT, nothing was loose or shorted, but, that does not necessarily mean that something isn't happening below the surface of the breadboard where it would not be visible.