Skip to main content
FAJOL.1
Associate II
September 18, 2024
Solved

Chip Select of SPI in Nucleo F401RE stuck low

  • September 18, 2024
  • 1 reply
  • 4521 views

Hi guys,

 

I m having an issue with my Nucleo F401RE. I m porting a code based on the use of SPI2 that worked very well on Nucleo G431RB. I made same setting on Nucleo IDE (see picture).

SPI Setting.jpg

 

After inizialization of periperhals NSS (Chip Select) goes to high and everithing seems to work fine until the first transmission:

 

 

 

void SPI_TX_16b(uint8_t* pdata){

	HAL_SPI_Transmit(&hspi2, (uint8_t*) pdata, 1, HAL_MAX_DELAY);

};

 

 

 

Then the NSS goes down and stucked there forever. In the picture (yellow is clk, green is data out, and violet is nss). 

 

Any ideas?

 

Thanks

 

scope_1.pngscope_0.png

Best answer by TDK

Don't use the hardware NSS pin on the STM32F4, it's not driven like a CS pin. It will always be low when the peripheral is active. Instead, initialize it as a GPIO output and manually set it low before transmission, and high afterwards.

 

1 reply

TDK
TDKBest answer
September 18, 2024

Don't use the hardware NSS pin on the STM32F4, it's not driven like a CS pin. It will always be low when the peripheral is active. Instead, initialize it as a GPIO output and manually set it low before transmission, and high afterwards.

 

"If you feel a post has answered your question, please click ""Accept as Solution""."
FAJOL.1
FAJOL.1Author
Associate II
September 18, 2024

ok fine. 

 

But why the IDE mentions "hardware NSS output signal" if Chip select is not automatically managed? In G431RB used to work automatically

 

Thanks

TDK
September 18, 2024

Different chips have different SPI peripherals and they behave differently. This is how it behaves on the STM32F4.

Why? Who knows, but newer chips behave differently so it feels like they recognized the issue. Just what it is. Keeping CS low is sometimes not a problem.

"If you feel a post has answered your question, please click ""Accept as Solution""."