Skip to main content
Graduate II
October 30, 2024
Solved

STM32F105xx SPI2 Does Not Drive NSS Pin High when Idle

  • October 30, 2024
  • 2 replies
  • 2535 views

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.
    Best answer by PGump.1

    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

    2 replies

    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

     

    Brian HAuthor
    Graduate II
    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 HAuthor
    Graduate II
    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.