2024-05-03 09:30 AM
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
2024-05-06 02:30 AM
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