NSS pin mode

[JBert.1]

Hello,

I'm using HAL_SPI_Transmit function to transfer two bytes over SPI, NSS pin controlled by SPI module. I noticed that NSS pin is changing state after each transmitted byte. I need that NSS goes low before transmission is started and goes back to high only when both bytes transmitted.

Is that possible?

[waclawek.jan]

Which STM32?

What you describe sounds like NSS Pulse mode, see description of SPIx_CR2.NSSP and the NSS pulse mode subchapter in SPI chapter in RM. Check by reading back the SPI registers, if this bit is set.

I don't Cube, but Cube is open source so you can easily find yourself, how is this bit set.

JW

[JBert.1]

waclawek.jan, thanks for prompt response.

I was searching over several forums, seems i'm not alone facing this problem.

Here is screenshot from my scope using NSS pin controlled by hardware:

Blue curve represents SPI clock, yellow is NSS pin. In my case i'm working with flash chip, to read/write data i need that NSS remains low until both bytes transmitted.

I also tried to use GPIO as output for chip select controlled by software, in this case everything works, but software controlled pin is very slow, even sys.clock is 48Mhz. Here is screenshot:

Is there any suggestions what else to try?

Thank you in advance.

[berendi]

Is there any suggestions what else to try?

• Telling the MCU part number
• Reading the reference manual
• Rewriting SPI handling code without HAL functions

[JBert.1]

Thanks for response, berendi.

MCU is STM32F030C8T6

Do you mean that both delays shown in second screenshot (before and after transmission) caused by HAL function?

[waclawek.jan]

Try yourself - set GPIO pin low by writing into BSRR, then write byte into SPI_DR, wait until SPI_RXNE gets set, read SPI_DR, repeat once more, then set GPIO pin high again.

Observe on oscilloscope the result.

JW

[berendi]

Exactly.

[JBert.1]

Thanks for suggestions.

I tried to use own SPI send/receive function and CS pin controlled by software. Result surprised me, sending 2 bytes took only 6us. Using HAL_SPI function it took 24us.

Thanks a lot, my problem solved.

[berendi]

No surprises here, just look how overcomplicated the HAL functions are compared to your straightforward one.

HAL tries to account for lots of possible uses of a peripheral in one function, your code does exactly what is necessary.

[Piranha]

> HAL tries to account for lots of possible uses of a peripheral

Isn't it ironic that it tries to do everything, but in real life can do nothing. Not even the UART!