Fix: add a minimum reset pulse duration #2251

ALTracer commented 2026年05月10日 22:58:35 +02:00

Detailed description

• No new features.
• The existing problem is the reset pulse of too short duration on some in-tree BMP platforms. #1868 point 2.
• This PR solves it by adding a minimal (1ms) delay at cortexm_reset() callsite (and cortexar).

This was previously tested to fix stlink and blackpill-f411ce so that they are able to cortexm_reset by wire the AT32F403A target connected via JTAG transport. See #2248 (actually problem present since before PR2072).
This seems to be the easier of the two mitigation variants for it (the other is invoking dp->ensure_idle() somehow mid-write to AIRCR via ADIv5 MEM-AP so that READ DP CTRL/STAT doesn't face broken transport).
Can't say how much native and bmp-v3 were affected, as they incorporate small busy-loops in platform_nrst_set_val(); this will increase the reset pulse (active low) duration, which is not necessarily a bad thing. Later the busy-loops can be removed from platforms where present.
BMDA was not affected as USB FS and synchronous nature of BMP remote protocol resulted in sufficient delay.
riscv_reset() has some riscv_dm_poll_state() call between nrst_set_val edges, which is basically a riscv_dm_read(), which might be long enough -- keeping as-is.

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

Fixes #1868 point 2.

## Detailed description * No new features. * The existing problem is the reset pulse of too short duration on some in-tree BMP platforms. #1868 point 2. * This PR solves it by adding a minimal (1ms) delay at `cortexm_reset()` callsite (and cortexar). This was previously tested to fix `stlink` and `blackpill-f411ce` so that they are able to cortexm_reset by wire the AT32F403A target connected via JTAG transport. See #2248 (actually problem present since before PR2072). This seems to be the easier of the two mitigation variants for it (the other is invoking `dp->ensure_idle()` somehow mid-write to AIRCR via ADIv5 MEM-AP so that READ DP CTRL/STAT doesn't face broken transport). Can't say how much `native` and `bmp-v3` were affected, as they incorporate small busy-loops in `platform_nrst_set_val()`; this will increase the reset pulse (active low) duration, which is not necessarily a bad thing. Later the busy-loops can be removed from platforms where present. BMDA was not affected as USB FS and synchronous nature of BMP remote protocol resulted in sufficient delay. `riscv_reset()` has some `riscv_dm_poll_state()` call between nrst_set_val edges, which is basically a `riscv_dm_read()`, which might be long enough -- keeping as-is. ## 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 Fixes #1868 point 2.