Skip to main content
Brian H
Senior
October 30, 2024
Solved

STM32F105xx SPI2 Does Not Drive NSS Pin High when Idle

I'm using the ST Cube environment (IDE + MX) to configure the SPI2 peripheral in Full-Duplex Master mode on a STM32F105VBHX chip.

It seems like the peripheral is not driving the NSS (chip select) pin (PB12).  When the pin is selected for SPI2_NSS and the peripheral is configured with the "Hardware NSS Output Signal", no signal is driven on that pin when the SPI peripheral is clocking data.  Instead, it is held low constantly.

If I configure that pin as GPIO, I can drive it with code just fine, which is what I am doing to get around the problem for now.  However, that is also problematic because I can't seem to depend on the HAL_SPI_TxCpltCallback and/or HAL_SPI_RxCpltCallback methods always getting called when a transaction completes.  Of course, this means some time is wasted.

I don't see any references to SPI2 NSS in the silicon errata that apply to my situation (I am not using USART3 at all, and not using the CRC peripheral in tandem with SPI).  

What could be causing the SPI2 peripheral to not drive NSS high when idle?

This topic has been closed for replies.
PGump.1
PGump.1Best answer
Senior II
October 31, 2024

Hi,

The NSS output in Master mode is a dud - it only half works :-

Screenshot_20241031_122905.png

I hope that helps...

Kind regards
Pedro

AI = Artificial Intelligence, NI = No Intelligence, RI = Real Intelligence.

8 replies

AScha.3
Super User
October 30, 2024

> What could be causing the SPI2 peripheral to not drive NSS high when idle?

F10x have no (automatic working) NSS hardware, you can set it only by (your) software.

Or set SSI on and off, but anyway you have to do it in software.

AScha3_0-1730318975146.png

 

If you feel a post has answered your question, please click on " Best Answer ".
Brian H
Brian HAuthor
Senior
October 30, 2024

That's not true at all.

From DS6014:

BrianH_0-1730319372011.png

From RM0008:

BrianH_1-1730319506548.png

You're pointing to the SSM and SSI bits, which affect the behavior of NSS in slave mode.  In slave mode, NSS is an input.  I am using the peripheral in master mode, in which NSS is an output.  Furthermore, SSM controls whether the peripheral pays attention to the hardware NSS pin (SSM = 0) or the SSI bit (SSM = 1).  

I realize my original post didn't specify master mode.  I've corrected that omission.

Brian H
Brian HAuthor
Senior
October 30, 2024

Reading further in RM0008, I see: 

BrianH_1-1730320693431.png

I've already encountered some odd behavior in my code where certain callbacks are not being called reliably from the HAL layer.  It could be that the code in the HAL layer that disables SPI after a transaction is also not being called reliably.  I'm not sure why those calls aren't happening but I suspect some kind of timing or interrupt priority issue with my code, because it changes based on whether I have certain breakpoints set.

If I can figure out why the callbacks aren't getting called, maybe that will also solve my NSS problem.