STM32F429 Nucleo-144 board - Can't get SPI2 to work! SCK OK, but no signal on MOSI (PB15) or MISO (PB14).

[Sbhad.1]

I have configured SPI2 in Stm32CubeMx and am coding in Stm32CubeIDE. PD3 as SCK, PB15 as MOSI and PB14 as MISO are configured, and i have also checked corresponding code in stm32F4xx_hal_msp.c as below.

void HAL_SPI_MspInit(SPI_HandleTypeDef* hspi)
{
  GPIO_InitTypeDef GPIO_InitStruct = {0};
  if(hspi->Instance==SPI2)
  {
  /* USER CODE BEGIN SPI2_MspInit 0 */
 
  /* USER CODE END SPI2_MspInit 0 */
    /* Peripheral clock enable */
    __HAL_RCC_SPI2_CLK_ENABLE();
 
    __HAL_RCC_GPIOB_CLK_ENABLE();
    __HAL_RCC_GPIOD_CLK_ENABLE();    /**SPI2 GPIO Configuration
    PB14     ------> SPI2_MISO
    PB15     ------> SPI2_MOSI
    PD3     ------> SPI2_SCK
    */
    GPIO_InitStruct.Pin = GPIO_PIN_14;
    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_SPI2;
    HAL_GPIO_Init(GPIOB, &GPIO_InitStruct);
 
    GPIO_InitStruct.Pin = GPIO_PIN_15;
    GPIO_InitStruct.Mode = GPIO_MODE_AF_PP;
    GPIO_InitStruct.Pull = GPIO_PULLUP;
    GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_VERY_HIGH;
    GPIO_InitStruct.Alternate = GPIO_AF5_SPI2;
    HAL_GPIO_Init(GPIOB, &GPIO_InitStruct);
 
    GPIO_InitStruct.Pin = GPIO_PIN_3;
    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_SPI2;
    HAL_GPIO_Init(GPIOD, &GPIO_InitStruct);

Additionally, the debug breakpoints placed in the above code show that this is executed. I am sending test SPI data, but on a DSO I can only see SCK pulses, but the PB14 (MISO) is always low, and PB15 (MOSI) is always high. Nothing is connected to those pins. I made sure there are no other conflicting peripherals like USB OTG, either configured or connected to the Nucleo board. SPi speed is 1.2 MHz.

Any clue about this? Thanks in advance.

[MM..1]

If you configure and use SPI2 as master then MISO low is OK .

How code you call to test send?

[waclawek.jan]

> I made sure there are no other conflicting peripherals like USB OTG

How?

Read out and check/post content of OTG_HS registers (mainly OTG_HS_GCCFG).

JW

[Sbhad.1]

Thanks for your reply. Yes, i use SPI2 as master in full duplex mode.

For testing I am using the following code :

HAL_GPIO_WritePin(SPI2_NSS_GPIO_Port, SPI2_NSS_Pin, GPIO_PIN_RESET);
if (HAL_SPI_TransmitReceive(&hspi2, wr_buf, (uint8_t *)spi_rx_buffer, 8, 5000) != HAL_OK) {
	printf("-1\n");
}
HAL_GPIO_WritePin(SPI2_NSS_GPIO_Port, SPI2_NSS_Pin, GPIO_PIN_SET);

[Sbhad.1]

Good question! I only depended on CubeMX to configure OTG as disabled.

How do i check that in the registers? I am not so familiar with interacting with registers in bit-language.

[MM..1 · Accepted solution]

Ok and what is in wr_buf? Is returned HAL_OK?

[Sbhad.1]

here is the piece of test code, the main part of it. HAL_OK is true.

#include "main.h"
 
SPI_HandleTypeDef hspi2;
 
void SystemClock_Config(void);
static void MX_GPIO_Init(void);
static void MX_SPI2_Init(void);
 
#define SPI_BUFFER_SIZE 255
main(){
 
// Some stuff are initiated
HAL_Init();
SystemClock_Config();
MX_GPIO_Init();
MX_SPI2_Init();
 
uint8_t wr_buf[8] = {0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF};
static uint8_t spi_rx_buffer[SPI_BUFFER_SIZE] = {0};
 
while (1)
  {
        HAL_GPIO_WritePin(SPI2_NSS_GPIO_Port, SPI2_NSS_Pin, GPIO_PIN_RESET);
        if (HAL_SPI_TransmitReceive(&hspi2, wr_buf, (uint8_t *)spi_rx_buffer, 8, 5000) != HAL_OK) 
        {
                 printf("-1\n");
         }
 
         HAL_GPIO_WritePin(SPI2_NSS_GPIO_Port, SPI2_NSS_Pin, GPIO_PIN_SET);
         printf("0\n");
 
	 HAL_Delay(1000);
}
}

[MM..1]

Then all is OK
MOSI is high you send FF
MISO is low you receive nothing connected

[Sbhad.1]

This is sooooo silly me.

If I change wr_buf to 11111111 instead of 00000000, I get the pulses on MOSI. This means SPI2 is working, my testing method was wrong!!!!

Thank you for asking the right debugging question!