Hello,
We have a SPI problem that we can’t understand. The failure is that received or transmitted data is shifted 1 bit. We think it is a glitch problem on the SPI clock that causes an extra clock pulse. It occurs rarely. We had problems with this earlier and thought we solved the problem with a 22 ohms series termination resistor installed directly after the SPI clock pad. The signal trace after the resistor is about 2 inch long. See post at http://e2e.ti.com/support/arm/sitara_arm/f/791/t/271189.aspx
We have gone through the SPI registers, SPI bus and the SW but can’t find anything wrong.
We use McSPI1 with two channels. CS0 with 16Mbit and mode 3. CS1 with 1Mbit and mode 1. McSPI1 pin configuration is fast slew, receiver enabled, pull up enabled for all pins.
out32(conf_mcasp0_aclkx , (MODE(3) | PULLUDEN | PULLUP_EN | RXACTIVE)); /* SPI1_SCLK */
out32(conf_mcasp0_fsx , (MODE(3) | PULLUDEN | PULLUP_EN | RXACTIVE)); /* SPI1_D0 */
out32(conf_mcasp0_axr0 , (MODE(3) | PULLUDEN | PULLUP_EN | RXACTIVE)); /* SPI1_D1 */
out32(conf_mcasp0_ahclkr , (MODE(3) | PULLUDEN | PULLUP_EN | RXACTIVE)); /* SPI1_CS0 */
out32(conf_xdma_event_intr0 , (MODE(4) | PULLUDEN | PULLUP_EN | RXACTIVE)); /* SPI1_CS1 */
Here is an oscilloscope picture of the SPI clock measured with normal probe with short leads before and after the 22 ohm resistor. (Not a FET probe)
Every 15 ms we have about 100 percent CPU load and about every 25 ms we use the SPI bus in a different thread with higher priority. We think the issue occurs when CPU load is 100 percent and we use the SPI bus.
The strange thing is that the problem disappear when we measure the SPI clock after the 22 ohm resistor with a normal probe (10Mohm 10pF).
If we add a 10 pF cap after 22 ohm resistor the problem also disappears.
Is this a known problem? What could cause the SPI clock glitch? Is there a workaround in the SW?
Best regards
Magnus
