SPi communication in stm32f407vgtx board

[Ash1]

Hi all

I am working with SPI1 on stm32f407vgtx and issue what I am, facing my NSS which internally controlled by SPI is taking more time for goes high even CLOCk has been stopped . my configuration are SPI full duplex 16 bit data clock is 2.6MHZ after prescaled I am transmitting on spi every 10ms task. Please check the screenshot of logic analyzer for further understanding .

Note: in the end I have disabled SPE bit  before checking TXE and busy flags.

[Ash1]

Hi TDK and Andrew,

Thank you for information and support.

The slave device I intend to use needs to use requires CS to toggle with each SPI Command [16 bit length]. The Requirement is to use Peripheral controlled CS hence I cannot use GPIO.

During Transmission we are able to observe the Data correctly over MOSI. Currently Default 0xFF on MISO as Slave is not connected.

The issue we see is additional ~1.5 us is taken by SPI controlled CS to go to High after Clock stops.To make CS high SPI is disabled via bit SPE =0 in CR1 after TXE = 1 and BSY= 0

• Is this intended behavior??
• Why additional time needed and what is the functionality executed in this period?
• Is there any default Setup Delay or Hold Delay implemented as SCI Clocks stops 1.4us before the SCI is High?

[Ash1]

Duplicate - merged.

---

Hi all

The slave device I intend to use needs to use requires CS to toggle with each SPI Command [16 bit length]. The Requirement is to use Peripheral controlled CS hence I cannot use GPIO.

During Transmission we are able to observe the Data correctly over MOSI. Currently Default 0xFF on MISO as Slave is not connected.

The issue we see is additional ~1.5 us is taken by SPI controlled CS to go to High after Clock stops.To make CS high SPI is disabled via bit SPE =0 in CR1 after TXE = 1 and BSY= 0

• Is this intended behavior??
• Why additional time needed and what is the functionality executed in this period?
• Is there any default Setup Delay or Hold Delay implemented as SCI Clocks stops 1.4us before the SCI is High?

Note : Please check once the image that I have shared.

B.R

Ash

[waclawek.jan]

The SPI hardware does not set NSS (CS) high actively.

If you use Cube/HAL, it probably disables SPI entirely (by clearing SPIx_CR.SPE) after transmission. This threestates the SPI pins, i.e. does not pull them up actively, although you mayu have enabled internal pullups on the NSS (CS) and SCK pins.

You can try to set the NSS (CS) pin to GPIO output and control it in software to generate the required framing, but again if you rely on Cube/HAL, the software overhead of it may prevent you to act quickly enough.

JW

[Andrew Neil]

---

@Ash1 wrote:

The Requirement is to use Peripheral controlled CS hence I cannot use GPIO.

---

Why is that a requirement?

The slave device neither knows nor cares how the CS signal is driven - just that it works as required.

---

@Ash1 wrote:

• Is this intended behavior??

---

As @waclawek.jan suggests, the defined behaviour is that CS stays low until the SPI is disabled:

https://www.st.com/resource/en/reference_manual/rm0090-stm32f405415-stm32f407417-stm32f427437-and-stm32f429439-advanced-armbased-32bit-mcus-stmicroelectronics.pdf#page=880

via: https://www.st.com/en/microcontrollers-microprocessors/stm32f407zg.html#documentation

---

@Ash1 wrote:

• Why additional time needed and what is the functionality executed in this period?

---

the delay you're seeing is probably the time that it takes to disable the peripheral.

At zero optimisation (which is the default for the STM32cUBEide Debug configuration), stuff can be very slow - especially HAL stuff.

So what optimisation level are you using?

It may or may not be quicker to manage the CS "manually" using HAL calls (also subject to optimisation, of course).

It probably would be quicker to do it via direct register access.

[TDK]

Duplicate:

SPi communication in stm32f407vgtx board - STMicroelectronics Community

---

Now merged.