Potential Silicon Error in SPI1 of STM32L432KC

Does same behavior occur if you manipulate PA5 by writing the the control registers directly, rather than using the HAL?

It's extremely unlikely you will find a silicon error when you're using HAL. If you find an error, it's an error in the HAL.

Create a bare metal example to validate the silicon error, I don't think there is one.

@Rob.Riggs​ Yes I'm manipulating the register directly. Could that be the reason?

Read out and post the relevant GPIO (and maybe also SPI) registers' content for the non-working case.

Here is GPIO setting for SPI generated by the CUBE

void HAL_SPI_MspInit(SPI_HandleTypeDef* hspi)
{
 
	GPIO_InitTypeDef GPIO_InitStruct;
	if(hspi->Instance==SPI1)
	{
		/* USER CODE BEGIN SPI1_MspInit 0 */
 
		/* USER CODE END SPI1_MspInit 0 */
		/* Peripheral clock enable */
		__HAL_RCC_SPI1_CLK_ENABLE();
 
		/**SPI1 GPIO Configuration
		PA1 ------> SPI1_SCK
		PA6 ------> SPI1_MISO
		PA7 ------> SPI1_MOSI
		*/
		GPIO_InitStruct.Pin = GPIO_PIN_1|GPIO_PIN_6|GPIO_PIN_7;
		GPIO_InitStruct.Mode = GPIO_MODE_AF_PP;
		GPIO_InitStruct.Pull = GPIO_NOPULL;
		GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_VERY_HIGH;
		GPIO_InitStruct.Alternate = GPIO_AF5_SPI1;
		HAL_GPIO_Init(GPIOA, &GPIO_InitStruct);
 
		/* USER CODE BEGIN SPI1_MspInit 1 */
 
		/* USER CODE END SPI1_MspInit 1 */
	}
 
}

Then I control the PA5 this way

#define LED_OFF					(GPIOA->BRR = GPIO_PIN_5)
#define LED_ON				(GPIOA->BSRR = GPIO_PIN_5)

Whether I use HAL for the GPIO control or not, it is different pin isn't it?

Ok, but to get the attention of validation engineers you need to provide a complete and concise demonstration of the issue, not code fragments.

GPIO pin configured where?

Read out and post the relevant GPIO (and maybe also SPI) registers' content for the non-working case.

JW

Just for the purpose of record, I solved this problem by not using PA5. Maybe I'll get back to this and submit a whole project when I have time.