STM32U5A9 SPI Hardware SS output enable mode not working as intended

[JediVille]

Hi

I am struggling to get hardware SS management to work.

SSM=0, SSOE=1
and
SSOM=0, SP=000

From RM0456 ( Section 68.4.7 Slave select (SS) pin management ) I am expecting that the SS pin is driven to active level when transfer starts ( CSTART = 1 ) and it is kept until EOT flag is set ( or transmission is suspended ).

This seem to work as intended.

But when transfer has ended SPI_CloseTransfer is called and when the __HAL_SPI_DISABLE_IT macro is used the SS pin is driven to active level again.

This feels like a hardware bug.

According to RM0456 CSTART is cleared when EOT flag is set ( or when a suspend request is accepted ).

Thus what I see is:
SS active when CSTART is set ( rising edge ).
It goes inactive when EOT flag is set ( rising edge ).
It goes active again when interrupts are disabled ( could be the EOT interrupt, however others are disabled at the same time ).

Thus it seems that the configuration is being overlooked when interrupts are disabled.
I would expect the SS to stay inactive until next CSTART.

Or am I missing something ?

For reference I am using the function HAL_SPI_TransmitReceive from stm32u5xx_hal_spi.c ( generated by CubeMX ).

Initialization code includes the following:

hspi2.Init.TIMode = SPI_TIMODE_DISABLE; // SP = 000
hspi2.Init.Mode = SPI_MODE_MASTER;
hspi2.Init.NSS = SPI_NSS_HARD_OUTPUT; // SSM = 1, SSOE = 1
hspi2.Init.NSSPMode = SPI_NSS_PULSE_DISABLE; // SSOM = 0
hspi2.Init.NSSPolarity = SPI_NSS_POLARITY_LOW; //

The slave I am using does not work if SS is driven active like this.
A solution is to use software control of the SS pin and the slave works fine with that configuration.

 

//Jesper

[JediVille]

I realized that what is probably happening is that the SS pin is tri-stated the moment interrupts are disabled. 

If I add an internal pull-up hardware control works as intended.

But I would still question if it is correct behaviour to tri-state the SS pin when it is configured to hardware control.

And I have not found a mention on pin behaviour.

//Jesper