STM32F407 - SPI pins output pulse when changing configuration to Alternate Function

[LS_it]

Hi,

I'm giving the firsts steps in this world and I'm trying to configure SPI in one STM32F407 discovery kit.
I'm using GPIOB pins 12, 13, 14 and 15 as Alternate Function to handle the SPI2 interface.

The point is, in the instant that I change the configuration of GPIO pins to Alternate Function, the pins for MISO, NSS and Clock give one pulse.
In the image it is clear what is happening.
I suppose that the change of configuration is not a reason to get this strange behavior.

The data is sent without problems.

Thanks for your comments.

 

[TDK]

To avoid this, you can configure the SPI and enable it prior the setting the pins as AF. HAL doesn't support this. An external pullup can also prevent. Or just ignore it as the pulses don't violate the SPI protocol.

Note that you should control the CS pin manually with GPIO functions as the built-in "NSS" functionality is unlikely to be what you want on the STM32F4 series.

[LS_it]

Thanks for your hints @TDK .

Indeed, I'm configuring the AF of GPIO pins for SPI2 before calling the SPI Init routine, to me this make sense.
I'm not using HAL, I configure the respective registers of the chip step by step, I think this way is better to learn a bit more of the structure of STM chip.

I'm also aware of that NSS functionality, until now I'm running the board without any external connections, only for test the output of SPI.

The code for the first approach is the following:

 

int main (void)
{
	char user_data[]= "UHello";

	GPIO_ButtonPA0 ();
	SPI2_GPIOInit ();
	SPI2_Init ();

	//while (1)
		{
			//while (!(GPIO_ReadFromInputPin(GPIOA, GPIO_PIN_NO_0)));
			//delay ();

			//this makes NSS signal internally high and avoid MODF Error - to use when NSS is software managed
			SPI_SSI_Config (SPI2, ENABLE);

			//to use when NSS is hardware managed
			//SPI_SSOE_Config(SPI2,ENABLE);

			//enable SPI2 -- flag para o iniciar
 			SPI_PeripheralControl(SPI2, ENABLE);

			SPI_Send (SPI2, (uint8_t *)user_data, strlen (user_data));

			//antes de fechar a comunicação, testa-se a busy flag
			while (SPI_GetFlagStatus (SPI2, SPI_BUSY_FLAG));

			//disable SPI2 -- flag para o fechar
			SPI_PeripheralControl(SPI2, DISABLE);
		}

	while(1);
	return 0;
}

 

Following your hint, I move the SPI2_GPIOInit () to the line before SPI_Send, like this:

int main (void)
{
	char user_data[]= "UHello";

	GPIO_ButtonPA0 ();

	SPI2_Init ();

	//while (1)
		{
			//while (!(GPIO_ReadFromInputPin(GPIOA, GPIO_PIN_NO_0)));
			//delay ();

			//this makes NSS signal internally high and avoid MODF Error - to use when NSS is software managed
			SPI_SSI_Config (SPI2, ENABLE);

			//to use when NSS is hardware managed
			//SPI_SSOE_Config(SPI2,ENABLE);

			//enable SPI2 -- flag para o iniciar
 			SPI_PeripheralControl(SPI2, ENABLE);
 			SPI2_GPIOInit ();
			SPI_Send (SPI2, (uint8_t *)user_data, strlen (user_data));

			//antes de fechar a comunicação, testa-se a busy flag
			while (SPI_GetFlagStatus (SPI2, SPI_BUSY_FLAG));

			//disable SPI2 -- flag para o fechar
			SPI_PeripheralControl(SPI2, DISABLE);
		}

	while(1);
	return 0;
}

In this situation I got the following behaviour:

So, the pulses appear again, only a little bit latter. 
I didn't test yet the pull up in the pins, anyway, it is my felling that the pull up doesn't help because the pulses appear when the pins goes to ground.

I also think that this behavior is not a big deal related to the SPI protocol ... the data is sent without errors.

But, at least, if we look to the MISO pin, it does not make sense the configuration as AF makes the pin go to the ground. In the master side, the MISO signal is an input and the pulse is forcing ground level. If in the slave side we have Vcc level, it result in a short circuit. We can tell the slave should be in high impedance state until the communication start, but, sometimes bad things happen.

Maybe be this is a feature of STM core, probably there is a rational explanation for this ...

Let's see if some more people have found this phenomena.

Regards.