Problem with SPI communication when Silabs Si86xx digital isolator is used - Page 1
Forum section: electronics / projects

author: prasimix
author_rank: Unknown
timestamp: June 07, 2015, 04:07:37 pm
content: I'm trying to establish communication between Atmel Atmega32U4 (used in Arduino Leonardo) on MCU PCB and TIDAC8552on PSU PCB via isolated SPI link. For isolation I'm using Silicon LabsSi86xx digital isolatorwhich can go up to 150MHz. While everything works as expected WITHOUT isolator I got a quite strange results when isolator is put in between MCU and DAC device. For testing is used very simple Arduino sketch which sending in infinite loop two values to the DAC each last 20ms:Code:#include "SPI.h"int DAC2_SELECT=5; // uncomment this line if Arduino board is used instead of PSU MCU boardint IO_EXPANDER2=6; // uncomment this line if Arduino board is used instead of PSU MCU boardint ADC2_SELECT=13; // uncomment this line if Arduino board is used instead of PSU MCU boardint var=0;void setup(){// Deselect devices that share same SPI bus on the PSU post-regulator boardpinMode(ADC2_SELECT, OUTPUT);digitalWrite(ADC2_SELECT, HIGH); // Deselect ADS1120pinMode(IO_EXPANDER2, OUTPUT);digitalWrite(IO_EXPANDER2, HIGH); // Deselect MCP23S08// Initialize DAC8552pinMode(DAC2_SELECT, OUTPUT);SPI.begin(); // wake up the SPI bus.SPI.setBitOrder(MSBFIRST);SPI.setDataMode(0); //CPOL=0, CPHA=0// SPI.setClockDivider(SPI_CLOCK_DIV16); // Slow down SPI clock speed to 1MHz for testing purposedigitalWrite(DAC2_SELECT, LOW);SPI.transfer(B00100100); // Write to Data Buffer BSPI.transfer(0x99); // send first byteSPI.transfer(0x99); // send second bytedigitalWrite(DAC2_SELECT, HIGH); // Deselect DAC}void loop(){digitalWrite(DAC2_SELECT, LOW);SPI.transfer(B00010000); // Write to Data Buffer ASPI.transfer(0x20); // send first byteSPI.transfer(0x00); // send second bytedigitalWrite(DAC2_SELECT, HIGH); // Deselect DACdelay(20);digitalWrite(DAC2_SELECT, LOW);SPI.transfer(B00010000); // Write to Data Buffer A and activate channel ASPI.transfer(0x80); // send first byteSPI.transfer(0x00); // send second bytedigitalWrite(DAC2_SELECT, HIGH); // Deselect DACdelay(20);}Schematic derived from muchcomplex oneis shown below (use right mouse click option to enlarge):Results WITHOUT isolator:Connection between MCU and PSU PCB without on-board isolator:Here is what I got when isolator is added between MCU and DAC:I tested it using isolator on MCU PCB ...... but also to be sure using isolator connected on breadboard to be sure that something is not connected wrongly on the MCU PCB:Please note that MCU PCB has two 10-pin IDC connector: black one is a non-isolated SPI, and grey is isolated SPI where "remote" part of the isolator device is supplied from external source (PSU PCB). Intentionally I used the same ribbon cable, and cable length doesn't seems that is an issue since everything works correctly without isolator. To be completely on safe side I tried to slow down SPI clock as much as possible even down to 125kHz (divide by 128 from default 4MHz or divide by 4). Nothing helps in case of isolator - I'm continuously receiving random values on the output instead of fixed two. I also tested the following "hybrid" connection where MOSI and chip select (ADC2_SELECT) goes thru isolator and SCLK is connected directly (of course with MCU ground connected to "remote" PSU ground). To my surprise that combination works but I cannot explain why. Also checking signal from the both side of isolator don't shows anything suspicious: signal duration on the "remote" side is slightly shorter since isolator has built-in Schmitt trigger logic.I ran out of ideas what to test next so if someone has any suggestion please let me know.

author: SArepairman
author_rank: Frequent Contributor
timestamp: June 07, 2015, 06:54:25 pm
content: dc test the chips gatesalso rise time might be too high.. your digital isolator is off on long wires. is there decoupling? did you check continuity on all those connections?

author: prasimix
author_rank: Unknown
timestamp: June 08, 2015, 10:20:44 am
content: Yes, wiring is long but again everything works fine when isolator is bypassed. Decoupling capacitors are present in both case: testing with MCU PCB and breadboard. You can also see that setting new DAC value is in sync but it look like transfered data is not correct. Please find two more screenshots where I put side by side directly connected SPI or thru isolator. In first case I'm changing values from 0x20 to 0x80 and in another one from 0x70 to 0x80.

author: moffy
author_rank: Super Contributor
timestamp: June 09, 2015, 01:43:27 am
content: It looks like a ground is not correct, or perhaps a bad channel. Have you tried different channels? I would measure the voltage on both sides of the chip on the chip pins, also check continuity from the chip pins.

author: mfratus2001
author_rank: Contributor
timestamp: June 09, 2015, 07:40:03 am
content: You say the cable lengths are fine since it works great without the isolator. This may be bad thinking. The isolator has high-speed chips, so therefore I think cable lengths are even more critical.

author: tszaboo
author_rank: Super Contributor
timestamp: June 09, 2015, 07:52:52 am
content: Quote from: mfratus2001 on June 09, 2015, 07:40:03 amThis. The isolators are fast, and with the cables, you have slow rise times. There is no hysteresis, no smitt trigger, so with a slow edge you will see a 0101 instead of a 01 on your output on a rising edge. Try using an isolator which is slower, or buffer the signal before it with a carefully selected logic gate. Or shorten the cable.

author: prasimix
author_rank: Unknown
timestamp: June 09, 2015, 08:11:58 am
content: Thanks to everyone for comments and suggestion. I'll try to play more with cable. In the meantime I did more measurement which again shows that something is critical in SCLK timing. Further comments and suggestion is welcomed.Everything is performed on the breadboard, same wires and flat cable is used as in initially presented results.Grounds on both side of the isolator are tied together, "remote" (or Side B) is supplied from PSU PCB, host (or Side A) from Arduino Leonardo. First I tired using mentioned wiring direct SPI connection and it works as expected.In first step SCLK and MOSI stays directly connected CS (ADC2_SELECT) goes over isolator. All unused isolator pins are grounded. DAC works as you can see on the following two screenshots (S1 is host side, S2 is remote side on the isolator device, DAC signal is analog output on DAC8552 pin 4 (VOUTA):Same thing when MOSI goes thru isolator and SCLK and CS stayed directly connected:And now we comes to problem that persist and I cannot figure out what is going on: when SCLK goes thru isolator communication stops regardless of the fact that signal looks fine on both side of the isolator. Please note that on DAC trace there is no more changes. That is one of two possible scenario. Another one is already described (random values are presented on DAC output).I'm adding one additional scenario when SCLK is connected to host side via capacitor. In that case DAC starts to behave regularly even when grounds are not tied together. Pleas find below schematic and result:

author: Kalvin
author_rank: Super Contributor
timestamp: June 09, 2015, 09:06:24 am
content: Wrong SCLK and MOSI phase? Does the MOSI change its state on the rising or falling edge of SCLK? And does the DAC expect the data to be stable on the rising or falling edge of the SCLK?

author: prasimix
author_rank: Unknown
timestamp: June 09, 2015, 09:28:53 am
content: Giant T H A N K S Kalvin!The whole misery is generated by wrongly declared SPI clock mode. I even put in sketch as an reminder the following comment: CPOL=0, CPHA=0 what is SPI_MODE 1 and for that inArduino IDEexists constant SPI_MODE1 what isnot equalto 0.So, for the correct working the following command has to be used:Code:SPI.setDataMode(SPI_MODE1);Case closed!EDIT: My understanding of CPHA was wrong. CPHA 0 is not falling edge what DAC8552 require but rising edge. The right CPHA has to be 1 and not 0.

author: Kalvin
author_rank: Super Contributor
timestamp: June 09, 2015, 10:59:15 am
content: Glad to hear that the problem got solved.