SPI Master NSS always low in STM32F4

[Andres Cao]

Posted on March 03, 2017 at 12:34

Hi guys!

I'm configuring the Nucleo 64 with the STM32F446RE to use SPI as a Master.

The problem I'm having right now is that the NSS pin is always low. Clock and MOSI are perfect. What I would like is that the NSS is high, and goes low during the transmission, then high again.

I've tried setting the NSS as Hardware output, and Software in Cube, but still failed to get what I want. 

I think this configuration should be sorted with the following 3 bits, from CR1 and CR2. Right now Cube is setting SSOE= 1, SSM=1, SSI=1. And the NSS pin is configured as hardware output in Cube. 

Any clues on how should I setup this? I would like to avoid having to use a random pin as CS and pull it manually.

Thanks!!

[Andres Cao]

Posted on March 03, 2017 at 15:52

Hey Nemui. Tried it but I still get nothing.

[waclawek.jan]

Posted on March 03, 2017 at 22:28

But most of the SPI slaves need the CS edge to trigger (capture) the internal shift register to memory.. so you need to trigger the CS even though you might be sending 100 bytes.

I know. The designer of the STM32 SPI module did not know. Why are you so surprised? Chipmakers employ mere people, no superheroes. It annoys me too, and then what. Move along, nothing to see here.

But I'm still curious, because even though SPE=0, NSS stays low. 

I don't have an 'F4 at hand now but I guess it goes Hi-Z. Try to swich on a pullup on it.

JW

[Tesla DeLorean]

Posted on March 03, 2017 at 23:16

>>I know. The designer of the STM32 SPI module did not know. Why are you so surprised? Chipmakers employ mere people, no superheroes. It annoys me too, and then what. Move along, nothing to see here.

Sometimes I think they employ interns with no practical experience programming peripheral hardware, and see minimal gate count as a priority over functional usefulness. Some places employ geniuses who can actually design and test complex logic, and have it work first time around, worked with some in the 80's and 90's, with a lot better cross-discipline understanding of where optimum balance of functionality vs gate count was located. I'm sure ST has some of them too, one of the MEMS guys is awesome, but they were probably weren't on the initial STM32 team when some of the design choices were baked in.

I like the STM32 a lot, but there is a bunch of brain damaged design in some of the peripherals and clocking, I live with it.

[Tesla DeLorean]

Posted on March 04, 2017 at 02:05

Just to add a little context, once you've committed an idea to silicon it is very disruptive to change that in subsequent releases/revisions. The STM32 families have been kept very consistent, and you don't have to check steppings to deal with dozens of anomalies.

[Jaroslaw Hill]

Posted on July 16, 2017 at 04:56

Hi,

I had to face the same problem, but on the STM32F105, SPI master + DMA and hardware NSS.

Before I had found the issue it looked like this

After reading the discussion I realized that disabling the SPI in DMA callback resolves the issue.

static void SpiCallback(SPI_HandleTypeDef *hspi)

   {    __HAL_SPI_DISABLE(hspi); // disable NSS   };

void HAL_SPI_ErrorCallback(SPI_HandleTypeDef *hspi)

   { SpiCallback(hspi); };

void HAL_SPI_TxRxCpltCallback(SPI_HandleTypeDef *hspi)

   { SpiCallback(hspi); };

void HAL_SPI_TxCpltCallback(SPI_HandleTypeDef *hspi)

   { SpiCallback(hspi); };

After that transmission looks like this.

I hope it will help you.

[Bill Finger]

Posted on August 10, 2017 at 15:13

Pullup worked, thanks!  I wish the documentation had indicated HiZ...

[Vangelis Fortounas]

Posted on August 10, 2017 at 17:23

Hello to all!

It is not writen in any RM or DS  that NSS pin in Master mode,  is responsible to control the CS of a slave device and to provide the necessary timing for this!

It is very clear also, in Master mode, that  NSS pin is kept low when master enabled  until the master is disabled.

So this is not a problem.  is the normal behaviour of SPI Master NSS pin.

When a Master  keep the NSS pin low in a multi device bus , this means  that all devices (with same NSS functionality) will be forced to act as slaves and will not try to act as Masters.(if properly configured for this ofcourse).

When  the Master  frees the NSS line, informs the bus that any other device can take the control of the bus as a new Master by forcing his  NSS pin low.

Conclusion. If you want to have one Master on the bus , and only slave devices , inside Master's device the NSS functionality is useless and the GPIO can be used as an ordinary pin.

[Georgi Marinov]

Posted on June 12, 2018 at 15:00

Hello. I had the same problem with stm32l0. When you use hardware NSS (on master). 

1. SPI_CR2_SSOE = 1

2. Hal lib always enable SPI on transfer. So you should disable SPI when finish transfer (__HAL_SPI_DISABLE)

3. Set pullup for NSS gpio pin in GPIO_PUPD

This setup work for me.

[BCoch]

THis tripped me up for a while too. Even when the STM32F is set to be the bus master, with HW NSS, the STM32F drives it low, but doesn't drive it high when not selected! Thus if you start out looking at the NSS pin, it looks like nothing's happening.

Unless there is some configuration I missed, the pin must be independently pulled up, either externally, or via the internal GPIO pull-up. (Which is too weak to allow rapid consecutive SPI transactions.)

[waclawek.jan]

> Even when the STM32F is set to be the bus master, with HW NSS, the STM32F drives it low,

> but doesn't drive it high when not selected!

By "not selected", you mean that you set SPI_CR1.SPE=0? Try toggling that bit, i.e. clear it, then immediately set it again.

JW