Incorrect handling of GPIO_INVALID in SPI HAL
Short description
HW_HAL_SPI::initMembers()
stores GPIO_INVALID
, the default value of nssPin
, as pin 15 on port A. Therefore, the information of the user not wanting to use the NSS pin is lost.
Long description
The constructor for HAL_SPI
has an optional parameter nssPin
whose default value is set to GPIO_INVALID
. It later constructs a HW_HAL_SPI
which calls HW_HAL_SPI::initMembers()
which has the same optional parameter with the same default value. However, initMembers()
does not store this variable of type GPIO_PIN
directly but uses HW_HAL_GPIO::getSTM32Pin()
and HW_HAL_GPIO::getSTM32Port()
to compute its pin number and a pointer to its port (see https://gitlab.com/rodos/rodos/-/blob/master/src/bare-metal/stm32f4/hal/hal_spi.cpp?ref_type=heads#L139-143). Since GPIO_INVALID
is -1, HW_HAL_GPIO::getSTM32Pin()
computes its pin number to be 15, and HW_HAL_GPIO::getSTM32Port()
decides it is on port A. With this, the information that the user does not want to use the NSS pin is lost and HAL_SPI::init()
configures PA15 to use some alternative function.
Disclaimer: I only checked all of this for the STM32F4 code since this is the only MCU we use in our project.