0

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

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();

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

Thank you!

DarreeN
  • 21
  • 3
  • You said you tried it on linux, but you didn't even say if it worked there. What was the point of mentioning it then? – Ilya Jun 06 '23 at 08:53
  • As for GPIO, open debugger, check SFR special function registers and check if GPIO port is configured correctly. Does the corresponding GPIO port have clock? Are all pin mode configurations set correctly? – Ilya Jun 06 '23 at 08:54
  • I said I tried it on Linux to show I verified that this isn't happening because of some local installation problem. If it worked there, I wouldn't have the problem anymore. – DarreeN Jun 06 '23 at 10:26
  • I will check the SFR, good idea. Thank you – DarreeN Jun 06 '23 at 10:27
  • Maybe show the code that configures the GPIO? Can you single-step through your code with a debugger to check that it is running as expected? – pmacfarlane Jun 06 '23 at 21:04
  • @Ilya Added a response to your comment after my testing as an answer. – DarreeN Jun 07 '23 at 06:03
  • @pmacfarlane Only the pin PI2 is set as high. This means the following is in the "MX_GPIO_Init" function. `HAL_GPIO_WritePin(GPIOI, GPIO_PIN_2|LCD_DISP_Pin, GPIO_PIN_SET);` – DarreeN Jun 07 '23 at 06:05

1 Answers1

0

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.

DarreeN
  • 21
  • 3