STM32L486 mcu used as Master SPI, Zigbee device as slave. What configuration of SSM and SSI should i be using?

[siddiq.habib]

I am going through an existing implementation, where my MCU's(STM32L486) SPI1 (PA4(NSS), PA5(SCK), PA6(MISO), PA7(MOSI) is used as master, the slave device is a zigbee stack.

Currently the master's SSL is configured as Software managed, (SSM=1, SSI= 1).

But the slave expect it to be asserted/deasserted through its SSL pin externally (GPIO).

In this case can i use the PA4(NSS) pin of the master to select the slave. this pin is connected to the SSL of slave.

My doubt is although the master is configured for software slave management, can it drive its PA4(NSS) pin for controlling the slave, Is this configuration correct or can cause problem?

[S.Ma]

The STM32 NSS pin controlled by SW (even not an alternate function) will be more than enough, especially because Zigbee are probably not bandwisth demanding. In this case, the SPI HW NSS signal is not going out of the chip, and that's my typical way. As such, any pin of the STM32 can be used. brings some degrees of freedoom in the pin selection.

[siddiq.habib]

the content is in reply

[siddiq.habib]

I have highlighted in yellow the statement which has been confusing me.

"Optionally, the pins can be left unused by the peripheral. Then the flow has to be handled internally for both master and slave"

Here it is mentioned "then the flow has to be handled internally for both master and slave".

Which puts a question in my mind that either both slave and master use internal bits for their SSL configuration

OR

if Slave is not configured using internal SSL configuration, use an explicit GPIO pin.

Please correct my understanding.

[siddiq.habib]

Thanks for the reply ... i havent picked up all the things u mentioned.

"In this case, the SPI HW NSS signal is not going out of the chip" -> do you mean

Because of the specific configuration of master (SSM = 1 and SSI = 1), the NSS signal doesnt generate any signal at the NSS pin level, so i cant connect this to slave's SSL pin. So i should use some other GPIO

OR

i can drive the PA4(NSS) pin using HAL GPIO API, and this will not cause any side effects.

[S.Ma]

The peripheral and its signals can be routed to GPIO through the alternate functions... or not.

So you should just select any GPIO as push pull output and drive it by SW to become the master's NSS.

The peripheral guts is like the brain without all nerves connected to muscles...

The drawing Figure 459 is misleading as it simply says if you know what you are doing and you don't need to get NSS to tell you the start and end of message, then you can forget it, which is rarely the case: a simple bus glitch and all your data maybe few bits shifted... and what happens if the slave is reset or the master is separately reset? boum!

You can set the SPI as you said, and not activate the alternate function to let the signal out. Then use the corresponding GPIO simple Set/Reset output level to generate the NSS. Use PA5 (or any pin you wish) as push pull output (mode=01) to generate the NSS for the slave.

[siddiq.habib]

I believe you meant PA4(NSS pin) of the master can be used to drive the slave select low and high without any side effects although master has Software slave management enabled.

[S.Ma]

Correct.