SPI Loss of Synch

[dknguyen]

For my magnetic compass, it has the following pin in addition to the MOSI, MISO, SCK, and SS pins for the SPI interface:

SYNCH PIN:
"The SYNC line is not needed except in cases where the V2Xe gets out of
synchronization with the host; a rising edge on the VX2e SYNC line will reset
the V2Xe’s SPI and communication buffers. Synchronization problems mostly
occur during power up when I/O ports and hardware are being initialized. This
may cause glitches in the clock line and might be interpreted by the V2Xe as
clock cycles. The SYNC line is totally asynchronous with respect to the SPI so
proper care in its implementation is highly recommended."

What exactly is this loss of synchorinization on the SPI line? I've never seen this line on any other SPI interface. I'm not sure why I haven't see this if it is something (loss of synch) that could happen.

 

[eblc1388]

Its there but you are not required to use it. It is like fitting a reset button to a PIC/AVR that has power ON reset.

Just in case you want to take positive action to make absolutely sure that the data from the SLAVE is in sync. It should normally be in sync but one sometimes want to eliminate the case where noise or glitch can put the data out of sync.

 

[Oznog]

Loss of sync is when the TX and RX lose a bit-time somewhere so the bit counters don't agree.

For example, say they send out a 16-bit frame. You get one bit after another and just keep going. Where does one 16-bit word end and the next begin? It's really tough if you lose sync. Sometimes the device generates the clock, and pauses it between words, which is potentially detectable by the controller. Sometimes you can write code to recognize bad words, although just what you can do to figure out what the first bit is can be tricky. If the SPI device has a reset available, by far the easiest solution is to pull it and reset your bit-count to zero.

They sort of depend on never losing sync to begin with, but that's a pretty iffy thing to guarantee.

This is why we created SPI with a Frame or CS wire. You either pull it low to start the frame or it will pull it low to indicate the frame is starting. Microchip's earlier SPI modules don't handle it though. You can handle it on an interrupt basis or you can get a newer part with a hardware Framed SPI Module, unfortunately that hardware module has been a bit "buggy".

 

[dknguyen]

Isn't that what chipselect is for? It tells when data is supposed to be sent and when it's not? Or is this for the case where CS is always pulled low?

Hmm, so I should connect the master reset up to this SYNC output also? That reminds of somethign I've never thought of before...I should probably connect all the I2C devices on the robot to the master reset, especially the motor controllers so if for some reason I manage to hit the reset the robot doesn't continue to move forward blindly.

Problem is...there is no reset output on the I2C devices...

 

[Oznog]

Generally, yes. The CS pin allows you to recover sync completely.

There are some other cases where the CS may not be used. For example, I have an ADC which operates in "continuous conversion" mode. It also has an optically isolated SPI bus and I didn't want to use more than a dual optocoupler for the SDO and CLK lines. This is however a problem, since I can't use CS then persistent loss of sync is possible.

dknguyen, I2C does have mechanisms to recover the start of the data right away if sync is lost. I don't recall what it is, but it is there.