SPI help

[Northy]

I've got a board with a single SPI port that goes to an ethernet phy, then to a connector, through a 50mm FFC cable to an LCD board. It's running at 5MHz and I'm getting some strange behaviour.
There are no series resistors on any of the traces.
Trace length on the main PCB is ~180mm. Then 50mm FFC. Then trace length ~137mm on the LCD PCB.

If I replace the 50mm FFC cable with a 120mm FFC cable, the screen becomes more reliable (as in there's less corruption).
If I put my 10x scope probe on the SCK line anywhere on the main PCB or LCD PCB then the screen seems to work 100% reliably. However, adding a 10pF cap stops the screen working completely.

I've totally underestimated getting this interface to work reliably, so I'm looking at what I should do to improve it. I'm thinking:

Series resistors at all outputs - Master outputs, and both slave outputs. Start with 47R but test various values eventually.
Make the traces 50R controlled impedance.

But, what should I do with the short FFC cable? I've been doing some reading and I've seen various ideas/suggestions.
R/C > cable > C/R
C/R > cable > R/C
R > cable > R

Any ideas how I can actually figure out what is causing the port to be unreliable?

Thanks,

G

[Siwastaja]

Check the SPI modes. There are four options, brute force through them to find if one works better. SPI clock polarity should be chosen such that data is registered during half-way of the stable data bit. If the clock polarity is wrong, then the data is registered during the transition and setup/hold times become really important. And when the clock polarity is wrong, it is quite random which of the adjacent bit gets clocked in, so once you change to right polarity you might or might not need to swap the other option ("phase") as well. Therefore going through the 4 combinations is needed.

Then, good grounding. On FFC, signal-groung-signal-ground-signal arrangement is highly recommended. If you lack pins, then substitute ground with power, i.e. signal-ground-signal-power-signal, but have physically small bypass caps between power and ground at both ends of cable. PCB should be with continuous ground plane and ground via right at every ground connection.

Series termination of SPI signals is a good idea to stop ringing, 47R is fine.

But the fact that adding just 10pF of capacitance makes me think it's a clock polarity problem after all.

[DavidAlfa]

Are the signals shielded between them? Like MOSI, GND, MISO, GND, SCK, GND.
Otherwise routing them in parallel through long traces will cause lots of crosstalk.

[Siwastaja]

Picture of layout (from PCB EDA software, with all layers and fills shown) is always a good idea in threads like this. A photo of complete setup as well, effort to post these is small and they often tell more than 1000 words.

[Northy]

The FCC pinout is:

GPIO
GPIO
CS
GND
GND
MOSI
MISO
SCK
GND
GPIO
GPIO
GPIO
GND
GND
POWER
POWER
GND
GND
POWER
POWER

Possibly not ideal, but maybe not the worst?

Why would a longer FCC cable give more reliable data transfer than a shorter one?

G

[Doctorandus_P]

Get an oscilloscope and measure.

[Siwastaja]

The FCC pinout is:

GPIO
GPIO
CS
GND
GND
MOSI
MISO
SCK
GND
GPIO
GPIO
GPIO
GND
GND
POWER
POWER
GND
GND
POWER
POWER

Possibly not ideal, but maybe not the worst?

Well it's far from optimal and I would fix it to the next revision by redistributing all those paralleled GNDs between the signals, but I still don't think crosstalk between MOSI, MISO, SCK caused by this layout would be the issue. And they have GND return path pretty close if not right next. Possible cause of issues but not that likely. Your FFC cable is quite short and as you say it works better with a longer cable.

But post PCB layout as well. And check the SPI modes.

[Northy]

I have been using a scope, but putting the scope on the CLK line makes the unreliability go away 
Is there a way I can try and 'measure' what's going on without physically connecting the scope? I tried putting the probe near the CLK line set to AC and full sensitivity, but couldn't see anything.

I'm not sure I can post the layout, sorry. I agree it would be helpful, but it's not up to me. I hope you understand.

I have checked that the processor is set to mode 0 and the two chips require mode 0, so it should be setup correctly? 

G

[peter-h]

Firstly, use the scope to check the data is set up correctly relative to the clock edge specified in the data sheet.

Then, all that really matters is the quality of the clock (the other signals can have poor edges etc) and you can tweak that with a series R to get it clean for that particular cable run.

If you have the above wrong, it will never be reliable.

I've played a lot with SPI and all kinds of different chips, all running off the same SPI controller (32F417) and one finds surprising things. One of them is that chips whose data sheets require the clock parked high actually do not care if the clock is parked low. In terms of digital design this is fairly obvious which makes one wonder why the hell does anybody want the clock parked high.

The following code shows some of the fun, for the devices listed

Code: [Select]

/**
   * @brief  Set the mode of the SPI for the required peripheral
   * 		This must be called before using each peripheral in turn
   * @param  mode: SPI_MODE_STLED316, SPI_MODE_ADS1118 or SPI_MODE_MCP3550 or SPI_MODE_HI3593 etc
   *
   * There were some weird problems related to different SPI devices not playing together, and the SPI clock
   * mode of one affecting another. One was in the form of STLED316 display artefacts with the HI3593.
   * One solution was to run all slaves with the clock parked LOW, which was incorrect per data sheet for some.
   * Most devices should not actually care anyway i.e. they should sample data only on the clock *edge*. But
   * What obviously does matter is which clock edge is used to sample the data and that must be set right.
   * The ADS1118 is the only one on which the data is sampled on the *falling* clock edge.
   * This is handy: https://visualgdb.com/tutorials/arm/stm32/spi/
   * and https://peter-ftp.co.uk/screenshots/202102233910802613.jpg
   *
   * One explanation for this which somebody found: Depending on SPI phase/polarity, the initial clock/data levels
   * after setup might be wrong. Since that bus has a whole bunch of SPI-slaves, I have to control the NCS-pin by
   * firmware anyways. So simple solution: after changing config, keep all NCS idle/high and send a single packet.
   * After that the idle polarity of the clock/data lines correspond to the configuration.
   * This was attempted and made some difference but also broke some other stuff.
   *
   * STLED316 clock modes marked **** work but brightness control fails and display occassionally flickers, which
   * suggests that the data coming out of the SPI is being read incorrectly. However this could be due to other
   * SPI device activity before or after the STLED316.
   *
   * SPI3 runs off APB1 which is 42MHz.
   *
   * This function works regardless of whether the SPI transfer is done with HAL_SPI_TransmitReceive() or with
   * SPI3_DMA_TransmitReceive().
   *
   */
void spi3_set_mode(uint8_t mode)
{
	// SPI configuration
	switch (mode) {

	case SPI_MODE_STLED316:										// options *** below work but should not
		m_spi.Init.Direction = SPI_DIRECTION_2LINES;
		m_spi.Init.DataSize = SPI_DATASIZE_8BIT;
//		m_spi.Init.CLKPolarity = SPI_POLARITY_HIGH;					// ****
		m_spi.Init.CLKPolarity = SPI_POLARITY_LOW;					// ***
//		m_spi.Init.CLKPhase = SPI_PHASE_2EDGE;						// ****
		m_spi.Init.CLKPhase = SPI_PHASE_1EDGE;						// ***
		m_spi.Init.NSS = SPI_NSS_SOFT;
		m_spi.Init.BaudRatePrescaler = SPI_BAUDRATEPRESCALER_64; 	// 650kHz (max 1MHz)
		m_spi.Init.FirstBit = SPI_FIRSTBIT_LSB;						// LSB first - unusual
		m_spi.Init.CRCPolynomial = 7;
		m_spi.Init.Mode = SPI_MODE_MASTER;
		m_spi.Instance = STLED316S_SPI;
		break;

	case SPI_MODE_ADS1118:
		m_spi.Init.Direction = SPI_DIRECTION_2LINES;
		m_spi.Init.DataSize = SPI_DATASIZE_16BIT;
		m_spi.Init.CLKPolarity = SPI_POLARITY_LOW;					// correct per data sheet
		m_spi.Init.CLKPhase = SPI_PHASE_2EDGE;						// likewise - sample on -ve ck edge
		m_spi.Init.NSS = SPI_NSS_SOFT;
		m_spi.Init.BaudRatePrescaler = SPI_BAUDRATEPRESCALER_16;  	// 2.6MHz (max 4MHz for ADS1118)
		m_spi.Init.FirstBit = SPI_FIRSTBIT_MSB;
		m_spi.Init.CRCPolynomial = 7;
		m_spi.Init.Mode = SPI_MODE_MASTER;
		m_spi.Instance = ADS1118_SPI;
		break;

	case SPI_MODE_MCP3550:
		m_spi.Init.Direction = SPI_DIRECTION_2LINES_RXONLY;
		m_spi.Init.DataSize = SPI_DATASIZE_8BIT;
//		m_spi.Init.CLKPolarity = SPI_POLARITY_HIGH;
		m_spi.Init.CLKPolarity = SPI_POLARITY_LOW;					// SPI mode 0,0, uses 4 bytes
//		m_spi.Init.CLKPhase = SPI_PHASE_2EDGE;
		m_spi.Init.CLKPhase = SPI_PHASE_1EDGE;
		m_spi.Init.NSS = SPI_NSS_SOFT;
		m_spi.Init.BaudRatePrescaler = SPI_BAUDRATEPRESCALER_16;  	// 2.6MHz (max 5MHz for MCP3550)
		m_spi.Init.FirstBit = SPI_FIRSTBIT_MSB;
		m_spi.Init.CRCPolynomial = 7;
		m_spi.Init.Mode = SPI_MODE_MASTER;
		m_spi.Instance = MCP3550_SPI;
		break;

	case SPI_MODE_HI3593:
		m_spi.Init.Direction = SPI_DIRECTION_2LINES;
		m_spi.Init.DataSize = SPI_DATASIZE_8BIT;
		m_spi.Init.CLKPolarity = SPI_POLARITY_LOW;					// This is actually correct per data sheet
		m_spi.Init.CLKPhase = SPI_PHASE_1EDGE;						// and so is this
		m_spi.Init.NSS = SPI_NSS_SOFT;
		m_spi.Init.BaudRatePrescaler = SPI_BAUDRATEPRESCALER_8;  	// 5.2MHz (max 10MHz for HI3593)
//		m_spi.Init.BaudRatePrescaler = SPI_BAUDRATEPRESCALER_4;  	// 10.5MHz (max 10MHz for HI3593)
		m_spi.Init.FirstBit = SPI_FIRSTBIT_MSB;
		m_spi.Init.CRCPolynomial = 7;
		m_spi.Init.Mode = SPI_MODE_MASTER;
		m_spi.Instance = HI3593_SPI;
		break;

	case SPI_MODE_NEO_M9N:
		m_spi.Init.Direction = SPI_DIRECTION_2LINES;
		m_spi.Init.DataSize = SPI_DATASIZE_8BIT;
		m_spi.Init.CLKPolarity = SPI_POLARITY_LOW;
		m_spi.Init.CLKPhase = SPI_PHASE_1EDGE;
		m_spi.Init.NSS = SPI_NSS_SOFT;
		m_spi.Init.BaudRatePrescaler = SPI_BAUDRATEPRESCALER_64; 	// 64: 650kHz (max 1MHz for 125kbyte/sec max data rate)
		m_spi.Init.FirstBit = SPI_FIRSTBIT_MSB;
		m_spi.Init.CRCPolynomial = 7;
		m_spi.Init.Mode = SPI_MODE_MASTER;
		m_spi.Instance = NEO_M9N_SPI;
		break;

	case SPI_MODE_LY68L6400:
		m_spi.Init.Direction = SPI_DIRECTION_2LINES;
		m_spi.Init.DataSize = SPI_DATASIZE_8BIT;
		m_spi.Init.CLKPolarity = SPI_POLARITY_LOW;
		m_spi.Init.CLKPhase = SPI_PHASE_1EDGE;
		m_spi.Init.NSS = SPI_NSS_SOFT;
		m_spi.Init.BaudRatePrescaler = SPI_BAUDRATEPRESCALER_2; 	// 2: 21MHz - max possible on this box
		m_spi.Init.FirstBit = SPI_FIRSTBIT_MSB;
		m_spi.Init.CRCPolynomial = 7;
		m_spi.Init.Mode = SPI_MODE_MASTER;
		m_spi.Instance = LY68L6400_SPI;
		break;

	default:
		break;

	}

	HAL_SPI_Init(&m_spi);

}
/code]

My next project is, wait for it, driving LCDs

[Postal2]

.... putting the scope on the CLK line makes the unreliability go away ....

Break the CLK line and insert a 0402 SMD inductor into the break, try ~15nH to start.

[peter-h]

That will resonate nicely with the wire ...

A series R is the absolutely standard way to suppress ringing etc.

[Northy]

How am I supposed to see what the waveform is like when the scope takes it from non working to working?
Or is it impossible?

If I change the design do I just add series resistors at all the outputs and not do anything either side of the FCC connector? Or do I add something either side of the cable?

Thanks,

G

[peter-h]

Your SPI is a Master, AFAIK. So it is transmitting stuff all the time.

So you can check the data versus clock timing. It will be very obvious.

Most likely you have the wrong phase set up and are changing the data at the clock edge.

[Siwastaja]

How am I supposed to see what the waveform is like when the scope takes it from non working to working?

Well probably the waveform changes only very slightly when the scope tip is introduced into circuit. So you should be able to see things like if clock polarity is correct, by eye. Or if there is something else going on.

[Northy]

Thanks, yes, I'll look at polarity etc too, but I'm more looking for ringing at the minute. Is that impossible really?

G

[pqass]

How about adding a 1M or 100K resistor (to GND) to load-down the clock line.
It won't help with seeing but might solve your problem.

[Postal2]

... Is that impossible really?

There are geniuses gathered here, and you are asking about such a trifle as connecting an oscilloscope probe through a resistor.

[BennoG]

Thanks, yes, I'll look at polarity etc too

I am almost 99% sure the clock polarity is inverted.
Reasoning:  If you put the scope on the clk signal there is a small capacitance added tot the clk so the rising edges are a little behind the data edges in this situation, but just enough to make the data stable.

Benno

[Postal2]

.... If you put the scope on the clk signal there is a small capacitance added tot the clk ....

You are misleading people. Connecting the probe introduces a complex circuit, the main component of which is the ground connection loop from the probe.

[Northy]

I am almost 99% sure the clock polarity is inverted.
Reasoning:  If you put the scope on the clk signal there is a small capacitance added tot the clk so the rising edges are a little behind the data edges in this situation, but just enough to make the data stable.

Benno

Thanks, I'll have a look tomorrow.

G

[Northy]

There are geniuses gathered here, and you are asking about such a trifle as connecting an oscilloscope probe through a resistor.

I'm well aware thank you of the knowledge available here, that't why I'm here. I read a lot and sometimes ask questions to improve my knowledge hoping I can help someone one day too.

We're these people born geniuses or did they have to learn too?

Thaks,

G

[Siwastaja]

I am almost 99% sure the clock polarity is inverted.
Reasoning:  If you put the scope on the clk signal there is a small capacitance added tot the clk so the rising edges are a little behind the data edges in this situation, but just enough to make the data stable.

Exactly this is what I have been saying. Clock polarity setting is 90% likely wrong and clock phase setting is then 50% likely wrong. Just change the clock polarity configuration bit, and if it doesn't help, then also change the clock phase bit.

With wrong clock polarity, clock edge and data change happen nearly simultaneously. This is how synchronous logic inside ICs BTW is usually designed but it needs correct handling of setup and hold times. On SPI the wrong clock polarity configuration works by luck. Simply put, you have like 33%-33%-33% chances that it reads one bit too late/early - it reads during transition (metastability, any random result) - it reads the correct bit. And it can be the same way for all the time, or vary between those three options for each bit.

Very tiny amounts of capacitance "fixing" or "breaking" it is a telltale sign. It ever so slightly changes the timing, changing between those three mentioned behaviors.

And of course, ignore Postal2 (I think it's obvious to most at this point?)

[SiliconWizard]

I would second the wrong SPI mode as well. At 5MHz over less than 20cm, the probability that this is a signal integrity issue, unless you have absolutely butchered the layout, is rather low.

Just as an example, for quickly testing a new TFT display on an existing board (via SPI), I connected it with a spaghetti of wires about 10cm long, SPI @50MHz (yes, 50), and it works perfectly fine. (It wouldn't be pretty in terms of EMI, but just mentioning the reliability factor.)

[Postal2]

...And of course, ignore Postal2 (I think it's obvious to most at this point?)

Did I stop you from giving a newbie the wrong directions?

You can connect the oscilloscope via a 100..300 ohm resistor (sometimes I connected even through 10k), but it is better to solder the chip resistors end-on at different points - where you are interested in looking, and touch the free ends of the resistors with a probe.

[Someone]

...And of course, ignore Postal2 (I think it's obvious to most at this point?)

Did I stop you from giving a newbie the wrong directions?

You can connect the oscilloscope via a 100..300 ohm resistor (sometimes I connected even through 10k), but it is better to solder the chip resistors end-on at different points - where you are interested in looking, and touch the free ends of the resistors with a probe.

You are talking about adding some extra resistance in the same order of the load that the tip capacitance presents at the x0MHz of SPI, which sounds like a marginal solution on a marginal problem.

If someone wanted to see a more accurate view of the signalling they would use an active probe which has lower loading.

or as multiple people have said, SPI is generally fairly robust, fiddling with a marginal design without checking for the obvious problem of where the data is being sampled is likely a waste of time.