Able to program GPIO_EXTI example but the board doesnt responds

[RafaelS]

Hello,

I am new to STM MCUs and need to test the different peripherals of the STM32H745 to decide if it fits my project. I began with the GPIO_EXTI example, and it worked. Later, I tried to configure a USART for debugging purposes, but it didn’t work. After several days of trying, I reprogrammed the GPIO_EXTI example, but to my surprise, the LEDs no longer toggle when I press the user button.

 

I have tried programming the ELF file using both STM32CubeIDE and STM32CubeProgrammer (after performing a full chip erase). In both cases, the programming process completes without errors.

I have no idea why this is happening. Does anyone have any advice, please?

 

Thank you very much.

PS. I use the STM32H745I-DISCO board

 

 

[mƎALLEm]

Hello,

What example you used with UART? the native UART example provided in the CubeH7 or your own example starting from CubeMx?

If yes what power supply you set for this board? SMPS or LDO? you need to set it to SMPS.

[RafaelS]

Thank you @mƎALLEm, 

 

I have started a new project with the option "Start My project from ST Board". I can see that in System Core -> RCC the following information

I can see in the main.c that this information is the same:

void SystemClock_Config(void)

{

RCC_OscInitTypeDef RCC_OscInitStruct = {0};

RCC_ClkInitTypeDef RCC_ClkInitStruct = {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_SCALE2);



while(!__HAL_PWR_GET_FLAG(PWR_FLAG_VOSRDY)) {}



/** Initializes the RCC Oscillators according to the specified parameters

* in the RCC_OscInitTypeDef structure.

*/

RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSI|RCC_OSCILLATORTYPE_HSE;

RCC_OscInitStruct.HSEState = RCC_HSE_BYPASS;

RCC_OscInitStruct.HSIState = RCC_HSI_DIV1;

RCC_OscInitStruct.HSICalibrationValue = RCC_HSICALIBRATION_DEFAULT;

RCC_OscInitStruct.PLL.PLLState = RCC_PLL_ON;

RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_HSE;

RCC_OscInitStruct.PLL.PLLM = 23;

RCC_OscInitStruct.PLL.PLLN = 177;

RCC_OscInitStruct.PLL.PLLP = 2;

RCC_OscInitStruct.PLL.PLLQ = 4;

RCC_OscInitStruct.PLL.PLLR = 4;

RCC_OscInitStruct.PLL.PLLRGE = RCC_PLL1VCIRANGE_0;

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 buses 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_HSI;

RCC_ClkInitStruct.SYSCLKDivider = RCC_SYSCLK_DIV1;

RCC_ClkInitStruct.AHBCLKDivider = RCC_HCLK_DIV1;

RCC_ClkInitStruct.APB3CLKDivider = RCC_APB3_DIV1;

RCC_ClkInitStruct.APB1CLKDivider = RCC_APB1_DIV1;

RCC_ClkInitStruct.APB2CLKDivider = RCC_APB2_DIV1;

RCC_ClkInitStruct.APB4CLKDivider = RCC_APB4_DIV1;



if (HAL_RCC_ClockConfig(&RCC_ClkInitStruct, FLASH_LATENCY_1) != HAL_OK)

{

Error_Handler();

}

}

 

Thanks

[mƎALLEm]

Hello,

In next time please use </> button to share your code. See this post.

Better to share your project (attach it in the thread) so we can look and test it.

[mƎALLEm]

Thanks for sharing.

The LED is toggling as intended from my side.

Did you upload the program of CM4? if it was not uploaded you cannot run the rest of CM7 program because there is a mechanism of synchronization at startup between the two cores.

[RafaelS]

I think yes.

1. I select the CM4 file

2. I click on the hammer in orther to build the CM4 project

3. I click on play icon

After I can read in Console <terminated> USART2_debug_CM4 download verified successfully

I do the same for CM7.

After programming both cores I push the reset button but nothing happens.

Am I doing the right steps?

Thanks.

[mƎALLEm]

Hello,

In your program there is nothing mentioning that you are sending characters over UART. The only thing I see is the LED toggle:

CM7:

 MX_GPIO_Init();
 MX_USART2_UART_Init();
 /* USER CODE BEGIN 2 */

 /* USER CODE END 2 */

 /* Infinite loop */
 /* USER CODE BEGIN WHILE */
 while (1)
 {
 /* USER CODE END WHILE */

 /* USER CODE BEGIN 3 */
	HAL_GPIO_TogglePin(LD1_GPIO_Port, LD1_Pin);
	//printf("Mare meua");
	//__io_putchar(48);
	HAL_Delay(1000);
 }
 /* USER CODE END 3 */
}

CM4:

 /* Initialize all configured peripherals */
 MX_GPIO_Init();
 MX_ETH_Init();
 MX_FDCAN1_Init();
 MX_FDCAN2_Init();
 MX_FMC_Init();
 MX_LTDC_Init();
 MX_QUADSPI_Init();
 MX_SAI2_Init();
 MX_SDMMC1_MMC_Init();
 MX_USART3_UART_Init();
 MX_USB_OTG_FS_PCD_Init();
 /* USER CODE BEGIN 2 */

 /* USER CODE END 2 */

 /* Infinite loop */
 /* USER CODE BEGIN WHILE */
 while (1)
 {
 /* USER CODE END WHILE */

 /* USER CODE BEGIN 3 */
 }
 /* USER CODE END 3 */
}

So the question is, are you seeing LD1 toggling or not?

[RafaelS]

I am going to try a Demonstration to see it run or not. May be it will give any clue

[RafaelS]

Hello,

I have download these file: https://www.st.com/resource/en/compiled_demos/stm32h745i-disco_demo.zip 

and I have launch "program_hexfile.bat" with the following output

But the screen does not show anything, only a white screen...

I wonder if the board is broken. It is strange to be able to program it without error.

Is it posible that the core is OK but the periferics are boken?

[mƎALLEm]

It's hard to tell you what happened and what is going on..

Try to run a very simple example without using any external resources (GPIOs etc ..) example an algorithm like BubbleSort: https://www.geeksforgeeks.org/bubble-sort-algorithm/

Make a full erase of the Flash using CubeProgrammer and upload/Run this algorithm on CM7. Run it in debug and see if the algorithm is running well (sorting the values correctly).

Do the same thing on CM4.

[mƎALLEm]

One thing, did you modify the option bytes? especially the boot options?

[RafaelS]

Hello,

I will try the algorithm BubbleSort as soon as possible, thanks.

 

I have not modified the option bytes. I attach a picture

Thanks

[mƎALLEm]

Did you change the boot options or not?

 

[RafaelS]

I have not changed the boot options.

[RafaelS]

Hello!
I have noticed something interesting. While running the bubble algorithm in debug mode, I realized that the CM7 core remains stuck in a while(1) loop due to an error handler.

 

 

 while((__HAL_RCC_GET_FLAG(RCC_FLAG_D2CKRDY) != RESET) && (timeout-- > 0));
 if ( timeout < 0 )
 {
 Error_Handler();
 }

 

It seems that there is a timeout... it seems that the D2 is not ready for some reason, I am going to take a look in this registers.

[mƎALLEm]

---

@RafaelS wrote:

Hello!
I have noticed something interesting. While running the bubble algorithm in debug mode, I realized that the CM7 core remains stuck in a while(1) loop due to an error handler.

 

 

 while((__HAL_RCC_GET_FLAG(RCC_FLAG_D2CKRDY) != RESET) && (timeout-- > 0));
 if ( timeout < 0 )
 {
 Error_Handler();
 }

It seems that there is a timeout... it seems that the D2 is not ready for some reason, I am going to take a look in this registers.

---

That's normal, CM7 is wating a wakeup signal from CM4 that you didn't run its program. 

At this stage I suggest to comment these lines:

 while((__HAL_RCC_GET_FLAG(RCC_FLAG_D2CKRDY) != RESET) && (timeout-- > 0));
 if ( timeout < 0 )
 {
 Error_Handler();
 }

and run again the example.

[RafaelS]

Hello,

the bubble algorithm works in both cores.

 

I have realise that the code

while((__HAL_RCC_GET_FLAG(RCC_FLAG_D2CKRDY) != RESET) && (timeout-- > 0));
 if ( timeout < 0 )
 {
 Error_Handler();
 }

 apears twice in main.c of CM7. I've commented out the first piece of code. This way, the second time the code appears, the CM7 doesn't get blocked due to a timeout.

So I did the following test: in the USART2_debug code I attached earlier, I commented out the first occurrence of that code and ran it step by step. When it reaches the line to toggle the LED, the LED turns on! This rules out the possibility that the board is damaged.

 

[mƎALLEm]

 

---

@RafaelS wrote:

Hello,

the bubble algorithm works in both cores.

 

I have realise that the code

while((__HAL_RCC_GET_FLAG(RCC_FLAG_D2CKRDY) != RESET) && (timeout-- > 0));
 if ( timeout < 0 )
 {
 Error_Handler();
 }

 apears twice in main.c of CM7.

 

---

But not the same condition: != RESET for the first and == RESET for the second.

And indeed this confirms my doubts. The board is OK but run the code in debug mode. The debug mode is a bit tricky as CM7 and CM4 are synchronized and CM4 is put in low power mode. 

You need to stop the debug session as I said previously and run the application in a stand alone mode.

Or  if you are not using CM4 simply comment out:

 /* Wait until CPU2 boots and enters in stop mode or timeout*/
 timeout = 0xFFFF;
 while((__HAL_RCC_GET_FLAG(RCC_FLAG_D2CKRDY) != RESET) && (timeout-- > 0));
 if ( timeout < 0 )
 {
 Error_Handler();
 }
 

 and

 /*HW semaphore Clock enable*/
 __HAL_RCC_HSEM_CLK_ENABLE();

 /*Take HSEM */
 HAL_HSEM_FastTake(HSEM_ID_0);
 /*Release HSEM in order to notify the CPU2(CM4)*/
 HAL_HSEM_Release(HSEM_ID_0,0);

 /* wait until CPU2 wakes up from stop mode */
 timeout = 0xFFFF;
 while((__HAL_RCC_GET_FLAG(RCC_FLAG_D2CKRDY) == RESET) && (timeout-- > 0));
 if ( timeout < 0 )
 {
 Error_Handler();
 }

This makes your application running as a Single Core MCU configuration.

Hope that helps you.

[RafaelS]

Hello @mƎALLEm, 

I have commented the lines that you have told me in CM7 and I have commented the following lines in CM4

 MX_GPIO_Init();
 MX_ETH_Init();
 MX_FDCAN1_Init();
 MX_FDCAN2_Init();
 MX_FMC_Init();
 MX_LTDC_Init();
 MX_QUADSPI_Init();
 MX_SAI2_Init();
 MX_SDMMC1_MMC_Init();
 MX_USART3_UART_Init();
 MX_USB_OTG_FS_PCD_Init();

 

When I run the aplication in stand alone mode, the LED doesn´t blink.

When I run the aplication in debug mode the LED turns ON when the MCU enters in the line

HAL_GPIO_TogglePin(LD1_GPIO_Port, LD1_Pin);

and turn off when the MCU jumps to the next line

HAL_Delay(1000);

And then it is no posible continuing the debug. The code stops in the following line of stm32h7xx_hal.c

while ((HAL_GetTick() - tickstart) < wait)

I imagine this is normal because the timer that counts the ticks might not stop in debug mode.

On the other hand, you mentioned that the CM4 is in low power mode. Do you mean that while debugging the CM7, the CM4 core is in low power mode? If I debug the CM4, for example, will the CM7 be in low power mode?