-
Notifications
You must be signed in to change notification settings - Fork 1.2k
Add startup delay and BOOT0 recovery documentation to prevent debug lockout #589
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| @@ -0,0 +1,150 @@ | ||||||||||
| # BOOT0 Pin Recovery Guide | ||||||||||
|
|
||||||||||
| ## When to Use This Method | ||||||||||
|
|
||||||||||
| If you cannot flash the board via ST-Link because: | ||||||||||
| - The firmware is blocking debug access | ||||||||||
| - ST-Link shows "unable to connect to target" or "init mode failed" | ||||||||||
| - You previously flashed firmware that prevents reprogramming | ||||||||||
| - You need to recover from a bad flash | ||||||||||
|
|
||||||||||
| ## What is BOOT0? | ||||||||||
|
|
||||||||||
| BOOT0 is a special pin on the STM32F103RC microcontroller that determines boot source: | ||||||||||
| - **BOOT0 = LOW (GND)**: Normal operation - runs firmware from flash memory | ||||||||||
| - **BOOT0 = HIGH (3.3V)**: Bootloader mode - STM32 enters DFU/programming mode | ||||||||||
|
||||||||||
| - **BOOT0 = HIGH (3.3V)**: Bootloader mode - STM32 enters DFU/programming mode | |
| - **BOOT0 = HIGH (3.3V)**: System memory bootloader mode - STM32 enters the factory UART bootloader (not USB DFU) |
Copilot
AI
Mar 10, 2026
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The documentation references ./flash_board.ps1 as a flashing script, but no such file exists anywhere in the repository. This will confuse users who follow this guide. Either remove this reference or add the missing script to the repository.
| Or use the flash script: | |
| ```bash | |
| ./flash_board.ps1 | |
| ``` |
Copilot
AI
Mar 10, 2026
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The inline code snippet in the "Prevention: Firmware Startup Delay" section has the same bug as the actual code: it presents the loop with the magic count 2000000 alongside the comment // 2 second delay, without accounting for the fact that this runs at 8 MHz HSI (before SystemClock_Config()). Documentation users copying this snippet will face the same timing issue. The example should be updated to use HAL_Delay(2000) placed after SystemClock_Config(), or at minimum note that the loop count needs to be calibrated against the actual clock speed when placed before clock configuration.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The delay loop is placed before
SystemClock_Config()(called at line 201), so the CPU is still running on the default HSI at 8 MHz — not at 72 MHz as the comment states. At 8 MHz, the loop body executes roughly 9x faster, meaning the actual delay is on the order of ~200 ms rather than ~2 seconds. The comment "2 second delay at 72MHz" is therefore incorrect, and the delay will fail to serve its intended purpose of giving the ST-Link debugger adequate time to connect.Consider moving the delay after
SystemClock_Config()and replacing it withHAL_Delay(2000), which is clock-agnostic, readable, and guaranteed to delay for exactly 2 seconds once the clocks are properly configured.