SPI raise/fall time

[bpacan]

Posted on February 10, 2014 at 10:39

Hi

I'm using STM32F373x SPI in slave mode. I get errors in about 0.1% bits transmitted, occurs in 50% of units from first production series of custom board. SPI lines have RC filter installed to improve EMC immunity. Rise/fall times are about 1us with filters and 10ns without them. I get no errors without filters. My question is what parameter do I exceeded?

Table 58 defines max. rise/fall 8ns (I guess only for master, cause load is also described). I think I'm not getting out of 30-70% duty cycle. Speed is 190kHz, reducing to 80kHz didn't changed anything.

#eye-pattern #stm32-spi

[Tesla DeLorean]

Posted on February 10, 2014 at 18:13

Guess you'd want to review the phase relationship between the CLK and DATA pins

[carl2399]

Posted on February 10, 2014 at 22:33

It may be worth looking at the slave end - as opposed to the master. Is there a limitation on maximum rise time for the incoming clock? Also, where is the filter located? If it's near the source, in which case there could be a longer section of relatively higher impedance trace that may be more susceptible to noise. It could be that these factors are combining to give you a double clock at the slave. A lot of SPI devices will run at tens of MHz. 

As you clock is so slow, I would try reducing the filter on the clock line (keep the resistor, remove the capcitor). The filtering on the data line should be fine as is - with 1us filter and 10us data rate I would be surprised if it's a problem.

[bpacan]

Posted on February 11, 2014 at 11:35

I measured with oscilloscope and serial analyzer (Saleae clone) and found no errors in communication. Each SPI line has the same RC and ~length.

RCs are located at slave side. They are 470R 1nF now. I can reduce cap. x times, but I need to increase R x times, leaving RC constant - not to worsen EMI.

There is no limitation of rise/fall times - it's only for passing required EMI level - SPI cross the boards with 1m cable.

BTW. It's 1us rise + 1.5us stable = 2.5us (low) + 2.5us (high) = 5us period -> 200kHz clock rate.

[bpacan]

Posted on February 12, 2014 at 11:26

One thing I noticed - replacing 470R with 240R (rise time / 2) gives similar errors, while other units works ok with 470R. Any idea?

[bpacan]

Posted on February 12, 2014 at 11:26

One thing I noticed - replacing 470R with 240R (rise time / 2) gives similar errors, while other units works ok with 470R. Any idea?

[bpacan]

Posted on February 12, 2014 at 11:27

One thing I noticed - replacing 470R with 240R (rise time / 2) gives similar errors, while other units works ok with 470R. Any idea?

[Tesla DeLorean]

Posted on February 12, 2014 at 21:12

So here's a thought

Put both the clock and data at the destination (failing slave?) on a scope, set the scope to trigger of the rising edge of the clock. Set the scope in persistence mode, and then send a constant stream of random bit patterns (white noise).

Then observe if you have any indeterminate crap in the center of the data window as the clock transitions it's threshold?

[waclawek.jan]

Posted on February 13, 2014 at 09:11

You're not going to like what I'm going to say: slew-rate limiting clock in SPI is a NO.

The reason is, that now you have the clock line susceptible to any noise/pulse of amplitude given by the hysteresis of clock input pin (typ.100mV for the 5V-tolerant pins, according to the datasheet) and duration given by the time the clock signal transitions the input decision level area (given by your slew-limiting RC). Thus, any small glitch (and it does not necessary mean a glitch in the clock line itself, it may be on the ground, even the internal ground of the chip, too) causes the slave to ''see'' multiple clocks during one rising edge generated by master. Plus you have decreased impedance of the clock line, making it further susceptible to all sources of EMI.

SPI and all other edge-clocked transfer schemes rely on the integrity of the edge, and are generally not suitable for longer distances, higher line loads, noisy environment, and are strictly not to be used beyond a single board. Note, how in I2C, where it is anticipated that it might interconnect boards within one enclosure, the standard itself mandates relatively heavy input filtering on the signals.

So, the primary way how to deal with this is to get rid either of the slew-rate limiting, or of the SPI as such. (Remember, I warned you: you are not going to like it). You may want to employ some more robust scheme to recover the clock. Think UART.

But I assume you are at such stage of the project that you can't switch to UART and want to salvage the existing hardware. A couple of things come into mind to make the clock recovery more robust:

- bit-bang the SPI receiver, e.g. by hooking the clock input onto an interrupt, where you can debounce the clock by reading it multiple times until its level gets stable

- timers have digital filters at their inputs, maybe you could find some way how to ''feed through'' the clock from one timer's input to an output and from there (externally) to SPI

- add more hysteresis by feeding the clock through some hysteretic amplifier; maybe some hysteresis could be gained by adding a series resistor, but that depends on the particularities of the input

In any case, I'd recommend you to prove the method's efficiency by deliberately injecting some reasonable amount of noise into the clock line.

JW

[bpacan]

Posted on February 13, 2014 at 14:12

clive1: I checked it but I saw nothing strange. Thanks for the tip, I'll use it in future for sure.

[bpacan]

Posted on February 13, 2014 at 14:24

waclawek.jan:

Many thanks for detailed information.

I knew that SPI is not intended for longer distances and we could live with this cheap and fast medium for our purposes. I never thought about it, I guess SPI hardware has some more hysteresis. I'll keep it in mind for future projects.

Today I can't recreate this errors (using exactly the same hardware and power supplies as for last week). I'll write when we decide which solution is sufficient for our needs.