Errror injection in SPI bus

[otzen]

HI

I am looking for a device to test my SPI communication. (No, not a host device or slave simulator).

We have a product with a SPI master that talks to different products acting as slaves, using our own protocol.

To setup a regression test for the error detection on the master and slave devices, I need to inject errors on the SPI bus.

Note: This could be done by adding special features to the master and slave devices prompting them to send invalid telegrams, but that comes with a lot of additional SW maintenance, that I want to avoid.


Master -----------+------------Slave
                  ^
                  |
               Tester


So If master sends
0x12, 0x24, 0x53
and i ask the tester to inject 0xFF on second byte, what slave sees is this.
0x12, 0xFF, 0x53

or if i ask the tester to inject 1 on last bit in second byte, what slave sees is this.
0x12, 0x25, 0x53

Same functionality for slave to master.

I cold probably build this using an Arduino and a few resistors, and some clever SW, but I would prefer to buy something already done, as development time is money.

So does anybody know of a device to do this?

Edit: For the questions about length, the protocol running on our SPI, has a fixed length of 12 16-bit words = 192bit, for each telegram. And running at 7.5 Mhz.

[SiliconWizard]

You could take a look at tools like this: https://www.thelabeshop.com/Analyzers/Bus-Analyzers/PC-based/Zeroplus-I2C-SPI-Control-Center/
It can monitor and generate data, but I'm not sure it can modify data on the fly as you would like to be done.

Of course, you could achieve this with a small FPGA (a microcontroller would  inevitably delay the transmission which would introduce a bias in your tests IMO).

[CopperCone]

You can count the rising edges with a ripple counter then on the correct count, pull a transistor low for a programable duration to fuck up the bus.


This could be done with a few 74 series chips. The only hard part would be to decode the output of the binary ripple counter, you would just use one mcu scanning its gpio constantly for the correct ripple code, when this correct combination is reached it would trigger an output to trigger a transistor for some duration, this could probobly be done with a trimpot and a fast comparator circuit.

If hats not fast enough you would need to wire up gates to decode the ripple counter into a disturbance trigger.

Since your transmissions are not too long you could probobly make some kind of generic decoding trigger with a piece of perfboard that has some headers with jumpers on it program the correct key. Since you only listed 3 8 bit packets this falls within a 8 bit counter, which does not require too many wires... You would need to rewire it every time unless you did something clever with dip switches

Two options other then logic gate level decoding might be to program a memory chip to output 11111111 when the correct register is read, but you would need to reprogram the memory each time to set the trigger. The 1 output would trigger your adjustable off pulse. I think parallel input parallel output nemory chips exist.

An analog solution would be to attach a fast parallel dac to your parallel output counter then use a fast comparator to trigger your pull low transistor time duration circuit. This would offer full potentiometer control i think, where the pot regulates the comparator trigger votlage which controls the count.

I dont know how precise it needs to be so maybe you could make a discrete dac out off resistors and a filter to do the job lol

You would need to do a quick estimate of the timing requirements

So long the bus is not too fast and you are dealing with less then 256 bits i think its pretty reasonable. Long blanking times might require elements you switch into the delay circuit to maintain potentiometer control.

Personally id like to see a solution that does not use a fpga or mcu fuck all that coding

This thing would make a nice piece of lab equipment imo. Not having to open an ide, deal with software obsolesence, etc is definatley as valuble as your time. Especially if you put some bnc connectors and a equipment bypass switch on it so it hooks up to an oscilloscope nicely for tuning.

Mm and tou can also make it switchable so instead of just pushing a bus low for some duration it sums in an external port that can be connected to a signal generator and pa so you can simulate things like heavy periodic interference

[GigaJoe]

would it be a signal function generator , that do output some pattern , and trigger by chip-select signal, will do the thing  (with hi output impedance ) ?

[CopperCone]

you can defiantly use a AWG for this if the strings are short enough and its fast enough, but they might be a bitch to program / interface.

[TK]

Maybe you can use a microcontroller and program a SPI bus repeater that can randomly introduce errors to the relayed packets?

[otzen]

Hi

I did take a look at the Zeroplus-I2C-SPI-Control-Center, unfortunately it is limited to 4Mhz, and we run 7.5 Mhz on the SPI bus.

I could easily wire up a few 74's, actually the simplest solution, would be an and and a or gate in series, that I have a pin to force high, and one to force low, combined with an Arduino.
For the SW part of such a tester, I am a SW developer, so that would take me a couple of hours to make.

But this is going into the automatic test setup in the test department. And they prefer something that is not homemade on a breadboard, and of which they can order extras/replacements if needed. Of course we could make a proper PCB, and create a product number etc. but this quickly becomes more expensive than buying a finished product, if it exists.

We can't be the first who want's to test the error handling on a SPI bus. Or does everyone else blindly trust that their error handling in the protocol layer just works without testing it?

For the questions about length, the protocol running on our SPI, has a fixed length of 12 16 bit word = 192bit, for each telegram. And running at 7.5 Mhz.

[ogden]

So does anybody know of a device to do this?

Self-made one. You will need different test patterns anyway, so need "tester" to be quite flexible and programmable. Luckily you have fixed length 192 bit packets, thou quite fast clock rate. I would just pick some microcontroller with at least two SPI peripherals and make "programmable SPI pass-through error injector". Packets would be completely received using slave SPI peripheral of tester, then accordingly modified, then sent out of master SPI peripheral. More or less few days project - in case it is ok to delay packets. If you want realtime error injector which is precise downto individual bit - you need FPGA. Doable but much more complex.