SPI input value being interpreted incorrectly

[bnp979]

Posted on January 04, 2015 at 04:11

My project involves using a STM32L152 part as a SPI master that receives data from a slave (digital accelerometer). When I look at the SPI signals through a scope, I notice that the incoming SPI data is being interpreted incorrectly by the L1 device.

I have attached images showing the oscilloscope outputs for two cases where I am finding the error. In each case, the blue signal represents SPI clock and yellow is SPI Data In.In the first case, there are two bytes read from the SPI port (corresponding to 2 sets of 8 clock cycles in the SPI clock). The second byte clearly has ''data in'' line being zero throughout. Yet the data is being read as a 1.Similarly, the second case involves two bytes being read from the SPI port. The second byte is being reported as 0xa, whereas it is should be 0xb (last bit is 1).What I am consistently seeing for these error cases is the LSB being wrongly interpreted as a '1' sometimes when it should be a 0.As part of my SPI settings, the clock polarity is high and clock phase is set to second edge (rising egde).Any inputs are appreciated!-Ben

[Tamas Novak]

Posted on January 04, 2015 at 11:27

You have not mentioned what was read from SPI receive register.

SPI has programmable SCK polarity, clock phase, and LSB/MSB bit order. First JPG seems to be L->H capture. The bits are 00010001 00000000, so bytes should be 0x11 0x00 or 0x88 0x00, depending on the bit order. Seconds snapshot is not 2 bytes, but a single one. Bits are 00010011 that can be interpreted as  0x13 or 0xc8. What did the receive register read? (''0xa'' and ''0xb'' you mentioned are only 4 bits!) If you read inverted (1st case 0xee 0xff, or 0x77 0xff), than you may have inverted implementation where logical data bit ''1'' is 0V on the MOSI and ''0'' is +3.3V. (Seconds case 0xec or 0x37)

[bnp979]

Posted on January 04, 2015 at 20:54

Novak,

Thanks for the reply.The SPI peripheral was configured to read MSB first. And it is true high (0V represents 0).As you noted the second case only shows the problematic byte. Please disregard the first byte read as it is immaterial here. The byte was read as 0x10 (not 10 as I mentioned) whereas you can see that it should read 0x11.The value read from the SPI Data Register for the two cases are the erroneous values I reported i.e. 1 for the first case and 0x10 for the second. I verified this by looking at the SPI register values in my uVision debuger.-Ben

[Tamas Novak]

Posted on January 04, 2015 at 21:08

I think the second case 2nd byte should be 0x13...you meant 0x11..and read 0x10..funny:))

If the SPI transmitter can be ''controlled'' (e.g not measured values sent), try transmitting different values and check if received bytes show some pattern... I have been using SPI on STM32F100 and STM32F429 without any weird things. word length can be set to 8 or 16 bits only....if there is a 7-bit setting, it could cause such thing...or 8/16bit cross-setting at sender/receiver  could receive bad last bits as well?

[bnp979]

Posted on January 04, 2015 at 23:36

The pattern I see is that the last bit is inaccurate (1s get interpreted as 0s and vice versa).

The net result is that the bits 8-15 of the digital accelerometer values being read, which  should always be either 0 or 0xff, sometimes show up as 1 or 0xfe. This obviously throws off the acceleration values considerably.Not sure what's going on with case 2. Seems like I might have noted the values incorrectly. But please look at case 1, as it represents a classic case of what is going on.I am pretty sure it's not a case of either of the sides using 7-bit communication. Clearly, we can see 8 cycles per byte in the SPI clock driven by the uC.This code is actually being ported from the PIC family as our system used to use a PIC24 in our prior version and both sides happily communicated using 8-bit SPI  

[Tamas Novak]

Posted on January 05, 2015 at 17:23

We can see from your recordings that SPI_CLK idle level is H, and

changes MOSI/MISO at CLK H->L edge, so must be sampled at CLK L->H edge by receiver MCU. The STM32F427/429 SPI has a CPHA (clock phase) bit. If CPHA=0 then sampling happens at H->L edge. As this is the moment of MOSI changing, anything can be read. Please check if your MCU has this bit and try to change it at init. ________________ Attachments : spi.jpg : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I0xy&d=%2Fa%2F0X0000000bgL%2F651Nb_giHybvQpEEAs2C.bwr9LotyyZ1FIPWzjrbOj0&asPdf=false