[Possible hardware bug] Full duplex SPI incorrectly reads last bit of each incoming byte

[pierre23]

Posted on June 05, 2016 at 01:54

Hi,

I need two STM32 to communicate with each other and unfortunately I only have a SPI bus available. Hence, I decided to set up a test between two ST boards (one STM32F429 Disco and one STM32F4 Discovery). The 429 is the master and the 407 is the slave. After many hours of debugging, here is my current situation:  - I can transmit data from the master to the slave using DMA and it is correcty received by the slave (also using DMA)  - at the same time, the master indeed receives data from the slave but it is not correct And it's pretty weird. Usually, my bytes have their last bit flipped. For instance, 0xFF will be come 0xFE and 0x52 will be come 0x53. However, depending on the sequence of bytes, sometimes one byte will be ok (but only for this sequence, and no matter how many times you send this exact sequence). Has anybody ever faced something like this? I came accross a similar issue on this forum but it affected the whole bus, in my case it's only the MISO pin. Speaking of which, in order to make the MOSI pin work, I had to set the GPIO speed for SPI CLK and SPI MOSI as low. When their speeds were high,  the slave would receive incorrect data. I figured setting the GPIO speed low would act as a low pass filter and reduce oscillations caused by switching GPIO pin. It sounds a bit extreme, but it worked (well, maybe for an other reason, though, I don't know), but it doesn't work for the MISO pin, no matter which configuration of GPIO speeds I choose. I hit rock bottom and at that point alternative ideas would be very much welcome. Thanks for your help and experience sharing. #stm32f4-spi-hal-bug

[TDK]

Posted on June 05, 2016 at 05:38

The issue with different speeds for different pins suggests something else is is amiss.

What speed are you running the bus at?  What happens when you use a much lower speed?  Are phase and edge settings between the chips the same?  Have you viewed the bus on a scope to ensure there isnt a ringing or noise issue?

[pierre23]

Posted on June 05, 2016 at 13:12

I'm running it at lowest speed (256 prescaler with sysclock of 168 MHz so I'm at ~168 ko/s). The transmission works up to a prescaler of 16.

The phase and edge settings are the same (the MOSI transmission wouldn't work either, otherwise). Yes I have a 60 MHz scope and I don't see any particular noise. Also, what is transferred on the MISO pin is correct, it is just incorrectly read by the master stm32.

[pierre23]

Posted on June 07, 2016 at 18:30

Here are the results of some tests with different discovery boards. In the left column, they are in master mode, in the right column, they are in slave mode. I indicated whether each board works in each case.

f407 = STM32F4-DISCOVERY f429 = STM32F429I-DISCO f746 = STM32F746G-DISCO

Master

 Slave

 f429

 

f407

f407

 

f429

 f746*

 

f407

f407

 

f746

f746

 

f429

f429

 

f746

Green means that data were correctly received (tested with a 256 byte-long buffer). Red means that data were incorrectly received, but that SPI transfer completed successfully. Note that in the special case (*), SPI transfer didn't even complete...There might be a hardware bug on the stm32f429, although I find this very unlikely. Also, before you ask, yes, I used a SPI peripheral without any IC connected to it (SPI4, precisely). (Edit: I recall using SPI3 and SPI5 also and MISO still didn't work, so maybe the bug is located in HAL drivers. I don't know. I can test again if needed anyway.) At this point I don't know what to think. I'm just exasperated by this mess.

[TDK]

Posted on June 07, 2016 at 23:46

Yeah that's a little frustrating.  I don't really have much else input to add.

I will say that I'm using the SPI1 peripheral in both master and slave mode on a STM32F429 chip using the latest HAL drivers and haven't encountered what you're encountering.I am seeing some other odd behavior but haven't investigated it quite enough to say it's not a bug in my code.

[waclawek.jan]

Posted on June 09, 2016 at 20:44

Post a photo of your setup.

JW

[dawid]

Posted on September 01, 2016 at 00:45

Hi,

I'm having the same problem with an STM32F407 (stm32f4-discovery board). I'm communicating LSB first, and the MSB is often read incorrectly. It does not seem to be random, I always have the error in the same place when reading specific data from a slave device. I have verified this with an oscilloscope, there is no significant noise, and the bit is electrically correct, but incorrect when in the data register. It does not occur on every byte received, and the error occurs both for 1 and 0 bits.Anybody have any clue on this?Regards,Dawid

[dawid]

Posted on September 01, 2016 at 01:02

Problem resolved (underlined the workaround). STM32F40x and STM32F41x silicon limitations, section 2.4.13:

LSB bit of data or CRC calculation can be corrupted for the receiveddata in master mode depending on the timing of the feedbackcommunication clock respect to the APB clock (SPI or I2S)DescriptionWhen the SPI or I2S is configured in master mode (in full duplex or receiver mode, readingback the data register or CRC enabled), the data received may have the last transacted bitcorrupted if delay of internal feedback derived from SCK pin is comparable with APB clockperiod. The last bit value is strobed too late into the shift register, while its content has beenalready either copied into the data register or compared with CRC pattern calculatedinternally. In case of data corruption, the bit position in the data register contains the value ofthe last bit received during the previous data transfer and CRCERR flag is asserted in spiteof all the data being received correctly.The main factors which can contribute negatively to the delay are decreased Vdd level,extreme temperature, high SPI bus capacity load and low SCK IO output speed. SPIcommunication speed has no impact.Workaround• Decrease the APB clock.• Set the IO pad configuration for the SCK pin to be faster.• Ignore the lastly transacted bit value

[waclawek.jan]

Posted on September 05, 2016 at 08:28

From other threads dealing with the topic it appears that this occured only when SCK drive (as set by GPIO_OSPEEDR) was set to lowest, and increasing it to higher than lowest helped in all those cases where the poster reported back. That corresponds to the second recommendation from mentioned erratum. Of course this relates also to the capacitance loading that pin, i.e. your application/board/connected devices.

For example https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=%2Fpublic%2FSTe2ecommunities%2Fmcu%2FLists%2Fcortex_mx_stm32%2FStrange%20reading%20over%20SPI&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B&currentviews=148 Please try and share your findings. JW