Code not being flashed to STM32F746G-Discovery board using STM32CubeIDE

[FHanu.1]

I am currently facing an issue while programming the STM32F746G-Discovery board using STM32CubeIDE. I have created a project using the default-generated settings and made a small modification in the GPIO configuration to set PI2 (D8) to a high output level. However, despite the console confirming that the code was flashed correctly and verified successfully, it appears that my changes are not taking effect on the board. I verified that with a multimeter.

I have also attempted to test the board using various simple code examples, but none of them seems to work either. I am wondering what could be causing this problem and if there's something I might be overlooking. Could there be a fault somewhere that is preventing my code from being properly flashed to the board, an additional step?

I was facing this issue on Windows, then decided to test the same on my Linux development laptop with a fresh installation of STM32CubeIDE. I have gone through "Help" -> "ST-Link Upgrade".

Any guidance or suggestions on troubleshooting steps would be greatly appreciated.

Thank you!

[Rim LANDOLSI]

Hello @Filip Hanus​  and welcome to the community,

Could you please provide which STM32CubeIDE version used for this project , the debug configuration and the GDB server log. Also, it would be more helpful to share the error occurred while flashing the code.

Thanks,

Rim

[Piranha]

C'mon, verify whether the code is actually flashed or not! Erase the whole FLASH, program the MCU from the IDE and read the FLASH memory with CubeProgrammer.

[FHanu.1]

I have debugged my STM32F746G-Discovery board project using STM32CubeIDE (Version: 1.12.1) and observed some details related to the configuration of the GPIO pin PI2 (D8).

I attempted to generate a .bin file for the project through C/C++ Build settings in the STM32CubeIDE, but I couldn't locate the "Convert to binary file" option. If I would have succeeded, I would have tried to flash it using the STM32CubeProgrammer.

I used the STM32CubeProgrammer to inspect the device's memory. After erasing the device, I programmed it with my code using STM32CubeIDE. The firmware includes the change in pin configuration where PI2 is set to a high output level. After flashing the program, I noticed that the flash memory area from 0x08000000 to 0x080003F0 was the only section of the device memory displaying written data. This indicates that the flashing process was completed successfully, and the configuration change for PI2 should be included in this written data.

When I build the project in STM32CubeIDE, it successfully finishes with no errors or warnings. The build output is:

   

Finished building target: test.elf
 
 
 arm-none-eabi-size test.elf 
 
 arm-none-eabi-objdump -h -S test.elf > "test.list"
 
 text data bss dec hex filename
 
 77904 476 39460 117840 1cc50 test.elf
 
 Finished building: default.size.stdout
 
 
 Finished building: test.list
 
 
 06:28:52 Build Finished. 0 errors, 0 warnings. (took 5s.154ms)

In the STM32CubeIDE debugger, I navigated to the Special Function Registers (SFR) tab and selected GPIOI. I found that the MODER register (GPIO port mode register) for GPIOI had a value of 0x00. This indicates that all pins in GPIOI are configured as inputs.

When stepping over the code in the debugger, I noticed that the SystemClock_Config(); function was continuously running in a loop and the debugger would not step further. This suggests there might be an issue with the clock configuration or an error handler redirecting the execution flow back to the system initialization code.

 Breakpoint 3, main () at ../Core/Src/main.c:162
 
 162 HAL_Init();
 
 (gdb)
 
 Breakpoint 5, main () at ../Core/Src/main.c:169
 
 169 SystemClock_Config();
 
 
 Breakpoint 5, main () at ../Core/Src/main.c:169
 
 169 SystemClock_Config();
 
 
 Breakpoint 5, main () at ../Core/Src/main.c:169
 
 169 SystemClock_Config();

[Piranha]

https://www.stmcu.org.cn/module/forum/data/attachment/forum/201905/16/111046byem60dcdcqej644.png

And CubeProgrammer also supports ELF files.

Anyway, as almost always, the real problem is just a broken code.

[FHanu.1]

I'd like to update this thread with my findings and hopefully, it might save someone else some time in the future.

I found the root cause of my issue, and it was simply an assumption I made. I thought the default code provided would be as plain and simple as possible, so I didn't look too closely into its workings initially. However, I later realized that it actually initializes and starts the FreeRTOS system.

Because of this, the execution never reached the part of my code where it was supposed to turn the LED on/off. In hindsight, it makes sense now why my LED control was not functioning.

I want to apologize for any confusion caused by this oversight. My intention was never to waste anyone's time. To those who are new to this, please ensure to fully understand your starter code before building upon it, as it might have more going on than you initially anticipate, just as it happened with FreeRTOS in my case.

Thank you to all who offered help and suggestions. It was an important learning moment for me, and I hope this post may be beneficial for someone in the future.