Skip to main content
kellogs
Associate
March 30, 2020
Question

NUCLEO=STM32H745ZI-Q: problems with SPI1 and SPI3

  • March 30, 2020
  • 2 replies
  • 790 views

Hello,

I am new to STM32 dev, so...

Logic analyzer only shows a glitch on MOSI line of SPI1 of around 156 ms then it puts it back to LOW level; similar results for SPI3.

Using PB3 (D23) and PB5 (D22) for SPI3; using PA7 (D11) for SPI1;

Solder bridges: SB49-OFF, SB50-OFF; SB56-ON, SB57-OFF

Checked with DMM for proper connectivity (MCU pin to pin socket)

STM32CubeIDE v 1.3.0

___The code___

What is commented out has already been tried, and not only that.

Help please!

Thank you

This topic has been closed for replies.

2 replies

kellogs
kellogsAuthor
Associate
April 2, 2020

I have also tried it like so:

void SystemClock_Config(void)
{
 RCC_OscInitTypeDef RCC_OscInitStruct = {0};
 RCC_ClkInitTypeDef RCC_ClkInitStruct = {0};
 RCC_PeriphCLKInitTypeDef PeriphClkInitStruct = {0};
 
 /** Supply configuration update enable 
 */
 HAL_PWREx_ConfigSupply(PWR_DIRECT_SMPS_SUPPLY);
 /** Configure the main internal regulator output voltage 
 */
// __HAL_PWR_VOLTAGESCALING_CONFIG(PWR_REGULATOR_VOLTAGE_SCALE3);
 __HAL_PWR_VOLTAGESCALING_CONFIG(PWR_REGULATOR_VOLTAGE_SCALE1);
 
 while(!__HAL_PWR_GET_FLAG(PWR_FLAG_VOSRDY)) {}
 /** Initializes the CPU, AHB and APB busses clocks 
 */
 
 __HAL_RCC_LSEDRIVE_CONFIG(RCC_LSEDRIVE_LOW);
 
 __HAL_RCC_PLL_PLLSOURCE_CONFIG(RCC_PLLSOURCE_HSE);
 
 RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSE;
 RCC_OscInitStruct.HSEState = RCC_HSE_BYPASS;
 RCC_OscInitStruct.PLL.PLLState = RCC_PLL_ON;
 RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_HSE;
 RCC_OscInitStruct.PLL.PLLM = 2;
 RCC_OscInitStruct.PLL.PLLN = 64;
 RCC_OscInitStruct.PLL.PLLP = 2;
 RCC_OscInitStruct.PLL.PLLQ = 2;
 RCC_OscInitStruct.PLL.PLLR = 2;
 RCC_OscInitStruct.PLL.PLLRGE = RCC_PLL1VCIRANGE_3;
 RCC_OscInitStruct.PLL.PLLVCOSEL = RCC_PLL1VCOWIDE;
 RCC_OscInitStruct.PLL.PLLFRACN = 0;
 if (HAL_RCC_OscConfig(&RCC_OscInitStruct) != HAL_OK)
 {
 Error_Handler();
 }
 /**Initializes the CPU, AHB and APB busses clocks
 */
 RCC_ClkInitStruct.ClockType = RCC_CLOCKTYPE_HCLK|RCC_CLOCKTYPE_SYSCLK
 |RCC_CLOCKTYPE_PCLK1|RCC_CLOCKTYPE_PCLK2
 |RCC_CLOCKTYPE_D3PCLK1|RCC_CLOCKTYPE_D1PCLK1;
 RCC_ClkInitStruct.SYSCLKSource = RCC_SYSCLKSOURCE_PLLCLK;
 RCC_ClkInitStruct.SYSCLKDivider = RCC_SYSCLK_DIV1;
 RCC_ClkInitStruct.AHBCLKDivider = RCC_HCLK_DIV2;
 RCC_ClkInitStruct.APB3CLKDivider = RCC_APB3_DIV2;
 RCC_ClkInitStruct.APB1CLKDivider = RCC_APB1_DIV2;
 RCC_ClkInitStruct.APB2CLKDivider = RCC_APB2_DIV2;
 RCC_ClkInitStruct.APB4CLKDivider = RCC_APB4_DIV2;
 
 if (HAL_RCC_ClockConfig(&RCC_ClkInitStruct, FLASH_LATENCY_2) != HAL_OK)
 {
 Error_Handler();
 }
 PeriphClkInitStruct.PeriphClockSelection = RCC_PERIPHCLK_USART3|RCC_PERIPHCLK_FDCAN
 |RCC_PERIPHCLK_SPI5|RCC_PERIPHCLK_SPI4
 |RCC_PERIPHCLK_SPI1|RCC_PERIPHCLK_SPI2
 |RCC_PERIPHCLK_SDMMC|RCC_PERIPHCLK_ADC
 |RCC_PERIPHCLK_SPI6;
 PeriphClkInitStruct.PLL2.PLL2M = 2;
 PeriphClkInitStruct.PLL2.PLL2N = 12;
 PeriphClkInitStruct.PLL2.PLL2P = 6;
 PeriphClkInitStruct.PLL2.PLL2Q = 2;
 PeriphClkInitStruct.PLL2.PLL2R = 2;
 PeriphClkInitStruct.PLL2.PLL2RGE = RCC_PLL2VCIRANGE_3;
 PeriphClkInitStruct.PLL2.PLL2VCOSEL = RCC_PLL2VCOMEDIUM;
 PeriphClkInitStruct.PLL2.PLL2FRACN = 0;
 PeriphClkInitStruct.SdmmcClockSelection = RCC_SDMMCCLKSOURCE_PLL;
 PeriphClkInitStruct.Spi123ClockSelection = RCC_SPI123CLKSOURCE_PLL;
 PeriphClkInitStruct.Spi45ClockSelection = RCC_SPI45CLKSOURCE_D2PCLK1;
 PeriphClkInitStruct.FdcanClockSelection = RCC_FDCANCLKSOURCE_PLL;
 PeriphClkInitStruct.Usart234578ClockSelection = RCC_USART234578CLKSOURCE_D2PCLK1;
 PeriphClkInitStruct.AdcClockSelection = RCC_ADCCLKSOURCE_PLL2;
 PeriphClkInitStruct.Spi6ClockSelection = RCC_SPI6CLKSOURCE_PLL2;
 if (HAL_RCCEx_PeriphCLKConfig(&PeriphClkInitStruct) != HAL_OK)
 {
 Error_Handler();
 }
 /** Enable USB Voltage detector
 */
// HAL_PWREx_EnableUSBVoltageDetector();
}

kellogs
kellogsAuthor
Associate
April 4, 2020

Looks like a C/C++ error. In debug mode the C compiler will initialize variables (non-standard behaviour) while the C++ compiler will not. Of course, I am trying to write some ordered C++ code here, which STM32CubeIDE is not too good at.

The problem was with `hspi` handles; solved by initializing them:

LCD_Nokia_5110::LCD_Nokia_5110() :
	hspi1({0}),
	hspi3({0})

Not having been zeroed, hspi.State was something else than 0 (HAL_SPI_STATE_RESET) and so ` HAL_SPI_MspInit(hspi);` would not get called any more.

These HAL_MSP* callbacks are yet another pain in the game, I did not realize those contained useful code...

I must say that in anticipation to the horrors of this Eclipse based ugliness I spent some 3-4 days trying to port this board in `mbed` and failed. Supporting it there would be much appreciated.