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

[SofLit]

Did you change the boot options or not?

[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.

[RafaelS]

I have not changed the boot options.

[SofLit]

---

@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.

[SofLit]

---

@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 @SofLit, 

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?

[RafaelS · Accepted solution]

Good news!!

I have found that in my code the configuration of PWR voltage scaling were

__HAL_PWR_VOLTAGESCALING_CONFIG(PWR_REGULATOR_VOLTAGE_SCALE2);

and it seems that the correct value is

__HAL_PWR_VOLTAGESCALING_CONFIG(PWR_REGULATOR_VOLTAGE_SCALE1);

Now the LED blinks.

PS. I have seen this info in the following post: https://community.st.com/t5/stm32-mcus-products/invalidate-d-cache-in-stm32h745i-disco/m-p/734952

@SofLitThank you for the help.