[bug] GPIO setting for SPIx_NSS pin

[Ryan Gronlie]

Posted on February 26, 2016 at 03:09

With STM32CubeMX v4.0 and STM32CubeF0 v1.5.0 the GPIO initialization for a hardware NSS pin has changed and doesn't match the information in the reference manual.

For example SPI1_NSS from STMCubeF0 v1.2.1 was initialized:

GPIO_InitStruct.Pin = GPIO_PIN_15;
GPIO_InitStruct.Mode = GPIO_MODE_AF_PP;
GPIO_InitStruct.Pull = GPIO_PULLUP;
GPIO_InitStruct.Speed = GPIO_SPEED_LOW;
GPIO_InitStruct.Alternate = GPIO_AF0_SPI1;
HAL_GPIO_Init(GPIOA, &GPIO_InitStruct);

NowSPI1_NSS from STMCubeF0 v1.5.0 is initialized:

GPIO_InitStruct.Pin = GPIO_PIN_15;
GPIO_InitStruct.Mode = GPIO_MODE_INPUT;
GPIO_InitStruct.Pull = GPIO_PULLUP;
HAL_GPIO_Init(GPIOA, &GPIO_InitStruct);

Receiving data on SPI using DMA is working intermittently. I'm seeing weird issues like entire data blocks shifted by 1 bit. I've had to manually change the GPIO initialization code to get SPI transfers working properly again. The reference manual indicates that NSS is an alternate function, so I'm not sure why it was changed to be initialized as a pure GPIO input. #stmcubef0 #bug-stm32cubemx

Posted on February 29, 2016 at 15:11

Oh really thank you! You saved a couple of my hours )  I just created discussion about the same issue [DEAD LINK /public/STe2ecommunities/mcu/Lists/STM32Java/Flat.aspx?RootFolder=/public/STe2ecommunities/mcu/Lists/STM32Java/cubemx%204.13.0%20STM32F4%20what%27s%20wrong%20with%20SPI%20RX%20DMA&FolderCTID=0x01200200770978C69A1141439FE559EB459D758000F9A0E3A95BA69146A17C2E80209ADC21&TopicsView=https%3a//my.st.com/public/STe2ecommunities/mcu/Lists/STM32Java/AllItems.aspx&currentviews=4] cubemx 4.13.0 STM32F4 what's wrong with SPI RX DMA? and after that I found your discussion and that fixed my problem )

[Walid FTITI_O]

Posted on February 29, 2016 at 17:04

Hi gronlie.ryan,

Thank you for your feedback and contribution. I will report this to our CubeMX team for checking. -Hannibal-

With STM32CubeMX v4.0 and STM32CubeF0 v1.5.0 the GPIO initialization for a hardware NSS pin has changed and doesn't match the information in the reference manual.

For example SPI1_NSS from STMCubeF0 v1.2.1 was initialized:

GPIO_InitStruct.Pin = GPIO_PIN_15;
GPIO_InitStruct.Mode = GPIO_MODE_AF_PP;
GPIO_InitStruct.Pull = GPIO_PULLUP;
GPIO_InitStruct.Speed = GPIO_SPEED_LOW;
GPIO_InitStruct.Alternate = GPIO_AF0_SPI1;
HAL_GPIO_Init(GPIOA, &GPIO_InitStruct);

NowSPI1_NSS from STMCubeF0 v1.5.0 is initialized:

GPIO_InitStruct.Pin = GPIO_PIN_15;
 GPIO_InitStruct.Mode = GPIO_MODE_INPUT;
GPIO_InitStruct.Pull = GPIO_PULLUP;
HAL_GPIO_Init(GPIOA, &GPIO_InitStruct);

Receiving data on SPI using DMA is working intermittently. I'm seeing weird issues like entire data blocks shifted by 1 bit. I've had to manually change the GPIO initialization code to get SPI transfers working properly again. The reference manual indicates that NSS is an alternate function, so I'm not sure why it was changed to be initialized as a pure GPIO input.

[stm32cube-t]

Posted on March 22, 2016 at 19:16

Dear user,

this is fixed in STM32CubeMX 4.14.