Skip to main content
Joe.H
Joe.H
Associate III
February 2, 2021
Solved

STM32F030C8 SPI transmits 16 bits per DR write instead of 8

  • February 2, 2021
  • 6 replies
  • 1203 views

I don't use CubeMX - I write to all the SPI registers directly.

STM32F030C8

I have SPI1->CR2->DS set as 7 (8 bit data transmit) but the CPU is transmitting 16 bits for each write to the SPI1->DR register.

I verify this using a logic analyzer.

I can't find any other register setting that affects the number of transmit bits so I'm very puzzled as to this behavior.

Any insights to get only 8 bits transmitted?

Thanks

This topic has been closed for replies.

6 replies

KnarfB
KnarfBBest answer
Super User
February 2, 2021

Same as last week: https://community.st.com/s/question/0D53W00000Wb3cBSAR/sending-one-byte-via-spi-stm32g474

Joe.H
Joe.HAuthor
Associate III
February 2, 2021

0693W000007DhBpQAK.pngThanks - I was looking at other posts that suggested changing to a union in the SPI typrdef but your suggestion was much better. I implemented suggestion and it addressed the byte transmit size but produced a delay and artifacts that are disturbing. The SPI process activity is extended beyond the transmission of the intended bytes - actually delaying operation also.

0693W000007DhBuQAK.png 

0693W000007DhBzQAK.png 

I've expanded the Artifacts to show MOSI and Clock activity.

The second SPI activity was a single write command then read 3 bytes. You can see the SPI delayed between acquiring the second and third byte and also generated an artifact.

I am controlling the SPI chip select directly with GPIO- that is why you see the CS go inactive before the SPI completes with the artifact generation.

Any comments/help?

Thanks

KnarfB
KnarfB
Super User
February 3, 2021

Doesn't look like that this is related to the DS assignment. Hard to tell what happens without seeing the code. Could the lines be in HiZ mode (disabled?) or weak signals at the probes. Looks more like random noise than SPI related...

Joe.H
Joe.HAuthor
Associate III
February 3, 2021

I figured out the delay. I poll SR once in the interrupt routine - processing receive prior to transmit. The delay is just process time between acquiring data once the fifo is empty. On the artifacts - the device I am writing/reading from is a serial flash memory device which would make the MISO go HI Z when the CS goes HI. But the artifacts are on the SPI MOSI and clock line which (I believe) are being driven (not HI Z) until the SPI is disabled. I disable the SPI just after setting CS HI - but you can see it takes the SPI over 7 usec to actually disable as shown when the clock returns to it's steady state LO. Thoughts?

waclawek.jan
waclawek.jan
Super User
February 3, 2021

Strip down your code to minimum but complete, compilable example exhibiting the problem, and post.

JW

waclawek.jan
waclawek.jan
Super User
February 3, 2021

> but you can see it takes the SPI over 7 usec to actually disable as shown when the clock returns to it's steady state LO.

Hi-Z means, there's nothing driving the pin. What you see is time until some parasitic leakage discharges the parasitic capacitance of the given track to the threshold of the LA's input.

JW

Terms & ConditionsAccessibility statement