Potential Silicon Error in SPI1 of STM32L432KC

[Innomatic]

Hi,

I suspect that I encountered with undocumented silicon error of STM32L432KC, while I'm playing with a Nucleo32-L432KC board. Here is how to reproduce it:

1. Start a new project with CubeMX v.4.27.0
2. Select SPI1 as a full duplex master(PA1:SCK, PA6:MISO, PA7:MOSI)
3. Select PA5 as GPIO output
4. Let STM32CubeMX generate code.
5. Test SPI1 and confirm that SCK (PA1) signal is working
6. Set PA5 high, then set it low
7. Repeat 5 (at this point the SCK failed to work)

In short, GPIO operation of PA5 (whose alternate function includes SCK) affects SCK of SPI1 (PA1).

Thanks,

[Rob.Riggs]

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

[Jeroen3]

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.

[Innomatic]

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

[waclawek.jan]

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

[Innomatic]

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?

[Tesla DeLorean]

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?

[waclawek.jan]

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

JW

[Innomatic]

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.