SPI Communication over Isolator

Andreas Zeiler · ‎2017-12-19

Posted on December 19, 2017 at 11:51

Hi all,

I'm running a SPI Communication between 2 STM32F469IG Controllers. The Controllers have to be isolated which (for now) is done by a MAX14850 Digital Isolator.

I need to run the SPI Communication at Full 45 MHz. But with this a big Problem occurs.

This Isolator has a propagation delay of about 7-8ns. So when my MISO Data gets clocked into Master-CPU it already has a delay of 14-16ns compared to Masters SCK. At 45MHz (22ns Period) this is not working. So the Master is reading in MISO when MISO is still not valid.

So maybe someone had this Problem already and could help me. Or is there a general workaround for this?

Is it possible to configure the Master SPI to clock in the MISO Line one clock later? With this I mean if MOSI is clocked out with falling edge, then MISO should be clocked in with the next falling edge.

If this is not possible (what I think of) are there any cheap Digital Isolators which could handle that Speed regarding the propagation delay?

I attached some measurements. SCK1SCK2_2.png is the Masters Clock before and after the Isolator. The other picture is the MISO Line before and after Isolator.

Legend: yellow CPU1; green CPU2

Thanks.

Kind regards

Andreas

#spi #stm32f4 #isolator

waclawek.jan · ‎2017-12-19

Posted on December 19, 2017 at 12:48

Run the clock back to the sourcing mcu through another isolator - i.e. add isolator in the direction of MISO and route SCK back together with MISO. Use those two signals with a second SPI in slave mode to receive.

JW

Andreas Zeiler · ‎2017-12-19

Posted on December 19, 2017 at 13:40

Hi JW,

thanks for reply. Unfortunately we want to try not to use one more SPI for uC to uC Com. In this case we would rather run communication in simplex mode (just SCK & MOSI on each side (2 Master with Rx IRQs)). But we want to avoid that because we have several Periphery and more smaller uCs with also needs SPI

:(

.

Kind regards

Andreas

Andreas Zeiler · ‎2017-12-19

Posted on December 19, 2017 at 15:00

Hi,

thanks a lot for your fast relpies.

Sadly I (or we) do not have any specification yet. So we're doing some blind predevelopment

:)

. I hope that the smaller CPUs will not need a big, high frequent and fast protocol. So we could use only one SPI for them. In this case my favourit solution would be the simplex mode. We'll see. We already considered several solution but I wanted to know if other developers had the same issues.

So thanks for your help.

Kind regards

Andreas

AvaTar · ‎2017-12-19

Posted on December 19, 2017 at 14:18

If this is not possible (what I think of) are there any cheap Digital Isolators which could handle that Speed regarding the propagation delay?

I fear this might not quite work out, especially the 'cheap'.

I remember similar ideas for a project in my last company, trying even cheaper opto couplers ... only to fall flat into the manure.

You can try reducing the clock frequency, or switch to some non-synchronous transfer method (another bus).

SPI was designed to be a cheap inner-PCB connection, not a safe transfer method.

waclawek.jan · ‎2017-12-19

Posted on December 19, 2017 at 14:26

,

Analog makes dedicated SPI isolators with delayed clock, check out

http://www.analog.com/en/products/interface-isolation/isolation/spisolator/adum3150.html ♯ product-overview

. I have no personal experience with them. There may be other such on the market. I can imagine to build such clock adjustment gadget discretely, but it does not sound to be trivial at above 10MHz.

JW

waclawek.jan · ‎2017-12-19

Posted on December 19, 2017 at 14:28

we have several Periphery and more smaller uCs with also needs SPI

If those smaller uCs don't need continuous/fast SPI, you can share one SPI between them.

You can also consider using USART in synchronous mode, although that has its limitations (LSB only, 8-bit only, limited speed, no continuous clock).

JW

AvaTar · ‎2017-12-19

Posted on December 19, 2017 at 19:00

A simplex SPI (with a request-response type protocol, i.e. async response) would be an alternative.

A data rate of 45MHz is quite high for a normal (on-PCB SPI) connection, are you sure you need that ?