Fix: Detect locked AT32F403A/407 to allow unlocking #2264

ALTracer commented 2026年05月24日 20:57:24 +02:00

Detailed description

• This is a fix to #1803.
• The existing problem is BMD probing but not detecting RDP1-locked AT32F403A, thus making it impossible to unlock them via monitor option erase.
• This PR helps solve it by adding a dedicated smaller detection routine, which skips adding Flash map, but still adds the stm32f1_cmd_list[] with stm32f1_cmd_option().

Tested against AT32F403A to allow unlocking. Unmodified BMD still cannot do this, because of tiny 250ms timeout in adiv5_swd_raw_access() -- RDP degrade involves a mass erase, which on these parts takes 1.4 seconds for each of two 512 KiB banks (or 0.8 s for 256 KiB). See also: #1956.
The target->driver = "AT32F403A/407 (locked)" is named like that to both pass the strncmp later in stm32f1_option_write(), and to indicate locked state (like nRF5 drivers).
Can't say whether AT32F407 (+EMAC) or older AT32F403 (200 MHz) are happy with similar treatment. Not dealing with other parts (AT32F415/F413, F421, F425), they will fail detection in a similar fashion. If I could test unlocking on these, it might make sense to me to dispatch all RDP1-locked AT32F4* (with FPEC at 0x4002_2000, like STM32F1) to a single "locked_detect()", that does not even add SRAM to map so to not lie about it -- smallest AT32F421 only have 8 KiB of it -- and provide the mon option erase command like this.

Your checklist for this pull request

• I've read the Code of Conduct
• I've read the guidelines for contributing to this repository
• It builds for hardware native (see Building the firmware)
• It builds as BMDA (see Building the BMDA)
• I've tested it to the best of my ability
• My commit messages provide a useful short description of what the commits do

Closing issues

## Detailed description * This is a fix to #1803. * The existing problem is BMD probing but not detecting RDP1-locked AT32F403A, thus making it impossible to unlock them via `monitor option erase`. * This PR helps solve it by adding a dedicated smaller detection routine, which skips adding Flash map, but still adds the `stm32f1_cmd_list[]` with `stm32f1_cmd_option()`. Tested against AT32F403A to allow unlocking. Unmodified BMD still cannot do this, because of tiny 250ms timeout in `adiv5_swd_raw_access()` -- RDP degrade involves a mass erase, which on these parts takes 1.4 seconds for each of two 512 KiB banks (or 0.8 s for 256 KiB). See also: #1956. The `target->driver = "AT32F403A/407 (locked)"` is named like that to both pass the strncmp later in `stm32f1_option_write()`, and to indicate locked state (like nRF5 drivers). Can't say whether AT32F407 (+EMAC) or older AT32F403 (200 MHz) are happy with similar treatment. Not dealing with other parts (AT32F415/F413, F421, F425), they will fail detection in a similar fashion. If I could test unlocking on these, it might make sense to me to dispatch all RDP1-locked AT32F4* (with FPEC at 0x4002_2000, like STM32F1) to a single "locked_detect()", that does not even add SRAM to map so to not lie about it -- smallest AT32F421 only have 8 KiB of it -- and provide the `mon option erase` command like this. ## Your checklist for this pull request * [x] I've read the [Code of Conduct](https://codeberg.org/blackmagic-debug/blackmagic/src/CODE_OF_CONDUCT.md) * [x] I've read the [guidelines for contributing](https://codeberg.org/blackmagic-debug/blackmagic/src/CONTRIBUTING.md) to this repository * [x] It builds for hardware native (see [Building the firmware](https://codeberg.org/blackmagic-debug/blackmagic?tab=readme-ov-file#building-the-firmware)) * [x] It builds as BMDA (see [Building the BMDA](https://codeberg.org/blackmagic-debug/blackmagic?tab=readme-ov-file#building-black-magic-debug-app)) * [x] I've tested it to the best of my ability * [x] My commit messages provide a useful short description of what the commits do ## Closing issues