STM32F051xx SPI problem

[bwang_bd]

Posted on February 28, 2014 at 16:10

Hello Everyone,

I'm using STM32F051xx to communicate with a SPI slave deivce. I found a problem that between two byte SPI clocks, there is a gap. And in the gap the state of MOSI line is always zero but is not the last bit value of previous byte. The slave device needs the MOSI value in the gap can keep the last bit value of previous sent byte. I learned its Reference Manual. But I didn't find any relative settings.  Thanks for any reply.Bing. #spi #stm32f051xx-spi

[chen]

Posted on February 28, 2014 at 16:23

Hi

Do you have CPOL or CPHA set (clock polarity with respect to data)?

[bwang_bd]

Posted on February 28, 2014 at 17:23

Yes. I have set the leading edge to sample data lines (CPHA = 0) and set clock to low when idle (CPOL = 0). The slave device requires both CPHA and CPOL are equal to 0.

Can the 2 bits setting lead the MOSI to be low during the clock gap?Thks.

[chen]

Posted on February 28, 2014 at 17:50

Hi

I do not think you understand : http://en.wikipedia.org/wiki/SPI_bus ''the master must also configure the clock polarity and phase with respect to the data. Freescale's SPI Block Guide

http://en.wikipedia.org/wiki/SPI_bus#cite_note-2

names these two options as CPOL and CPHA respectively, and most vendors have adopted that convention.'' ie CPOL and CPHA are 2 different modes entirely ''

• At CPOL=0 the base value of the clock is zero
  • For CPHA=0, data are captured on the clock's rising edge (low→high transition) and data is propagated on a falling edge (high→low clock transition).
  • For CPHA=1, data are captured on the clock's falling edge and data is propagated on a rising edge.
• At CPOL=1 the base value of the clock is one (inversion of CPOL=0)
  • For CPHA=0, data are captured on clock's falling edge and data is propagated on a rising edge.
  • For CPHA=1, data are captured on clock's rising edge and data is propagated on a falling edge.''

''The slave device needs the MOSI value in the gap can keep the last bit value of previous sent byte.'' I think, if the SPI peripheral is correctly configured, the data line should stay at the last value until the start of the next transmission. Is the code writing to any of the SPI control register in between each byte transmission?

[jpeacock2399]

Posted on March 01, 2014 at 00:37

I do not think you understand :

• For CPHA=0, data are captured on the clock's rising edge (low→high transition) and data is propagated on a falling edge (high→low clock transition).
• For CPHA=1, data are captured on the clock's falling edge and data is propagated on a rising edge.

Data is clocked on edges, not levels.  Your SPI device should be looking at the MOSI data bit on the clock edge, not as a level when the clock is idle.  How does your SPI device know when MOSI data is valid if it doesn't look at the clock edge?  The state of the MOSI line is only important at the clock edge when data bit is latched.   Jack Peacock

[bwang_bd]

Posted on March 01, 2014 at 02:56

Hi Jack and sung.chen_chung,

Thanks for your help. I'm sorry I didn't explain why the SPI slave deivce need the MOSI to keep the last bit value of previous sent byte. The reason is:The SPI slave has two SPI operation (read and write). Both the 2 operations are designed as half-duplex communication way. And for writing operation, master needs to set MOSI line to high before select the device by pulling CS line down. And the MOSI line must keep high at least 100ns after the CS line is pulled down. This indicates the SPI slave deivce the transcation is for writing operation.And for reading operation, master needs to set line to low before select the deivce by pulling CS line down. And the MOSI line must keep low at least 100ns after the CS line is pulled down. This indicates the SPI deivce the transcation is for reading operation.To satisfy the slave device requirements, I set the CS line to be managed manually but not by hardware on MCU side. And I send 0xFF using SPI hardware and then pull CS line down to indicate the slave device the MOSI line is high. And in the same way, I send 0x00 using SPI hardware and then pull CS line down to indicate the slave deivce the MOSI line is low.But the in the clock gap, the MOSI line cannot keep the last sent bit of previous byte. This is why I new the post.In addition, the slave device cannot be configured again because it is a device that cannot be programmed.From: Jack PeacockPosted: Saturday, March 01, 2014 12:37 AMSubject: STM32F051xx SPI problem

I do not think you understand :

• For CPHA=0, data are captured on the clock's rising edge (low→high transition) and data is propagated on a falling edge (high→low clock transition).
• For CPHA=1, data are captured on the clock's falling edge and data is propagated on a rising edge.

Data is clocked on edges, not levels.  Your SPI device should be looking at the MOSI data bit on the clock edge, not as a level when the clock is idle.  How does your SPI device know when MOSI data is valid if it doesn't look at the clock edge?  The state of the MOSI line is only important at the clock edge when data bit is latched.  Jack Peacock

[bwang_bd]

Posted on March 01, 2014 at 15:23

Hi All,

I have solved this problem. Before sending 0xFF, I set the Frame Format to SPI TI Mode in SPIx_CR2 register. Then pulling down CS line. At last, I set the Frame Format to SPI Motorola Mode. By this way, the last bit of 0xFF keeps until the SPI format is set to SPI Motorola format. Similarly, the last bit of 0x00 keeps until the SPI format is set to SPI Motorola Mode.Maybe the method is not regular. But it indeed solved my problem.Thanks again for all of you.