Receive wrong data in SPI slave - polling mode - receive only config

[jg_spitfire]

Hi, I am using cubemx to configure a stm32f411ve board as slave in receive only, polling mode and sofware NSS, in the code generated I have only added a few lines of code, only which I consider neccesary

**the master sends 12 bytes

outside main function:

uint8_t rxbuffer[12];
 
void Timeout_Error_Handler()
{
	while(1){
		HAL_GPIO_TogglePin(GPIOD,GPIO_PIN_13); //led orange
		HAL_Delay(500);
	}
 
}
 
 
void Error_Handler2()
{
	HAL_GPIO_WritePin(GPIOD,GPIO_PIN_14,GPIO_PIN_SET); //led red
}

inside main function:

    // I have commented the while (1) because for my test the master sends data just one time 
      //while (1)
      {
        /* USER CODE END WHILE */
        MX_USB_HOST_Process();
     
        /* USER CODE BEGIN 3 */
     
     
       switch (HAL_SPI_Receive(&hspi5,rxbuffer,12,5000))
        {
         case HAL_OK:
           /* Turn LED6 on: Transfer in reception process is correct */
           HAL_GPIO_WritePin(GPIOD,GPIO_PIN_15,GPIO_PIN_SET); //led blue
           break;
     
         case HAL_TIMEOUT:
           Timeout_Error_Handler();
           break;
     
         case HAL_ERROR:
           Error_Handler2();
           break;
     
         default:
           break;
         }

the issue is that I am receiving only 0XFF

I was testing the same board with the slave code provided by ST in the stm32f411 examples:

STM32Cube\Repository\STM32Cube_FW_F4_V1.25.0\Projects\STM32F411E-Discovery\Examples\SPI\SPI_FullDuplex_ComPolling

and this code works ok BUT I want to implement hardware slave select, this example uses the SPI2 of the board and that SPI does not allow to configure a hardware slave select, so I thought the easiest way to achieve this was create a new project with other SPI peripheral of the board (I am using SPI5) and include the hardware slave select option (once I have tested that without this option works ok, as the example provided by ST)

is there any configuration function I am missing?

thanks

[TDK]

If HAL_SPI_Receive returns HAL_OK, then it's reading something. Likely the MOSI signal isn't making it to you somehow.

Check your pin assignments and AF selection of those pins.

Verify the signal actually exists using a scope or logic analyzer.

[jg_spitfire]

The pins are configured as default by the cubemx:

• alternate function push pull
• very high frequency
• no pull up and no pull down

I dont have a logic analyzer right now