GPIO I/O control of the SPI port on F0

You can, at all times, continue to read the input-state of the pins by GPIO Input.

If you want to temporarily override the output state, change the direction or anything else that will disrupt the control the SPI module has over any of the pins, you can do so by modifying GPIOx->MODER (which x, which bits depends which pins) and setting the mode to Input or General-purpose-output as distinct from alternate-function. But you'll have to put it back to alternate-function before you do your next SPI operation as the HAL SPI libraries will not expect such "underhand" methods. Or call SPI_Init() again.

One point: GPIOx->ODR does not reflect the state that the SPI module chooses to drive an output pin when it has control. So you might cause a glitch on any pin unless you program GPIOx->ODR before changing GPIOx->MODER.

See the Reference Manual for your stm32 for more details.

Hope this helps,

Danish

SPI_Init() or any other SPI function neither cares whether there are any GPIO pins assigned to the SPI peripheral, nor does it attempt to configure any pins. We are speaking of StdPeriph, not HAL, aren't we?

The SPI peripheral does not care either if its outputs do not appear on any pins, but the state of its inputs are officially indeterminate. Unofficially I believe that unassigned inputs are sensed as low level by the peripheral.

Thanks for all.

At first I was issuing HAL_SPI function with hardware NSS. So, I realized that I did not have control over NSS by HAL_GPIO; and I need occasionally this control in order to read the MISO state from the external IC flagging "new data ready". So, I switched to HAL_SPI by SW NSS, on this turn I have control over NSS, but now, I must add this control before HAL_R/W SPI, and provide any way to read MISO state.

According some experiment into my STM32F072, the original CUBEIDE MX_SPI2_Init() can be disable by HAL_SPI_Deinit(), but in order to use the I/O pins, I needed to re-issue MX_GPIO_Init() again before any IO command, in order to resume control over those GPIO. Reissuing MX_SPI2_Init() seems to work, but I perceived some glitch on SPI's pins. I have been seaching on better ways to read the MISO before reading SPI.

My hardware is finished, but for new one, my own lesson from now on would be using SW NSS and commit MISO to a second IO port. Some SPI IC, would not need that NSS should be issued just before SPI transaction; NSS may be left asserted by grounding, saving one GPIO pin, but I am afraid that this procedure might increase IC noise sensibility.

Regard,