Default FW generated by CubeMx for STM32H745I-DISCO board doesn't work after cycling power

[Michael98006]

I'm trying to generate a default FW image with CubeMx 5.3.0 for my STM32H745I-DISCO board with the only change being the addition of the code to blink an LED:

 GPIO_InitTypeDef GPIO_InitStruct = {0};

 __HAL_RCC_GPIOJ_CLK_ENABLE();

 GPIO_InitStruct.Pin = LD1_Pin;

 GPIO_InitStruct.Mode = GPIO_MODE_OUTPUT_PP;

 GPIO_InitStruct.Pull = GPIO_NOPULL;

 GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_LOW;

 HAL_GPIO_Init(LD1_GPIO_Port, &GPIO_InitStruct);

 while (1)

 {

  HAL_GPIO_TogglePin(LD1_GPIO_Port, LD1_Pin);

  HAL_Delay(500);

 }

So I program the FW image with IAR (both CM4 and CM7 images), reset the board, and the LED starts blinking.

Resetting the board restarts the FW just fine.

Unplugging the USB cable from the STLK port and plugging it back in (this cable also provides power to the board) results in the FW not running anymore. IAR can't reprogram the MCU because it can't see the target anymore. Neither can the ST-LINK utility.

The Workaround

So I perform a "full chip erase" via ST-LINK (I have to hold the reset button down while plugging in the USB cable and pressing the full chip erase button, then release the reset button). I can program the chip with IAR, but the FW still doesn't run.

I erase the full chip again and program the GPIO_EXTI example from the CubeH7 package (version 1.4.0). The example works great (I can see LED's toggle when I press the user button. The example FW continues to work after multiple iterations of unplugging and plugging in the USB cable. OK, so my board is fine. I can now program the FW I generated with CubeMx and run it... until the USB cable is unplugged.

To get my FW running again, I have to repeat the steps above all over again.

The question is, what's so different between the default code that CubeMx generates and the code in the GPIO_EXTI example that I can't cycle USB power with the CubeMx-generated FW, but the example code runs ok after cycling USB power?

[Tesla DeLorean]

Make sure CubeMX isn't disabling the debug connection based on some menu setting/selection. Check "connect under reset", and reduce connection frequency.

I'm not using CubeMX, for a host of reasons, not going to litigate them here, but does limit my personal experiences with it, and interest generally.

Use the STM32 Cube Programmer over the ST-LINK Utilities, the former has current mindshare. Check also current ST-LINK/V3 firmware, the standalone update tools has the most recent version as I recall.

I've posted SystemClock_Config() for the H745I that I think is workable. Getting the wrong VOS settings or LDO/SMPS settings, makes for a bad day. Worst case strap BOOT0 High, and cycle power a couple of times.

I'll go dig for the code, useless search functions on forum

https://community.st.com/s/question/0D50X0000AtikPdSQI/stm32h745xdisco-documentation-insert-card-issue

[Michael98006]

Looks like the problem was that CubeMx generated this code:

 HAL_PWREx_ConfigSupply(PWR_LDO_SUPPLY);

Whereas the working example had this code:

 HAL_PWREx_ConfigSupply(PWR_DIRECT_SMPS_SUPPLY);

Once the line was updated, I was able to cycle power to my board and get it running every time USB power was supplied.

ST needs to update their CubeMx tool to generate the correct code for the board, considering that PWR_DIRECT_SMPS_SUPPLY is not even an option on the SupplySource drop-down list under RCC settings.

[Tesla DeLorean]

Here's the one I had in mind

https://community.st.com/s/question/0D50X0000B45FHiSQM/stm32h745idisco-crash-at-systemclockconfig

[Tesla DeLorean]

I'm going to cross link your other post so I can find it later via a strafe search

https://community.st.com/s/question/0D50X0000BD2xd9SQB/cubemx-is-missing-the-pwrdirectsmpssupply-option-under-rccsupplysource

[Tesla DeLorean]

@Khouloud GARSI​ @Nawres GHARBI​ can someone review or comment on the CubeMX H7 situation