SPI last bit spoilage

[oscar_fridman]

Posted on December 25, 2011 at 17:34

Hello

I'm using stm32f103 controller and via SPI trying to read data from EEPROM Microchip 25LC080B. The problem I deal with, is last bit corrupting when reading from eeprom, sometimes 0->1 and sometime 1->0, I've verified with scope. I assune writing to eeprom is OK becasue i got a response. Thats how I'm initializing SPI port {   SPI_InitTypeDef SPI_InitStructure;   SPI_StructInit(&SPI_InitStructure);   SPI_Cmd(SPIx, DISABLE);     SPI_I2S_DeInit(SPIx);   /* SPIy Config */   SPI_InitStructure.SPI_Direction = SPI_Direction_2Lines_FullDuplex;   SPI_InitStructure.SPI_Mode = SPI_Mode_Master;   SPI_InitStructure.SPI_DataSize = SPI_DataSize_8b;   SPI_InitStructure.SPI_CPOL = SPI_CPOL_High;   SPI_InitStructure.SPI_CPHA = SPI_CPHA_2Edge;   SPI_InitStructure.SPI_NSS = SPI_NSS_Soft;   SPI_InitStructure.SPI_FirstBit = SPI_FirstBit_MSB;   SPI_InitStructure.SPI_BaudRatePrescaler = SPI_BaudRatePrescaler_256;    /* Configure SPI */   SPI_Init(SPIx, &SPI_InitStructure);   /* SPI enable */   SPI_Cmd(SPIx, ENABLE);  } Thanks #spi-stm32f103

[Tesla DeLorean]

Posted on December 25, 2011 at 18:02

Thinks to check:

That the SPI clocking parameters are correct. ie latching on correct edge. That the chip select remains active (presumably low) until some period after the last bit exits the STM32, so waiting on Transmit Complete, Not Transmit Register Empty, then on Receive Not Empty. If waiting on RXNE, make sure it is cleared prior to the last null/junk byte sent out.

[oscar_fridman]

Posted on December 25, 2011 at 20:54 CPOL and CPHA verified. CS going low and stays there until end of all transmitions (as in datasheet) At the begining I've waited on SPI_I2S_FLAG_TXE event, but now I also perform busy wait. I'm verifying on scope that new clock starts only after previous ends. I'm the only master. I've put scope after all buffers and line translators at STM pin ,  clock is pretty slow (about 400KHz) and MISO signal looks nice

[domen23]

Posted on January 03, 2012 at 15:19

 As clive said, you should wait on RXNE.

[stepanovr]

Posted on June 16, 2016 at 01:45

I have the same behavior on STM3F429 SPI1. Sometimes the last bit (reading SPI) disappears (became 0 instead of 1). That happen randomly, but if I connect a scope probe to clock signal then the bit became stable 0. The bit RXNE is set at the reading received data moment.

[Tesla DeLorean]

Posted on June 16, 2016 at 02:00

If losing data from a slave watch very carefully where CS/SS is collapsing wrt the issue.

[stepanovr]

Posted on June 16, 2016 at 03:36

Thank you for a quick response.

Unfortunately I didn't understand your message.

[Tesla DeLorean]

Posted on June 16, 2016 at 04:16

Ok, so as the -ChipSelect goes high the slave will tri-state its output. So a) make sure you keep -CS low until you have clocked in the last bit, and b) you are reading the slave output on the right edge of the clock

What SPI device is the slave?

[stepanovr]

Posted on June 16, 2016 at 22:06

Thank you for  response.

First: CS starts going high one microsecond after the last clock transaction. Second: In order to simplify the test I managed to neutralize the slave peripheral holding reset all the time. MISO output is a solid high and never changes. I read 0xFE instead of 0xFF. The same firmware operates with the same peripheral on SPI2. No problems observed. I got the same behavior on two different boards for SPI1 only. SPI2 connected to the same kind of slave (si3050 as dazy chain of 5) operates properly on both boards.

[waclawek.jan]

Posted on June 17, 2016 at 08:52

This is a recurrent problem, with around a dozen threads on this forum, which was never completely investigated down to the root - but I am afraid it can't be without active involvement of ST.

It might be related to the sequencing of the very first SCK clock after enabling the peripheral, i.e. whether the SCK line was in active or inactive state from the point of view of CPOL just before enabling the peripheral or so. I've seen issues of a similar nature although not quite the same, when changing CPOL/CPHA on-the-go without stopping/restarting the peripheral (it's lots of fun to find out what's going on, I can recommend it as a weekend project ;) ). Also, one friend of mine discovered, that the SPI receiver is driven from the pin directly rather than from an internal signal (i.e. when no pin was not set as SPI-SCK AF, the receiver did not work at all). I can't quite explain how could it be more specific to SPI1 - either through different parasitics, or different source clock (different APB)? https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=https%3a%2f%2fmy.st.com%2fpublic%2fSTe2ecommunities%2fmcu%2fLists%2fcortex_mx_stm32%2fStrange%20reading%20over%20SPI&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B&curren...