STM32F4 SPI, Weird signals on the MOSI/MISO lines

upgrdman · ‎2012-10-21

Posted on October 22, 2012 at 01:12

The original post was too long to process during our migration. Please click on the attachment to read the original post.

stm32forum · ‎2012-10-22

Posted on October 22, 2012 at 09:32

You need push-pull for SPI communication, rise time with pull up/down is to slow for the SPI speed

.

waclawek.jan · ‎2012-10-22

Posted on October 22, 2012 at 12:50

In C, the == operator has higher precedence than the binary & operator, thus for example

while(SPI1->SR & SPI_SR_TXE == 0)

;

is evaluated as

while(SPI1->SR & (SPI_SR_TXE == 0))

;

and as SPI_SR_TXE is a non-zero literal, this expression evaluates as a permanent zero (false), thus the while is never looped (there is a side effect of reading the SPI1->SR register once, as it's volatile).

I doubt this is what you wanted.

A minor issue is that main() ought to have a parameter (void).

JW

upgrdman · ‎2012-10-22

Posted on October 23, 2012 at 05:12

JW: Thanks! That fixed the MOSI problem, now the MCU is outputting data as expected. Input still doesn't work :(

Edje: I turned on the pull-downs because that is how STM did it in their demo firmware. I turned them off (no pull-down or pull-up) and the MISO line stays high, even while holding down the reset button.

-Farrell

waclawek.jan · ‎2012-10-22

Posted on October 23, 2012 at 08:53

Try a loopback test first - disconnect MISO from the accelerometer and connect it to MOSI. That could highlight potential setup problems.

JW

upgrdman · ‎2012-10-28

Posted on October 28, 2012 at 20:27

I wasn't able to do that since it's soldered to the F4Discovery board, and its an LGA package. After lots of poking around I finally solved the problems:

1. STM has a typo in the F4Discovery User Manual. (UM1472, p.28) They list CS as being on PE2, but it's actually PE3.

2. It seems the CS line must go high between each ''transaction'' (not sure if that is the correct word), but not between each byte. I was under the impression you could just leave it low the whole time. I had an SPI LCD where CS was permanently low (done on the PCB) and didn't know some devices need CS to be high at certain times.

-Farrell

waclawek.jan · ‎2012-10-29

Posted on October 29, 2012 at 09:28

> 1. STM has a typo in the F4Discovery User Manual. (UM1472, p.28) They list CS as

> being on PE2, but it's actually PE3.

Thanks for reporting that here. You might also perhaps submit it to ST through a support request (https://my.st.com/onlinesupport ), as this forum appears not to be monitored by ST personnel at the moment.

> 2. It seems the CS line must go high between each ''transaction'' (not sure if that is the

> correct word), but not between each byte. I was under the impression you could just

> leave it low the whole time. I had an SPI LCD where CS was permanently low (done

> on the PCB) and didn't know some devices need CS to be high at certain times.

Unfortunately, there's no firm SPI standard and the behaviour of ICs with this interface differs wildly from chip to chip. This is a quite common case where the CS line serves as sort of a latch or ''confirmation'', but there are other schemes around, too. The corollary is, to read the fine datasheet in each and every case... 🙂

JW

Amel NASRI · ‎2013-02-28

Posted on February 28, 2013 at 17:42

''STM has a typo in the F4Discovery User Manual. (UM1472, p.28) They list CS as being on PE2, but it's actually PE3.''

Thanks for reporting!

Your feedback will be taken into account in coming release of the user manual (don't ask me by when exactly :-)).

Best Regards,

ST.MCU

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.