(Bug)Platform Configuration Challenges When Porting Blinky Example to STM32F407G-DISC1

[Tabrez-dev]

My Experience Implementing Blinky for STM32F4
When trying to run the blinky example on an STM32F407G-DISC1 board, I faced several challenges that revealed gaps in our platform support framework:

1. Mysterious 8-Byte Binary Syndrome
Initial Symptom:
The built binary was only 8 bytes despite correct compilation.

Diagnosis:

• No STM32F4-specific linker script existed
• Build system fell back to wrong memory mapping

Solution:
Created app/linker_files/stm32f4.ld with proper 1MB FLASH / 128KB RAM boundaries

2. Platform Detection Blind Spot
Challenge:
The -p stm32f4 flag wasn't triggering platform-specific configuration.

Discovery:

• Both app and example configs lacked STM32F4 conditionals
• Platform detection only worked for default targets

Fix:
Updated both app/config/app_config.cmake and examples/config/app_config.cmake with STM32F4 detection logic

3. Silent HAL Initialization Failure
Observation:
LED turned on but did not blink despite correct-looking code.

Root Cause:

• Missing HAL_Init() before clock configuration
• Systick timer not initialized

Resolution:
Added mandatory HAL_Init() call in the blinky example

Lessons Learned

1. Each different board needs its own special settings file to work right. We can't assume one linker script/setup fits all
2. Default fallback behaviors can hide critical errors

Recommendations

1. Create platform support checklist for:
   • Linker scripts
   • Clock configs
2. Add build system validation steps
3. Document initialization sequence requirements

Verification
Success criteria achieved after:

• Binary grew to expected 12KB size
• LED blinks

This experience highlights the importance of explicit platform configuration and proper initialization sequences.

[ajmerij]

@Tabrez-dev this is a known issue.

We made the platform compilable with STM32 SDK and have not committed latest files here. We will soon commit latest files and ensure that you will be able to download using openocde from CLI at least.

This issue will remain open and will be fixed by us.

[Tabrez-dev]

shall i continue with test or is there significant changes to the code base that i will need to do the test properly as described in Optimize GPIO Interrupt Handling for STM32F4 Platform #1?

[ajmerij]

You could possibly just write the ISR handler function within STM32 Cube IDE and post the proposed snippet here until we update the files from our end. How does that sound?