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.

[Postal2]

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, ....

Yes, that's exactly it.

If you have a quartz crystal that has an unreliable start, you will never detect it by directly connecting the probe to its terminal - it will start at the moment you connect it. This is solved by connecting through a resistor (as well as doing it for adjusting the resonance of the coils with a trimmer core).
In the described case, resonance occurs - you need to use a resistor.

[Someone]

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, ....

Yes, that's exactly it.

If you have a quartz crystal that has an unreliable start, you will never detect it by directly connecting the probe to its terminal - it will start at the moment you connect it. This is solved by connecting through a resistor (as well as doing it for adjusting the resonance of the coils with a trimmer core).
In the described case, resonance occurs - you need to use a resistor.

For a crystal in a feedback loop the change in reactance by adding some comparable tip resistance may well produce a significantly different result, but that does not apply to general probing. Any tip resistor would need to be >>> the probe loading to make a substantial difference in the general case. An SPI line driver does not substantially change with reactance (while keeping impedance similar).

Better solution: have a selection of appropriate probes for different situations.

[Northy]

My ethernet device states this in the datasheet:

SCL is expected to stay low when SPI operation is idle. SPI operations start with the falling edge of SCS_N and end with
the rising edge of SCS_N. A single read or write access consists of a 27-bit command/address phase, then a 5-bit turnaround (TA) phase, then an 8-bit data phase. For burst read or write access, SCS_N is held low while SCL continues to
toggle. For every 8 cycles of SCL, the device will increment the address counter, and the corresponding data byte will
be transferred on SDI or SDO in succession.
All commands, addresses and data are transferred most significant bit first. Input data on SDI is latched on the rising
edge of clock SCL. Output data on SDO is clocked on the falling edge of SCL.

Is this mode 0?


My LCD device datasheet states this:

Only SPI mode 0 is supported.


So do I need the clk line transitioning half way through the data bit?

Thanks,

G

[Someone]

So do I need the clk line transitioning half way through the data bit?

Yes, that would be the first thing to check, that the data is stable around the sampling edge.... But...

My ethernet device states this in the datasheet:
.....
Input data on SDI is latched on the rising
edge of clock SCL. Output data on SDO is clocked on the falling edge of SCL.

and

My LCD device datasheet states this:

Only SPI mode 0 is supported.

Is this mode 0?

You tell us:
https://en.wikipedia.org/wiki/Serial_Peripheral_Interface#Mode_numbers
Ideally checking the timing diagrams in the data sheets rather than relying on mode "numbers".

[Siwastaja]

My ethernet device states this in the datasheet:

SCL is expected to stay low when SPI operation is idle. SPI operations start with the falling edge of SCS_N and end with
the rising edge of SCS_N. A single read or write access consists of a 27-bit command/address phase, then a 5-bit turnaround (TA) phase, then an 8-bit data phase. For burst read or write access, SCS_N is held low while SCL continues to
toggle. For every 8 cycles of SCL, the device will increment the address counter, and the corresponding data byte will
be transferred on SDI or SDO in succession.
All commands, addresses and data are transferred most significant bit first. Input data on SDI is latched on the rising
edge of clock SCL. Output data on SDO is clocked on the falling edge of SCL.

Is this mode 0?


My LCD device datasheet states this:

Only SPI mode 0 is supported.


So do I need the clk line transitioning half way through the data bit?

Thanks,

G

Yes, CLK line must transition half way through the data bit. The only question is whether 0->1 or 1->0 is the transition we talk about. Other transition happens simultaneously with data bit changing. That is the wrong transition.

After the polarity (half-cycle timing shift) is correct, then clock phase configuration is a shift of a full clock cycle. it isn't, see edit below

It is normal that slave devices are hard-wired to support only one mode. I would do the same as slave device designer. Change the clock polarity/phase configuration of SPI peripheral on the master side.

No one remembers the mode numbers and I have seen at least once if not twice that a datasheet specification does not match reality (manufacturer copy-pasted a wrong timing diagram etc.), so just go change CPOL (working on assumption that it is definitely wrong) and go through the remaining two modes (different CPHA) to find the one of the two which works.

Edit: Fuck, I got even the CPOL / CPHA names backwards compared to Wikipedia. If I do this mistake, I'm sure many others do it as well. So just test all four combinations until it works.

Edit 2: So from the Wikipedia table, it becomes obvious that swapping either one of the two bits swaps the sampling edge, they do not represent simply half-cycle and full-cycle delays like I initially wrote. So test all four combinations.

[Northy]

The ethernet chip has this timing diagram:

[Northy]

The LCD chip has no proper timing diagram 

[Siwastaja]

Pictures of layout or schematics would also help not only on question about signal integrity but also to understand they system. You have been talking about two SPI devices which sound like both are slaves. What is the master, and how the two slaves connect to the same bus, with two separate nCS signals, yes?

Does the communication to the ethernet chip always work and it's just the display which is failing? They might need different SPI mode, in which case you need to change the SPI peripheral configuration on the fly between accessing the two slaves (maybe disabling and re-enabling the SPI peripheral in-between), but that does not sound like a big problem.

This would be much easier with more information.

[ebastler]

...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?

Your technical advice is hit-or-miss and your attitude is consistently annoying. That's enough for me to enable "ignore user". 

[Postal2]

.... Better solution: have a selection of appropriate probes for different situations.

This is impossible. In some cases, when connecting the probe changes the operation of the device (as in this case), it is enough to connect a 10 cm long wire instead of the probe, holding it with insulated tweezers, including for starting the quartz. Therefore, it is customary to use a resistor in such cases. Of course, the signal obtained in this way is slightly distorted, but the question was precisely about how to view it.

Your technical advice is hit-or-miss and your attitude is consistently annoying. That's enough for me to enable "ignore user".

OK.

[dietert1]

It's impressive how after almost two pages of posts the clock/data timing relationship has not been verified. Unreliable data transmission with SPI is 99 % caused by wrong clock/data timing configuration and the other 1 % is clock out of spec (high). There is no way around checking the clock/data timing relationship. Stop trying to reduce the unreliability but fix it.

Regards, Dieter

Edit: And sorry, there is no SPI device without clock/data timing relationship specification. If you did not find it, you need to continue your search. You cannot and you did not setup the data transfer without that information.

[Siwastaja]

Unreliable data transmission with SPI is 99 % caused by wrong clock/data timing configuration

I only dared to say 90% but you are probably closer to truth.

[peter-h]

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

They were born like that

The rest are just people copying/pasting from ChatGPT

It's impressive how after almost two pages of posts the clock/data timing relationship has not been verified.

Indeed. Checking this takes about 5 mins.

To the OP:



You can see the rising clock edge clocks in each data bit.

You can also see the CLK is parked HIGH (at the start and at the end) but that is not important. No idea why they draw it like that. In SPI it is normally parked LOW.

Some chips differ but they are unusual. This one (ADS1118) clocks the data on the falling edge



It also shows CLK parked LOW at the start, and parked HIGH at the end, just to sort the men from the sheep. All these chips run fine with the clock parked LOW. And if they didn't, there would probably be funny problems with the first packets after power-up.

How do you block somebody? Postal2 is a curious one. He posts after every post of mine, and the info, while in the right ballpark contextually, is nonsense.

[Pbtz]

It may not be the reason for the issues you're having, but it's usually good practice to insert a 22R or 33R series resistor in the output signals and perhaps limit the bandwidth of the net.

[Postal2]

...... is nonsense.

If you give a monkey glasses, it will put them on its butt.

[ebastler]

How do you block somebody?

Via the forum's main menu, go to Profile > Forum Profile;
then select Modify Profile > Buddies/Ignore List > Edit Ignore List.
There you can enter user names you want to "ignore".

You will still see their posts, but the posted text will be hidden. There is a "show me the post anyway" link instead, so you can still view the post if you are interested. I often do take a look, but then my expectation has been set and I have reminded myself that "this is a strange one, don't get upset". Works for me.

Users you are ignoring also can't send you Personal Messages via the forum. I have never encountered a situation where that was an effect I wanted/needed -- users who start to actively harrass others would be banned quickly anyway. But it's a side effect of the "ignore user" function which one apparently can't configure separately.

[Postal2]

.... usually good practice to insert a 22R or 33R series resistor in the output signals ....

It's hard to explain to people how strong resonance can be. And it happens precisely on the signal fronts, and it doesn't matter that the clock frequency is 5 MHz. Northy wanted to see this, and everyone should see this too.

[Someone]

.... Better solution: have a selection of appropriate probes for different situations.

This is impossible. In some cases, when connecting the probe changes the operation of the device (as in this case), it is enough to connect a 10 cm long wire instead of the probe, holding it with insulated tweezers, including for starting the quartz. Therefore, it is customary to use a resistor in such cases. Of course, the signal obtained in this way is slightly distorted, but the question was precisely about how to view it.

What does that 10cm wire achieve that a different probe could not? Electrically.

Probes are available with a wide range of load impedances, and I find it implausible that there are zero products which address your claimed fix of adding some hundreds of ohms in series (given some probes have exactly that by default!).

[Postal2]

What does that 10cm wire achieve that a different probe could not? ...

It is meant that touching critical points with a small piece of wire hanging in the air directly causes undesirable effects. In order for the oscilloscope probe not to cause such effects, the chip resistor must be at its end. I have not seen such probes, but I have seen a resistor soldered by the manufacturer with a tap to the measurement point many times (I hope everyone has seen it). Therefore, if the oscilloscope probe affects the circuit when connected, you can solder the chip resistor to the circuit and touch the probe through it. The choice of resistor value depends on the expected impedance of the circuit.

[dietert1]

In a well designed digital circuit there are no "critical points". 16 cm of wire are equivalent to 1 nsec. So unless the SPI is running at clock above 300 MHz, it won't be affected by a short piece of wire. Well designed digital circuits stay far away from any intricate analog effects. Unreliable operation like the OP reported indicates errors of the digital design.
Many programmable digital chips nowadays support "output pin drive strength" for EMI reasons. No need for external parts!

Regards, Dieter

[peter-h]

I think Postal2 is dropping in ChatGPT answers.

[inse]

I came late to the party and would like to know what kind of probe was used for the measurement.
10:1 >100Mhz with short ground connection?

[Siwastaja]

I think Postal2 is dropping in ChatGPT answers.

No, ChatGPT writing style is totally different and easily distinguishable from the annoying autistic verbosity.

Postal2 is an artistic experiment who is best ignored instead of replied to, but randomly maybe 20% of time happens to drop a sensible/correct comment.

But yeah, there is something similar with Postal2 and ChatGPT: tendency of hallucinating total random shit which makes no sense in any context. But writing style is totally different. Postal2 is a real person with brain wired up differently to the rest of us.

[Postal2]

In a well designed digital circuit there are no "critical points". ...

I just bought an mp3 player board with an unstable quartz crystal that even senses touch on the case.
https://www.eevblog.com/forum/projects/diy-mp3oggflac-player-feasible/msg5681177/#msg5681177
You can have a good design, but the component will let you down.

I came late to the party and would like to know what kind of probe was used for the measurement.
10:1 >100Mhz with short ground connection?

I recently checked the MIPI DSI CLK frequency, which was 200 MHz, with a Micsig oscilloscope and the included ~200 MHz probes. The scope showed about 50 mV amplitude from one of the differential outputs relative to ground. However, I had to turn off all the lights except the incandescent ones to see it.

I think Postal2 is dropping in ChatGPT answers.

I usually hear the word "ChatGPT" from stupid people, I have never tried it, but I actually attended a XILINX seminar about AI and I know how it works.

[dietert1]

In a well designed digital circuit there are no "critical points". ...

I just bought an mp3 player board with an unstable quartz crystal that even senses touch on the case.
https://www.eevblog.com/forum/projects/diy-mp3oggflac-player-feasible/msg5681177/#msg5681177
You can have a good design, but the component will let you down.
...

A crystal oscillator is an analog circuit. SPI data transfer is a digital circuit.

Regards, Dieter

[Postal2]

A crystal oscillator is an analog circuit. SPI data transfer is a digital circuit.

Perhaps I was not clear enough. The "empty wire" example applies to analog circuits and RF. The case described here involves introducing an additional resonant circuit into the main circuit, formed by the connected probe, its capacitance, the inductance of the probe-to-ground loop, and the inductance of the section of the design from the probe connection to the circuit in which the resonance occurs. Therefore, an attempt to simulate a probe connection with a capacitance of 10 pF gave the opposite effect.

It looks like this (picture):

[dietert1]

A SPI transfer that fails or becomes unreliable by adding short wires is typical for a wrong configuration of the clock/data timing relationship. With a wrong configuration setup/hold times are marginal and the circuit shows exactly that strange behavior the OP reported. It will be gone with a valid digital configuration. Trying to make the wrong digital design work better by some analog mods is a waste of effort.

Regards, Dieter

[Postal2]

... With a wrong configuration ...

So, you're implying that while the device's author turned away, someone snuck up and changed the polarity? Please show an example of a standard library that has a non-standard signal phase by default.

The non-standard phase of the spi module may be needed when working with Microchip via ICSP or implementing Microwire via spi. It is unlikely that you can accidentally copy such source code, if you can find it at all.

Although peter-h regularly posts his code for the non-standard ADS1118, scaring people.

[Siwastaja]

A SPI transfer that fails or becomes unreliable by adding short wires is typical for a wrong configuration of the clock/data timing relationship. With a wrong configuration setup/hold times are marginal and the circuit shows exactly that strange behavior the OP reported. It will be gone with a valid digital configuration. Trying to make the wrong digital design work better by some analog mods is a waste of effort.

Regards, Dieter

Yeah. A bit more about this:

Synchronous digital logic (e.g. as used in digital ICs like microprocessors) is based on data and clock changing "simultaneously". But this involves a carefully designed clock tree. It is a clock edge which triggers change of data. Then the data propagates through gates which have some guaranteed minimum delay. By modelling it is then guaranteed that the changed data value gets to its destination significantly after the clock transition - this minimum acceptable time is called hold time.

This arrangement, "output data as soon as acceptable but not any sooner", leaves maximum possible time for data delays before the next clock transition - the margin that needs to be left at the end of the slot is called setup time.

But SPI does not do this kind of delay management and matching. If you try to run SPI like "normal" synchronous logic, hold time violations are very likely. Or even beyond that; sampling the data even before it is outputted, so violating setup time plus being off-by-one bit.

SPI instead is specified to clock the data in on the opposite clock edge it is outputted: expressed in time, exactly half-way the bit time slot. This completely prevents the issue of data being sampled "too early", but of course reduces the time margin to the next transition to half, but that is generally OK for the clock rates used in SPI.

Now if the clock configuration is incorrect, SPI tries to operate like normal synchronous logic inputting the data at the exact same time as its being output. If the system was designed for this, like normal synchronous logic, it would correctly read the previous bit, but being not delay-matched for this purpose it has pretty much equal chances of sampling the previous bit, the current bit, or the invalid transition area between them which could sample in either value or result in metastability (which is an interesting failure condition in itself).

[peter-h]

Although peter-h regularly posts his code for the non-standard ADS1118, scaring people.

Rubbish. A troll...

A bit more about this:

A good explanation of how to do, and not do, FPGA design At some point, probably late 1990s or so, Xilinx reduced their silicon geometry (even for existing part numbers) which made them run a lot faster and this broke more or less all designs except those that used the global clock nets for practically all clocking. Since that was always how FPGA design was supposed to be done, Xilinx didn't care

A lot of SPI slaves have weirdly bodged SPI interfaces. Like this one
https://www.eevblog.com/forum/projects/anyone-using-the-u-blox-neo-m9n-gps/
and others have rediculously low max SPI clock speeds e.g. the STLED316 (max 1MHz).

[dietert1]

..
A lot of SPI slaves have weirdly bodged SPI interfaces. Like this one
https://www.eevblog.com/forum/projects/anyone-using-the-u-blox-neo-m9n-gps/
and others have rediculously low max SPI clock speeds e.g. the STLED316 (max 1MHz).

Chinese TFT driver chips are known for their issues. E.g. the ILI9488 doesn't three-state its SPI data output. One needs to add an external gate to make it SPI bus compatible. Many TFT displays available from China don't have that gate. Instead they provide two separate SPI interfaces for display and touchscreen. And of course their example software won't even try to read from the display driver chip.

Regards, Dieter

[peter-h]

Interesting.

AFAIK the Ramtex library doesn't read the display either. There is no fundamental reason to. But for the touch screen you obviously do need to read it.

[ebastler]

AFAIK the Ramtex library doesn't read the display either. There is no fundamental reason to.

Well, many microcontroller-based systems will not have enough RAM to keep a full frame buffer in the microcontroller. So one may want to read the prior pixel contents from the display (for specific pixels or a small local area) before drawing some moving objects or traces.

[Postal2]

Although peter-h regularly posts his code for the non-standard ADS1118, scaring people.

Rubbish. A troll...

Who?

................
   case KDE_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;
................

[peter-h]

Well, many microcontroller-based systems will not have enough RAM to keep a full frame buffer in the microcontroller. So one may want to read the prior pixel contents from the display (for specific pixels or a small local area) before drawing some moving objects or traces.

See this thread
https://www.eevblog.com/forum/projects/graphics-on-an-embedded-system-tft-display-need-help-with-some-pointers/

Reading back the display is some way down the list of doing it efficiently. One might do it with purely memory-mapped graphics...

Indeed, in embedded graphics you don't normally have a full frame buffer but even if you did, SPI won't usually be fast enough to just modify the buffer and then send the whole buffer up to the LCD. You could probably draw a clock face on a 256x256 LCD, with 10MHz+ SPI, that way, but that's about it. For anything more real, one needs to be be clever and keep tabs on the area which has been affected and send only that. See above link.

case KDE_SPI_MODE_ADS1118:

Yes, but context is everything. I don't think you understand the concept of "context" which is why your posts usually make a bit of sense but are of no use to anybody working on something specific.

[Postal2]

.... your posts usually make a bit of sense ....

Thank you, captain.

[Northy]

Hi all,

Sorry for the silence, I've not been feeling well for a few days.

I looked at the bus with a logic analyser on Friday morning, and it looked right for the ethernet IC (although my clock idles low and the data sheet looks like it idles high).

I can assure you there is nothing else in the LCD datasheet other than what I have posted. The manufacturer has been contacted though. However, the timing looked the same as ethernet IC.
I'll look at the timing again this week, and try and get a specific timing diagram from the LCD IC manufacturer.

If set up/timing does seem to be correct I'm thinking this is some serious ringing on the lines. If so do I just try resistors on the outputs (that I should have added, and usually do  ) or should I add 'something else' either side of the FFC cable too?

Thanks,

G

[peter-h]

You need an oscilloscope, not a logic analyser.

[Northy]

I've looked on a scope too. I was looking at the timing relationship on the logic analyser.

I'd like to see any ringing on the scope, but adding the probe changes things.

Or am I getting the wrong end of the sick again here?

G

[Siwastaja]

Hi all,

Sorry for the silence, I've not been feeling well for a few days.

In the mean time, will you ever disclose what the SPI master is? And the reason why you did not test the different SPI modes, it takes literally a few minutes to try?

[Postal2]

.... If so do I just try resistors on the outputs ....

You need only one resistor or inductor on the CLK line, absolutely nothing else.

I would prefer inductor (I wrote which one in my first message in this thread).

[Siwastaja]

And really, just in case it's not clear already, ignore Postal2. Do not put inductors on any of the SPI lines.

[Postal2]

... ignore Postal2. ....

For those who have read this thread from the beginning, it is clear who should be ignored.

[ebastler]

Well, many microcontroller-based systems will not have enough RAM to keep a full frame buffer in the microcontroller. So one may want to read the prior pixel contents from the display (for specific pixels or a small local area) before drawing some moving objects or traces.

See this thread
https://www.eevblog.com/forum/projects/graphics-on-an-embedded-system-tft-display-need-help-with-some-pointers/

Reading back the display is some way down the list of doing it efficiently.

Thanks for the link -- some good discussion there. But the use case I was thinking of is not really covered, I believe:

Let's say you have a complex background pattern drawn on the screen. Just as an example, a world map which you drew from vector outlines, with overlaid day/night zones (changing slowly depending on the time of day and the season). Now you want to draw a few moving satellites or other objects and need to update them regularly.

How do you restore the background pattern when the object moves away to a different spot? You could recalculate the whole background pattern just to figure out which color goes into those few pixels. But it seems much more efficient to read the original background pattern from the display (and store it in a small buffer in MCU RAM) before drawing the object in its new location, and restore the background from that buffered info when the object moves on.

I am currently working on a related use case: Draw a few fast-changing traces, over a background which comprises a coordinate system with variable axis labeling, some UI (menu) elements which may change, plus some measurement results determined from the time-averaged traces. Same thing -- the background info changes slowly and is not trivial to recalculate on the fly; the traces should overlay the background; but of course the background pattern needs to be restored when the trace moves away.

So I think there are some meaningful uses for reading data back from a display. The chip manufacturers must have had some reason to make data transfer bi-directional...

[peter-h]

The data for the world map must have come from somewhere. Probably stored as a block of data in FLASH. So, since you know the initial position of the moving object, fetch that little rectangle from the FLASH and send it out over SPI (which deletes the said object) and then draw the object in its new position.

[dietert1]

Maybe the OP could mention parts, clock rate and other setup. Show your measurements! Until now the only thing we know is the clock polarity may be opposite to what is in the specs - which can already cause a setup/hold timing issue. The SPI variant and clock to be used for a display is specified in the datasheet of the graphics chip built into and driving the display.
Recently i made a little graphics card for a TFT display without display memory, using a STM32H730 MCU and its LTDC peripheral. It generates digital video from a large buffer in the MCU address range, in my case inside the MCU RAM. It can work with 8 bit per pixel, using the color palette on the fly while generating video and it supports two frame buffers. Their images get mixed on the fly using a transparent color (green screen method). The nice demos they show use one of the frame buffers as background image and the other one for "sprites". The solution even works for video with overlays. Depending on the size of the screen external RAM may be required.

Regards, Dieter

[ebastler]

The data for the world map must have come from somewhere. Probably stored as a block of data in FLASH. So, since you know the initial position of the moving object, fetch that little rectangle from the FLASH and send it out over SPI (which deletes the said object) and then draw the object in its new position.

As described, my first assumed case has a world map rendered from vector graphics, plus a dynamically generated day/night overlay. My current actual use case, as also described, has a background comprising dnamically generated coordinate axes with labels, menu items, and measurement results.

So no, there's no way to just fetch the background section from some static store. (Or to regenerate it dynamically with very simple code.)

[peter-h]

The axes should be super fast to generate and send over SPI. And maybe some other stuff too. Otherwise, yeah, you need RAM

[Northy]

The parts are:

ADUC7023
KSZ9893
BT817

G

[Someone]

It's impressive how after almost two pages of posts the clock/data timing relationship has not been verified.

End of page 3, finally the part numbers are revealed and the data sheets all have clear and unambiguous statements about the clock phase requirements/settings. So its one of those threads:

The LCD chip has no proper timing diagram 

If we can find it trivially, either you're providing the wrong part numbers to us or you've not bothered looking.

"I've Tried Nothing and I'm All Out of Ideas"

[dietert1]

In the BT817 datasheet "4.1.1 QSPI Interface" it says the SPI only operates in mode 0. Then you can go to:
https://en.wikipedia.org/wiki/Serial_Peripheral_Interface
and see the timing diagram and the relationship of CPOL and CPHASE to the SPI mode index. Then you know the correct configuration of the SPI master.
The ADUC SPI is limited at 20 MHz while the BT817 spec is 30 MHz.
The ethernet chip SPI timing is in datasheet figures 6-9 and 6-10. There is a complication with "low speed" and "fast speed" setup. And the SPI pins also serve other functions. Maybe a bit tricky to get it all working properly.

Regards, Dieter

Edit: The ADUC has two SPI issues in its errata ("Silicon Anomaly"). er007 affects slave mode, er004 restricts bit rate. Other info: https://ez.analog.com/microcontrollers/arm7-core-products/f/q-a/18321/has-anybody-got-example-code-that-maximizes-the-spi-baud-rate-in-master-slave-mode (remark about weak SPI clock).

[Postal2]

... which is why your posts usually make a bit of sense but are of no use to anybody working on something specific.

You are right. I see.

[Northy]

Well now I feel like a total fool, the timing was there all along. 
Sorry guys.

G

[Siwastaja]

What a weird and obsolete microcontroller, but that does not matter, took 2 minutes to find the datasheet and SPI configuration register:

https://www.analog.com/media/en/technical-documentation/data-sheets/aduc7023.pdf
page 59

3 SPICPO Serial clock polarity mode bit.
This bit is set by the user; the serial clock idles high.
This bit is cleared by the user; the serial clock idles low.
2 SPICPH Serial clock phase mode bit.
This bit is set by the user; the serial clock pulses at the beginning of each serial bit transfer.
This bit is cleared by the user; the serial clock pulses at the end of each serial bit transfe

Now try out the four choices (00, 01, 10 and 11). Well three left because you already have one (non-working) in use.

[Postal2]

There is one small problem. Assuming that there is no resonance, connecting the oscilloscope probe will shift CLK forward, as will the 10 pF capacitor. Let's assume that the polarity of CLK is reversed. Then any forward shift of CLK should make the situation worse. However, connecting the probe normalizes the situation. For the wrong polarity, this means that CLK moves backward. The author has invented a Time Machine.

[peter-h]

What a weird and obsolete microcontroller

I thought that too. It is 15 years old. I suspect the OP is not the designer in this case; probably was handed this to do an add-on. Nobody would choose a chip like this and especially not from that company

It's not a crazy-expensive chip though, looking at Mouser etc.

[Northy]

Hi all,

I'm feeling a bit better today.
I'll try the other modes tomorrow, but today I used the logic analyser to confirm that the SPI is as per the requirements of both IC data sheets.
I'll look at the physical integrity of the waveforms tomorrow, but I'm back to struggling to measure it with the scope that I've got.

Thanks for your help so far.

G

[Northy]

Hi all,

Thank you for your help with all this, it is much appreciated.
I have made the design reliable (it seems) with a 49R resistor in the CLK line.

I watched this video last night:


In the video the guy states that you should consider a Pi filter for cables between boards. If I was add these for the FCC cable link is there an resource anywhere to show how you should design it?

Thanks,

G

[Postal2]

... I have made the design reliable (it seems) with a 49R resistor in the CLK line. ....

Well done.

.... a Pi filter for cables between boards. ...

Your frequency is 5 MHz. Up to 10 MHz you only need to worry about ringing on the CLK line, if it concerns the reliability of your device and there are no requirements for interference from your device.

[peter-h]

I have made the design reliable (it seems) with a 49R resistor in the CLK line.

Possibky only by luck. You need to verify the timing properly.

Your frequency is 5 MHz. Up to 10 MHz you only need to worry about ringing on the CLK line

Nonsense; ringing is related to the edge properties, not the clock frequency.

[Siwastaja]

It could be false clock edges due to massive amount of ringing but I'm still not convinced. Series resistor will add a tiny bit of delay so it could be still wrong clock polarity, just like adding scope probe adds delay, adding series R adds delay too. But SPI should not be sensitive to tiny changes in delay. So I would still remove the resistor (or add 10pF, or whatever you did to make it inoperational) and do what we have been suggesting from the start, try different clock configuration. A tiny change in code which takes less time to test than soldering any resistors.

Adding series termination to clock line only makes no sense, once you are at it, add 49R to all other outputs as well (so MOSI and nCS at master site; MISO at slave site). If we then hear about problem coming back... 

Still no layout pictures and/or photos. (Bonus points for schematics.)

Finally, after you are sure that clock configuration is correct and figured out why you had problems, then adding series termination (that 49R) is definitely correct thing to do so doesn't hurt, but before going for more filtering please identify if you have a problem, then find the reason for the problem, and only then add a filter designed to correct the problem if it can't be solved otherwise (e.g. better layout).

[Postal2]

Possibky only by luck. ...

I guess when you do something, it's just luck that helps you.

[dietert1]

You can certainly find many youtube videos with engineers unaware of SPI modes, who try to save their wrong designs by some extra resistors. A correct SPI transfer doesn't need those resistors nor any other termination. If it makes a difference, setup/hold times are marginal i.e. the digital design is inconsistent.

Regards, Dieter

Edit: According to the AD forum post i linked above the ADUC SPI clock output is weak and won't produce ringing.

[Postal2]

.... According to the AD forum post i linked above ....

It's called a "relay race", you asked on one forum, dragged it here, someone will drag it to a third... It's a common thing.

[Siwastaja]

A correct SPI transfer doesn't need those resistors nor any other termination.

Well, to be fair, need of termination is an "analog" issue in the sense that protocol does not matter. You need termination if the slew rate of the driver is high enough and the trace you are driving is long enough for transmission line effects to be relevant.

Slew rates vary between different microcontroller families, and some also have configurable drive strengths.

For a PCB trace a few centimeters long, termination rarely makes any difference, but here the combined length of traces and cable are long enough that termination might be well necessary to pass EMC.

Good SI is always worth investigating some time into and series termination resistors cheap, but I agree with you that it's not likely the reason for the functional issues OP is seeing.

[dietert1]

.... According to the AD forum post i linked above ....

It's called a "relay race", you asked on one forum, dragged it here, someone will drag it to a third... It's a common thing.

That was an official contribution from an AD employee, labeled "ADApproved". Don't try to confuse people. You aren't the one who knows better.

[Postal2]

... Don't try to confuse people. ...

If anyone is confusing people, it's you and your company. If you hadn't posted your nonsense about the configuration, the author would have solved everything in 1 day.

[Siwastaja]

Just try the three other configurations.

[ebastler]

Just try the three other configurations.

Kudos for repeating that calmly and without resorting to exclamation marks or emojis.

[Siwastaja]

But it's quite interesting to see that while everybody else deals with SPI clocking issues by choosing the correct clocking configuration, there is at least one who has never heard about SPI clocking modes and uses carefully tuned series inductors and parallel capacitors on the clock line to tune the delay to achieve a "working" system, and probably has had some success doing that.

I guess, if all you have is a hammer, ...

[Postal2]

...  while everybody else deals with SPI clocking issues by choosing the correct clocking configuration, ...

Based on the symptoms described by the author, even a monkey can understand what is going on.

[Northy]

Guys, I'm sorry if you are upset with me, it's not what I wanted.

I have used a logic analyser to confirm that the timing is correct as per the detailed timing diagrams from the data sheets that I'd missed.

I had a look around with the scope today and there was a lot of ringing. So I added the 49R9 to the clk line as a quick test as it had been suggested that was the most important trace. Yes, I should add them to all, but it's particularly fiddly to do. I'll look at it tomorrow.

I've already made a list of things that can be done better on the next iteration of the layout.

I can try the other SPI modes. Both ICs require mode 0, I've verified that the mode is set to 0, and checked the timing is correct to the datasheets, but I'll try the other modes too.

At 5MHz do I not need any filtering either side of the FFC cable?

Thanks,

G

[ebastler]

Guys, I'm sorry if you are upset with me, it's not what I wanted.

I can't speak for Siwastaja and dietert1, but as far as I am concerned, don't worry, I am not upset with you. 

[Postal2]

.... So I added the 49R9 to the clk line as a quick test as it had been suggested that was the most important trace. Yes, I should add them to all, but it's particularly fiddly to do. ....

If you have a requirement for interference from your device, then you will have to install resistors on all lines. If you are only concerned about reliability, then installing additional resistors will not affect anything. The fact is that ringing occurs only on the signal fronts, it will have time to fade before the time of strobing.

....  At 5MHz do I not need any filtering either side of the FFC cable?

If you install resistors on all lines, then no filters are needed. Filtering is needed again because of interference. For reliability, you only need one resistor, which you have already installed.

[Siwastaja]

Guys, I'm sorry if you are upset with me, it's not what I wanted.

Post the information we are asking and we won't be upset . (No, really, I'm having a good time with this thread, mostly thanks to Postal2.)

I mean the low hanging fruit stuff which takes less than a minute for you to produce. Screenshot of schematic, layout, maybe a photograph of the device. It's not like you have to take it using a film camera, develop the film and scan the pictures.

I have used a logic analyser to confirm that the timing is correct as per the detailed timing diagrams from the data sheets that I'd missed.

That would be easier to verify if you posted a screen capture or photograph of the logic analyzer screen.

I had a look around with the scope today and there was a lot of ringing. So I added the 49R9 to the clk line as a quick test as it had been suggested that was the most important trace. Yes, I should add them to all, but it's particularly fiddly to do. I'll look at it tomorrow.

Very excessive ringing can cause issues like this, so it's a real possibility. Definitely add the resistors to the rest of the traces as well. At the driver; so MISO would be at the slave, others at master.

Seeing the scope image would be interesting. Some ringing which actually is not there will also result in from the loop of the ground clip, so if you still have the little metal springy thing which came with the oscilloscope probe (it is easy to lose it), use that. Scratch some solder mask off from the ground plane so you can touch the spring thing, and probe the signal.

And oh, always probe at the receiver pin. Especially now as you have the series termination resistor in place; by definition of source termination signal is only valid at the receiving end of the transmission line.

At 5MHz do I not need any filtering either side of the FFC cable?

5MHz is the data rate and does not mean much else except maybe giving an ultimate limit to how much you can allow your filter to slow down the signal.

Filtering has two different purposes, to reduce emissions and/or to increase immunity. But you should definitely start by fixing the layout (including your cable signal arrangement) because if it's proper then you should not be having emission/immunity problem in the first place. After proper layout, terminate the signals with the source series resistor and it's very unlikely you need any extra filtration. Well increasing the series resistance value beyond the exact characteristic impedance of the trace already is filtering.

[Siwastaja]

If you have a requirement for interference from your device, then you will have to install resistors on all lines. If you are only concerned about reliability, then installing additional resistors will not affect anything. The fact is that ringing occurs only on the signal fronts, it will have time to fade before the time of strobing.

This is actually quite correct. IF the clock configuration is right, then the whole point is that data is sampled in the middle of valid period. What drives sampling is the clock signal; so it's most important to "clean that up". Then the data signal ringing is a smaller problem because it has time to decay before sampling. But only if the clock configuration is correct.

Excessive ringing in other signals can still couple elsewhere and in extreme cases still cause functional issues for your own device. Not passing EMC is more probable issue.

[dietert1]

In his first post the OP mentioned scoping the SPI lines but nothing of ringing. This is strange. He did not show a single measurement until now so the whole "ringing" is a bit fishy. Of course we all know how to make something that rings. By the way, usually there is parallel termination of digital signal by limiting diodes at the receiver end of digital lines.
Neither it was demonstrated that the digital design is correct and that the problem has been solved.

Regards, Dieter

[Postal2]

... That would be easier to verify if you posted a screen capture or photograph of the logic analyzer screen. ...

Northy, take a screenshot of the ringing; if you screenshot something that is already clear, then no improvement will occur in heads.

[Siwastaja]

... That would be easier to verify if you posted a screen capture or photograph of the logic analyzer screen. ...

Northy, take a screenshot of the ringing; if you screenshot something that is already clear, then no improvement will occur in heads.

Well, quite obviously the best idea is a scope capture of both SCK and MOSI. It will show both signal integrity issues such as ringing, and clock relationship to data in a single capture.

[Postal2]

Well, quite obviously the best idea is a scope capture of both SCK and MOSI. It will show both signal integrity issues such as ringing, and clock relationship to data in a single capture.

Yes, I already asked about it. Because my picture, posted earlier, is not very informative. And a real screenshot would be useful. And useful, as we see, for many people.

[dietert1]

OP busy making the clock signal ring like mad.

[Siwastaja]

OP busy making the clock signal ring like mad.

 

[Postal2]

OP busy making the clock signal ring like mad.

He doesn't want to say that he used a series resistor to see the ringing, so as not to offend you.

Because it will show that not only do you not know SPI, but you also don't know how to use an oscilloscope.

[Siwastaja]

You realize that this long ground lead with some ~50-100nH of extra inductance (and a loop which picks up any magnetic field) causes much more measurement errors than <10pF of input capacitance of a typical oscilloscope + 1:10 probe you are trying to reduce with an extra series resistor?

I mean, while at it, give more complete probing advice.

If only 1:1 probe is available then I wholeheartedly agree an extra series resistor is pretty important.

[Postal2]

This is a 1:10 probe, and it does not switch. Of course, you will not see everything in its pure form as in the picture. However, there is always a point nearby with which you can compare. And the assessment is made precisely by comparison.

[Siwastaja]

Oh yes, you can probe the signal and then probe the ground plane next to the signal and take the difference of the two traces to remove the contribution of your ground lead antenna.

The rest of us will use the tool intended for the job, the springy thing that came with the probe which reduces the ground lead length from 10cm to 5 millimeters or so.

[Postal2]

Oh yes, you can probe the signal and then probe the ground plane next to the signal and take the difference.....

I already understood from your previous statements that it turns out that some people might have such a thought.

[dietert1]

This is all futile in the case of SPI. We have a GHz scope and i have done work at 50 psec time scales. That was no SPI. Look at the numbers.
The ADUC is known to produce a weak SPI clock signal at 20 MHz, so the rise time will be about 3 to 5 nsec. At that time scale a short ground lead or any other 10 or 20 cm wire will slightly affect the signal, but not disturb a well designed digital transmission. I mentioned that above. Ringing isn't the problem.
I'm no moderator but here i see the continuous attempt to establish a false narrative. It started with the first post of the OP. Pretending to seek help but instead of documenting the problem, already proposing that resistor nonsense. Inserting resistors into on-board SPI signals is unnecessary and may in fact result in a transmission sensitive to crosstalk and EMI.
One exception i know of is driving high resolution ADCs with SPI interface, but then it's not about the digital signals but about protecting the analog signals. The resistors sit next to the ADCs SPI pins.
Another exception i know of is off PCB SPI transmission. Then you want to use slow clock, twisted pairs and the like to get reliable transmission. That's a different game, more like USB or Ethernet.

Regards, Dieter

[Postal2]

...  We have a GHz scope and i have done work at 50 psec time scales. .....

If you give a monkey glasses, it will put them on its butt.

[Siwastaja]

Inserting resistors into on-board SPI signals is unnecessary and may in fact result in a transmission sensitive to crosstalk and EMI.

Well, series-terminating a unidirectional single-ended point-to-point line driven by CMOS output stage is never wrong and can't hurt. For slow edge slew rates or short lines, it doesn't matter. For longer lines or higher edge slew rates it does.

Then again if OP has a shared SPI bus for those two slaves (instead of two separate buses), then it's not point to point and series termination will not work optimally.

Of course excessive resistor value would introduce extra RC filtering and increase the driving impedance enough for the line to become more susceptible to interference but that would not happen with usual values of 33R-47R.

Note that OP does not simply have SPI-on-board, they have SPI over two boards and cable with total length of 367mm. I would most definitely design in series termination on a board like this.

Adding inductor in series as suggested by our dear Postal2 is a colossally bad idea, I think, though. And of course, so is spending a lot of time into refinement of SI when the SI probably isn't the issue.

[Postal2]

... Adding inductor in series as suggested by our dear Postal2 is a colossally bad idea, I think, though. ...

The inductor would dampen the resonance without reducing the amplitude. But it doesn't make much difference, a resistor would work too, if that's what you're used to. I would put a resistor too, if it were 50 cm closer on the table.

[ejeffrey]

Oh yes, you can probe the signal and then probe the ground plane next to the signal and take the difference of the two traces to remove the contribution of your ground lead antenna.

I know you realize this is not the best approach but for anyone else reading: this is a method of last resort, do not use it until you have fixed everything else you can.  Doing a differential measurement like this will cancel pickup by the ground lead antenna, but it won't solve the biggest problem with passive proves which is ringing of the probe capacitance with the ground indictance.  That ringing is specificifically caused by transitions on the signal pin exciting the LC resonance.  If your prove the ground, there won't be any transitions to excite the resonance and you won't much.

If you see ringing on a prove and have lost the ground pin attachment for your probe or are too lazy to use it, this is what you should do: take a measurement with the ground clip attached.  Then, fold it up as close to the prove body as you can get, aiming for a 5:1 reduction in loop area.  If the ringing you observe changes significantly, then basically don't trust your measurement until you get a low indictance ground pin. 

I do measurements all the time with a typical 6" alligator clip ground lead.  But I just know how to recognize probe ringing and ignore it when that's not what I am looking for.  And when I care about that sort of thing I do install the low indictance ground pin.

[Postal2]

Oh yes, you can probe the signal and then probe the ground plane next to the signal and take the difference of the two traces to remove the contribution of your ground lead antenna.

I know you realize this is not the best approach but for anyone else reading: this is a method of last resort, ....

This kind of probe work is possible (ground checking), but only if you synchronize the oscilloscope with the signal you are searching for.

..... or are too lazy to use it, .....

Definitely.

... I do measurements all the time with a typical 6" alligator clip ground lead.  But I just know how to recognize probe ringing and ignore it when that's not what I am looking for.  And when I care about that sort of thing I do install the low indictance ground pin.

I completely agree.

[ejeffrey]

... Adding inductor in series as suggested by our dear Postal2 is a colossally bad idea, I think, though. ...

The inductor would dampen the resonance without reducing the amplitude. But it doesn't make much difference, a resistor would work too, if that's what you're used to. I would put a resistor too, if it were 50 cm closer on the table.

Please nobody else listen to this, this is terrible advice.

Inductors don't dampen resonances except by accident: they *store* energy and are more likely to make your problem worse rather than better.  They do push the resonant frequency down, which might or might not help, but saying it is damping is completely wrong.

[Postal2]

... Adding inductor in series as suggested by our dear Postal2 is a colossally bad idea, I think, though. ...

The inductor would dampen the resonance without reducing the amplitude. But it doesn't make much difference, a resistor would work too, if that's what you're used to. I would put a resistor too, if it were 50 cm closer on the table.

Please nobody else listen to this, this is terrible advice.

Inductors don't dampen resonances except by accident: they *store* energy and are more likely to make your problem worse rather than better.  They do push the resonant frequency down, which might or might not help, but saying it is damping is completely wrong.

I don't understand why I have to explain obvious things.
First, try replacing the inductor through that powers the motor with a resistor.
Second, I recommended smd 0402, but it already has resistance and low quality factor.
Third, the output pin is involved in resonance, when we put the inductor closer to it, we break this circuit. The resonance will not change, it will simply stop.
If something is unclear, clarify what exactly, and do not try to criticize right away, so as not to look like a fool later.

Industrial engineering does not know about your recommendations (photo).

[peter-h]

Please nobody else listen to this, this is terrible advice.
Inductors don't dampen resonances except by accident: they *store* energy and are more likely to make your problem worse rather than better.  They do push the resonant frequency down, which might or might not help, but saying it is damping is completely wrong.

Agree 100%. Postal2's postings have been previously discussed in various threads...

[Postal2]

Please nobody else listen to this, this is terrible advice.
Inductors don't dampen resonances except by accident: they *store* energy and are more likely to make your problem worse rather than better.  They do push the resonant frequency down, which might or might not help, but saying it is damping is completely wrong.

Agree 100%. Postal2's postings have been previously discussed in various threads...

peter-h, your knowledge of the issue is not worth discussing.

Your frequency is 5 MHz. Up to 10 MHz you only need to worry about ringing on the CLK line

Nonsense; ringing is related to the edge properties, not the clock frequency.

... At 5MHz do I not need any filtering ....

.... The fact is that ringing occurs only on the signal fronts, it will have time to fade before the time of strobing. ...

[Siwastaja]

If you see ringing on a prove and have lost the ground pin attachment for your probe or are too lazy to use it, this is what you should do: take a measurement with the ground clip attached.  Then, fold it up as close to the prove body as you can get, aiming for a 5:1 reduction in loop area.  If the ringing you observe changes significantly, then basically don't trust your measurement until you get a low indictance ground pin. 

I do measurements all the time with a typical 6" alligator clip ground lead.  But I just know how to recognize probe ringing and ignore it when that's not what I am looking for.  And when I care about that sort of thing I do install the low indictance ground pin.

Yeah, I do agree that the best practice in a pinch without proper tools is to squeeze the ground lead closer to the probe while watching the screen. If you see the ringing reduce you can mentally imagine it reducing even more by eliminating the loop.

But really, you can use pliers to make a new springy thing for the probe tip from any (long enough) component lead; you may need to sacrifice one THT resistor just for the leg. It won't be as... springy as the real thing (which is made out of spring steel or something), but will work fine for a few measurements.

[dietert1]

Another method is using an active probe. We have some Lecroy AP022 probes with 2.5 GHz bandwidth, 100 KOhm and 0.6 pF input. Often the active probe won't ring when the 10:1 passive probe rings visibly, i mean both with ground lead of similar length. The active probes came with those spring contacts, in order to capture analog signals up to some GHz. Wavelength at 2 GHz is 15 cm, so the ground lead of more than 5 cm will be a problem.
All this may be useful when you try to capture 1 nsec or faster signal edges, yet unnecessary with a typical SPI bus. If you do a measurement of a SPI bus with a 4 channel scope and all four ground leads attached, there will be very little ringing.

Regards, Dieter

[Siwastaja]

Inductors don't dampen resonances

Yeah, but this is how Postal2's brain operates; in reality inductors cause resonances which then possibly need damping. If you reduce this to two keywords, "inductors" and "damping", you easily come to opposite (wrong) conclusion.

When inductance is added, you add damping e.g. in form of explicit parallel resistor, or by choosing a lossy inductor (lossy core material). Ferrite beads as shown in Postal2's photograph are a typical example of the latter.

But I would consider adding ferrite beads to SPI bus as a last resort option and that is if it's failing EMC testing (radiated or conducted emissions for example). I'm very doubtful they ever turn a non-functional SPI bus into functional one.

[Postal2]

.... or by choosing a lossy inductor (lossy core material). Ferrite beads ....

You are right, I have a lot of different ferrite, sometimes ferrite works wonders. But in this described effect ferrite is absent:

... If I replace the 50mm FFC cable with a 120mm FFC cable, the screen becomes more reliable (as in there's less corruption). .....

[dietert1]

Here i have some scope dumps of an I2C bus with about 40 cm of 1.27 mm flat cable between STM32 MCU and BME680 sensor, with 4K7 pullups. Within the flat cable both SCL and SDA have Gnd or Vcc wires on each side.
I used a Lecroy 500 MHz scope at full bandwidth. The dumps show how ringing depends on STM32 pin speed configuration. The low speed configuration looks almost clean, except some crosstalk to the other signal in OD state. As ringing remains less than 0.8 V with all three configurations, all three work completely reliable. In this case pin speed configuration is about avoiding EMI.

Regards, Dieter

[Wolfram]

For probing fast digital signals, 500 ohm 10:1 passive probes are also a cheap way to reduce the impact of ground lead inductance. A 450 ohm series resistor at the probing point, into a 50 ohm coax terminated into 50 ohms (either using a scope with a 50 ohm termination option, or an inline 50 ohm BNC terminator). As long as the signal source is not significantly affected by 500 ohm resistive loading, this method gives very high bandwidth and much flatter response than usual high impedance probing. It's also possible to use trade off the signal level for loading by making the series resistor larger, 950 ohms for 20:1 or 4950 ohms for 100:1.

[Postal2]

.... A 450 ohm series resistor at the probing point, ....

Yes, that's right.

....The dumps show how ringing ....

I2C just doesn't reach the speeds where ringing becomes a problem.

[dietert1]

Maybe you missed it, but above it has already been explained that ringing does not depend on clock frequency but on rise and fall times.
Let me repeat: In my measurements ringing is no problem as it's amplitude is always less than 0.8 V, even when the MCU produces the fastest signal edges it can. And the larger spikes decay rapidly, lets say within 10 nsec. So the hardware works the same at much higher clock rates, e.g. 50 MHz. Next time i have some cable SPI on my desk, i will show similar measurements for SPI.

Regards, Dieter

[Postal2]

Maybe you missed it, but above it has already been explained that ringing does not depend on clock frequency but on rise and fall times. ....

Okay, okay, you scared me, from now on I will use the most sophisticated means of suppressing ringing on the I2C bus.

[Siwastaja]

I2C just doesn't reach the speeds where ringing becomes a problem.

STM32 IO pins use the exact same switching MOSFET structures in I2C and SPI modes, so there is no difference in amount of ringing when going low (driving '0'). Of course, with I2C, there will be no ringing when going up because that is super slow through the pull-up resistor.

[dietert1]

Yes, with my measurements i did not check the ringing from fast positive edges as I2C doesn't have them.
Anyway, there is the argument of linearity, so ringing from rising edges will look similar to ringing from falling edges, except with a positive spike. Traditionally rising edges were "weaker" even in totem-pole outputs, but that remains to be demonstrated by measurement.
I think ringing depends on the cable configuration. A ribbon cable with enough ground wires inside has a very regular geometry that is known to work well at rather high clock rates. Remember those ribbon cables for computer hard disks that were used at clock rates up to 66 MHz. They had a similar length and as far as i remember every third wire was a ground.

Regards, Dieter

[Postal2]

STM32 IO pins use the exact same switching MOSFET structures in I2C and SPI modes, ....

What can you suggest to eliminate this terrible interference on the I2C bus?

[ricko_uk]

Some suggestions...:

1) Have you checked there aren't any ground loops which might be redirected or attenuated when you connect the oscilloscope?

2) Have you checked if there are nearby sources of very strong EMI (on the board or somewhere else)?

3) The oscilloscope gives you a better picture than a logic analyser but if you get a non-corrupted packet you might not see the issue. Have you tried using a digital anaylser to have a better picture of all bits/bytes that might be "seen" (i.e. read) by a digital device like your micro? you might see some patterns perhaps.