Detailed description
- This is a small new feature. See #2248 (comment)
- The existing problem is AT32F403A flashing fails when connected via 4-wire JTAG transport without physical reset wire:
JTAG-DP invalid ACK. - This PR solves it by catching that exception.
Tested on blackpill-f411ce against AT32F403ACGU7 as found on https://github.com/WeActStudio/WeActStudio.BlackPill , and on BMDA (I think). I have not seen a similar error (refuse to reset/flash) with other targets or probe platforms, if only J-Link. JTAG access resulted in 0:0 messages can still appear on DEBUG_TARGET channel of BMF. If the comment block is unwelcome, then I'll delete it in favor of Codeberg/Forgejo issue trackers.
Related, let's drop the extraneous 10ms delay I introduced back in PR2072. It didn't exist there, and there are two other 10ms delays around it (one after 1ms RST pulse, one near return from cortexm_reset()).
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 small new feature. See https://codeberg.org/blackmagic-debug/blackmagic/pulls/2248#issuecomment-14374226
* The existing problem is AT32F403A flashing fails when connected via 4-wire JTAG transport without physical reset wire: `JTAG-DP invalid ACK`.
* This PR solves it by catching that exception.
Tested on `blackpill-f411ce` against AT32F403ACGU7 as found on https://github.com/WeActStudio/WeActStudio.BlackPill , and on BMDA (I think). I have not seen a similar error (refuse to reset/flash) with other targets or probe platforms, if only J-Link. `JTAG access resulted in 0:0` messages can still appear on DEBUG_TARGET channel of BMF. If the comment block is unwelcome, then I'll delete it in favor of Codeberg/Forgejo issue trackers.
Related, let's drop the extraneous 10ms delay I introduced back in PR2072. It didn't exist there, and there are two other 10ms delays around it (one after 1ms RST pulse, one near return from `cortexm_reset()`).
## 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