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

[waclawek.jan]

Posted on December 02, 2014 at 08:36

Inadequate common ground? Too slow slave SPI?

JW

[John F.]

Posted on December 02, 2014 at 09:45

The signals in your pictures don't look that bad. Are you sure you have the polarity of the clock edges correct for the device you're interfacing? You don't say what device it is.

[vineet2]

Posted on December 02, 2014 at 10:07 Hi John,    Yes the polarity of the clock is OK. Actually, the SPI slave, which is the STM32 chip, is a SecureCore 300 chip, is getting correct data at clocks 100, 250 and 500 khz. When I move to 1Mhz, I see that the first bit of the MSB is incorrect, the rest of the data looks ok. Then when I move onto 3 Mhz, first byte seems to be corrupt, the data that follows is ok. On the SPI Master side, is a Bubble Board from Gemalto: http://m2m.gemalto.com/developer-zone/order.html I hope I answer your questions. Regards, Vineet.

[vineet2]

Posted on December 02, 2014 at 10:10

Actually, the SPI slave at the driver level is running faster than the master. So I dont think that may be an issue.

Also, I am taking the 5V and Gnd power from the Gemalto board which is connected to PC over USB. Could you explain what you mean by Inadequate common ground? Regards, Vineet.

[waclawek.jan]

Posted on December 02, 2014 at 10:54

> Yes the polarity of the clock is OK.

How do you know that? What is SecureCore 300? > Could you explain what you mean by Inadequate common ground? Every signal should have its dedicated return/ground wire in the cable. Connect the oscilloscope's ground to the slave's ground and measure the signals at the slave in that way. Also, what is the nature of the erratic data? Some bits flipped? If yes, systematically from 1->0 or 0->1; or random? Or is it bit-shift? If so, how do you synchronize slave to master, do you use NSS? Why is data amplitude on the scope pictures different from clock amplitude? What was the Y(voltage) range for both waveforms/channels? JW

[vineet2]

Posted on December 02, 2014 at 12:22

Hi JW,

How do you know that? What is SecureCore 300? [Vineet]: Because I am able to get correct data for 100, 250 and 500kbps. I cannot disclose too much about the chip, but it is cortex M3, be assured. Also, what is the nature of the erratic data? Some bits flipped? If yes, systematically from 1->0 or 0->1; or random? Or is it bit-shift? If so, how do you synchronize slave to master, do you use NSS? Why is data amplitude on the scope pictures different from clock amplitude? What was the Y(voltage) range for both waveforms/channels? [Vineet]: For the last 2 questions, please refer the image attached. I am sending the following data from the Master: 01AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA02 and I receive the following:

E1EA

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA02 Another example: I send: 00100000102030405060708090102030405060708090102030405060708090102 I recevie:

E1

000000102030405060708090102030405060708090102030405060708090102 So it is consistent that the first 2 bytes are getting corrupted. This is confirm. This is at 3Mhz SPI clock. I have kept the range of both waveforms same in this file. Now the only issue here is that the rest of the data seems OK except the first 2 bytes. Also the NSS is controlled by the Master like a GPIO and it is falling well before the 1st byte starts the transmission. Only issue is, I cant explain why the first 2 bytes are getting corrupted? Regards, Vineet. ________________ Attachments : Image.jpg : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I0yr&d=%2Fa%2F0X0000000bgW%2Ffl39VYszftfdKiEblHXZy7JMhyuaOGGeGPqp87r74K4&asPdf=false

[Tesla DeLorean]

Posted on December 02, 2014 at 12:58

And where is this signal in the picture being scoped at? The STM32 end, or the far end? What are the GPIO slew rate settings on the STM32 end? Can you shorten the cable significantly? Does that help? What's the spec say about the time from the CS/NSS low until the first clock?

Have you attached a logic analyzer that can see all the signals? If you trigger on the CS low, how does the transaction look?

[waclawek.jan]

Posted on December 02, 2014 at 13:21

Sounds like a runaway pointer to me, rather than SPI problem.

JW

[vineet2]

Posted on December 03, 2014 at 03:18

The probing is done at the STM32 side which is the SPI slave. I will check on the slew rate.

Regarding the shortening of length do you mean the clock or MOSI pin? The NSS in STM32 can be software controlled which is our current setting. So whenever the slave receives a fall edge from the Master, it will internally set the SSI bit. I think the chip select is not an issue here because lowering it from Master side and after a long delay I send the data. As for the slave receiving the chip select, here is how I do it: Set GPIO to 1 on Master and then lower it. Check on slave in debug whether I receive a fall edge. I receive it. Then the master sends the data and the slave recevies it in buffer. I zoomed in on the 1st byte of the MOSI line and found that for the 1st 3 bit periods, the voltage on the MOSI line is around 400mV and then lowers a little. The same thing can be observed for bit no. 10, counting from left. So instead of reading the first 3 bits as zero, it is reading as 1. Please refer the attached file. I have marked the way bits should be read and how they are being read incorrectly. 4 bits are received incorrectly counting from left: 1,2,3 and NOTE: Purple is MOSI with 200mV/div and Blue is SPI clock with 2V/div. Regards, Vineet. ________________ Attachments : Image2_Zoom.jpg : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I0wm&d=%2Fa%2F0X0000000bgV%2FwsXRWJZQxWPaJCWeJSA13iyU0t.oq82iG9g.0.toQag&asPdf=false