SPI Clock Problem at 3Mhz

[vineet2]

Posted on December 02, 2014 at 03:49

HI Group,

    I have a development board which is acting as SPI Master connected to an STM32 chip on another prototype board acting as SPI slave. I cannot change anything on the development board. I am facing an issue with SPI communication. When the data is sent at 100khz, 250khz anf 500khz, the data reaches the slave correctly. When I increase the frequency of SPI clock to 1Mhz and 3Mhz, then the data on the SPI slave starts getting corrupted. I have captured the waveforms at all the mentioned frequencies from the developement board side and for 3Mhz from the STM32 side. Cable length from the development board to the prototype board is 6 inches. In all the attachments: Pink Line is MOSI Blue line is SPI Clock Please share your thoughts on how to resolve the issue? Regards, Vineet. #stm32 #spi-clock #ringing

[vineet2]

Posted on December 03, 2014 at 03:34

Hi All,

   I reduced the wire length of the clock from 6inches to 3 inches. Same result. Would it help to connect a schmit trigger chip so clean up the MOSI Line? Vineet.

[Tesla DeLorean]

Posted on December 03, 2014 at 03:41

Ok, so perhaps stop focusing on the STM32, and pay more attention to your master, and how it's configured, and the specs for the pins.

You'd want keep ALL the wires short and of uniform length, and a really solid ground connection.

[vineet2]

Posted on December 04, 2014 at 06:47

Hi,

Actually, I dont have the schematics of the Gemalto Board, so I dont know for sure what is there between the SPI pins on the chip and the ones on the header. I only have the option to explore what is happening outside the header. I put a resistor of 44 ohms on the MOSI line from the slave side to ground and was able to solve the issue. Please take a look at the MOSI line in pink. They are better in the Image4 file. I am able to get data correctly upto 6Mhz. My only concern is I cant explain this. I learnt about resistance termination, so I thought it would be useful. Since I will be going a PCB up next I want to be sure if this is the right thing to do. Please share your thoughts. Regards, Vineet. ________________ Attachments : Image2_Zoom.jpg : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I0yc&d=%2Fa%2F0X0000000bgU%2FBAIPGWYtdYpFMfxnl.Yw257SEuhbTR099K5ZBWOXb68&asPdf=falseImage4_Zoom.jpg : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I0yS&d=%2Fa%2F0X0000000bgT%2FZRB4UQI3vmgx5vwoLBZvdPBzB0EIZXeidB2dVlZ2M3M&asPdf=false

[John F.]

Posted on December 05, 2014 at 09:49

When  a logic signal must pass between separate PCBs it's usual to buffer it. For low speed (115kb/s) communications single ended interfaces like RS232 will do. For higher speeds (10Mb/s) a balanced differential interface like RS485 is used. Where signal edges can be slew rate limited or lengths are short it's possible to use unterminated signal pairs (no resistor(s) between them).

For fast (100s of MHz) signals, Low Voltage Differential Signalling LVDS may be used. This is a balanced differential interface but with lower voltage swings and always uses resistor termination (at both ends if multiple tranceivers are connected to the bus). If you must send your SPI signals between two PCBs you (or your hardware engineer) must decide what to do based on the signal wire length, data rate and power consumption you can tolerate. Although LVDS looks like overkill (400MHz possible) it may be the lowest cost mainstream option. You also need to pay attention to the grounds used which should be common between the two PCBs and to the characteristic impedance of the signal paths as others have mentioned. Just adding resistors to ground or wherever is not likely to be a robust solution. Can't you just get the PCBs closer and reduce the signal wire lengths (to less than a couple of inches). You will need to do your own research and make a judgement as to what best suits your requirements.

[ilmars]

Posted on December 08, 2014 at 16:20

>I learnt about resistance termination, so I thought it would be useful.

You better don't terminate CMOS lines but add impedance-matching series resistors. In your first 3MHz waveforms little ringing is visible. Try adding 22ohm series resistors to all the lines as close to output as possible, check waveforms. If still notice ugly overshoots - increase series resistor. If waveform became too rounded - decrease resistor. BTW 3MHz waveforms in your original post looks quite good to me. It shall work with such signals.[edit] BTW crosstalk is also noticeable. So you definitely need as short cables as possible, do not run signal lines in parallel but in ribbon cable put ground lead inbetween them, add series matching resistors for all the signal lines.

[Pm77]

Posted on August 18, 2015 at 12:32

Hello there,

I had similar issue with SPI clock running at 18 Mhz(max allowed Fpclk / 2. Where my Fpclk is 36M). Everything was working fine initially until data read from SPI-DR was started trowing garbage. Interesting thing was after power on reset results were correct but in seconds it was throwing garbage.. My config was as follows RCC_APB1PeriphClockCmd(RCC_APB1Periph_SPI2, ENABLE);     RCC_AHB1PeriphClockCmd( RCC_AHB1Periph_GPIOB, ENABLE);          GPIO_InitStructure.GPIO_Pin   = GPIO_Pin_15;     GPIO_InitStructure.GPIO_OType = GPIO_OType_PP;   GPIO_InitStructure.GPIO_Speed = GPIO_Speed_100MHz;   GPIO_InitStructure.GPIO_Mode  = GPIO_Mode_AF;   GPIO_InitStructure.GPIO_PuPd  = GPIO_PuPd_NOPULL ;   GPIO_Init(GPIOB, &GPIO_InitStructure);     GPIO_PinAFConfig(GPIOB, GPIO_PinSource15, GPIO_AF_SPI2);                    GPIO_InitStructure.GPIO_Pin   = GPIO_Pin_10;     GPIO_InitStructure.GPIO_OType = GPIO_OType_PP;   GPIO_InitStructure.GPIO_Speed = GPIO_Speed_100MHz;   GPIO_InitStructure.GPIO_Mode  = GPIO_Mode_AF;   GPIO_InitStructure.GPIO_PuPd  = GPIO_PuPd_NOPULL ;   GPIO_Init(GPIOB, &GPIO_InitStructure);   GPIO_PinAFConfig(GPIOB, GPIO_PinSource10, GPIO_AF_SPI2);     //SPI interface config--------------------------------     SPI_InitStruct.SPI_BaudRatePrescaler = SPI_BaudRatePrescaler_2;     SPI_InitStruct.SPI_CPHA = SPI_CPHA_2Edge;     SPI_InitStruct.SPI_CPOL = SPI_CPOL_High;     SPI_InitStruct.SPI_CRCPolynomial = 0;     SPI_InitStruct.SPI_DataSize = SPI_DataSize_16b;     SPI_InitStruct.SPI_Direction = SPI_Direction_2Lines_RxOnly;     SPI_InitStruct.SPI_FirstBit = SPI_FirstBit_MSB;     SPI_InitStruct.SPI_Mode    =    SPI_Mode_Slave;     SPI_InitStruct.SPI_NSS = SPI_NSS_Soft;     SPI_Init(SPI2,&SPI_InitStruct); I had scopped on SCK and MOSI pins(on STM32F407 demo board) and it was perfectly synchronized data and clock with rise time 25ns(I have differential driver driving these pins). I changed board and results were same. Then I changed SPI2 to SPI3 and SCK and MOSI to PB3 and PB5 respectively and suddenly it was working. At time of  config I was aware PB10 is shared on STM32F407 demo board (MP45DT02 SPI_SCK). So possible conclusion is at higher speed shared pin's tracks going all over place was adding extra capacitance(with Gnd plane) affecting signals @ IC pin. So look out for this possibility.. Pankaj