2024-10-30 12:17 PM - edited 2024-10-30 01:23 PM
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?
Solved! Go to Solution.
2024-10-30 06:35 PM
Hi,
The NSS output in Master mode is a dud - it only half works :-
I hope that helps...
Kind regards
Pedro
2024-10-30 01:10 PM - edited 2024-10-30 01:13 PM
> 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.
2024-10-30 01:23 PM
That's not true at all.
From DS6014:
From RM0008:
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.
2024-10-30 01:40 PM
Reading further in RM0008, I see:
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.
2024-10-30 02:02 PM - edited 2024-10-31 12:01 AM
Hello @Brian H ,
The NSS pin can be configured in hardware or software mode. In hardware mode, the SPI peripheral controls the NSS pin automatically. In software mode, the NSS pin is controlled by the software.
In master mode, the NSS pin can be used to indicate the start and end of a communication frame. The master can drive the NSS pin low to start communication until SPI is disabled.
In slave mode, the NSS pin is typically driven by the master to indicate when the slave should listen for incoming data.
The behavior of the NSS pin is controlled by the SPI control registers (SPI_CR1 and SPI_CR2). Specific bits in these registers determine whether the NSS pin is managed by hardware or software and whether it is used for input or output.
May be your issue could be due to the configuration of the SPI_CR1 and SPI_CR2 registers. So, make sure that the SSM and SSI bits are configured correctly.
Also, make sure the SPI peripheral is correctly configured and setting the appropriate bits in the SPI control registers to ensure the NSS pin is driven high when no communication.
Note that for hardware NSS management, the SSM bit should be cleared, and the NSS pin should be configured as an output.
2024-10-30 06:35 PM
Hi,
The NSS output in Master mode is a dud - it only half works :-
I hope that helps...
Kind regards
Pedro
2024-10-31 12:26 AM
As I told you: the F10x has no NSS hardware.
You have to do it in software.
Whether you prefer to just set/reset a pin or disable the spi to toggle one bit - is up to you.
So the NSS hardware in this chip is just a pin you can set or reset by software, but a real NSS would automatically set and reset the NSS pin on every transfer.