I have developed driver for SPI master which can run at maximum bit rate of 20MHz, but I don't have any SPI slave which can reach 20 MHz. For data verification I have shorted both MOSI and MISO pins and comparing data received with the data which I have transmitted. I just want to ask if this test case will be sufficient enough for data verification at 20 MHz? Also for testing chip select pin, I have tested it with Oscilloscope.
7
-
1\$\begingroup\$ Wouldn't it be easier just to hook up them to the oscilloscope and use the decoders? \$\endgroup\$– valerio_newCommented Mar 29, 2018 at 12:51
-
1\$\begingroup\$ Simply use an identical copy of the master hardware as slave? \$\endgroup\$– LundinCommented Mar 29, 2018 at 13:43
-
\$\begingroup\$ What do you mean by "data verification"? \$\endgroup\$– Bruce AbbottCommented Mar 29, 2018 at 18:10
-
\$\begingroup\$ By verification i meant no data should corrupt at 20 MHz bit rate. \$\endgroup\$– Ameer HamzaCommented Mar 30, 2018 at 7:22
-
\$\begingroup\$ Am also checking same way. I am seeing readbuffer values are zero once transfer is complete. Can you share your configured code for this? \$\endgroup\$– giri hkCommented Aug 23, 2021 at 11:27
|
Show 2 more comments
2 Answers
\$\begingroup\$
\$\endgroup\$
While you may conduct such a test barring anything else attempting to drive MISO in conflict, and an observed failure could be meaningful, success in such a loopback test is of limited meaning.
Even aside from analog issues, an SPI interface is fundamentally stateful logic. For the slave to produce bits in response to the master clock, one of two things must happen:
The slave receives the master clock after propagation and analog delays, and directly uses a buffered version of this to clock a data register which replies to the master after internal, analog, and propagation delays.
The slave samples the master clock with a faster, internal clock, and uses that to enable an internally clocked data register which replies. Thus in addition to the delays above, there is a sampling jitter and possibly one or more internal clock periods of state advancement needed to generate a reply. This is particularly common for MCUs operating as SPI slaves.
Either of the above could at a high clock rate be sufficient enough to cause reply data to arrive after the clock edge on which the master will sample it, or insufficiently in advance of it to satisfy a setup time requirement.
answered Mar 29, 2018 at 18:56
\$\begingroup\$
\$\endgroup\$
No you can't.
Even if you find a 20MHz device, you can test it for that device only. Other devices will have different timing.
I would expect the data coming into the MISO pin to be the most critical as it is the longest round-trip: master_clock_out -> slave_clock_in -> slave_data_out -> master_data_in. You do not test that with a direct loop-back as there is no slave involved.
To know if an interface will work you have to read and check the timing specification of all the chips involved.
Also the timing would depend on the capacitive load of the clock and the data lines. That will very from board to board and from device to device.
