Feature: SWD delay/frequency calibration #1955

ALTracer commented 2024年10月12日 16:28:00 +02:00 (Migrated from github.com)

Detailed description

• This is a new feature unused during actual debug.
• The existing problem is most in-tree probe platforms misrepresent the SWCLK setting returned by platform_max_frequency_get() -- could run much slower or much faster.
• This PR solves it for SWD but not JTAG by implementing an example remote monitor command (platform-specific) to emit example waveforms (in a blocking fashion, like always) and measure the CPU cycles it took (via DWT or TIM2 32-bit).

Tested on blackpill-f411ce, stlink/swlink (GD32F1, GD32F3) and f072 (32F072B-Disco) to enhance precision after correcting timing_stm32.c, both no_delay special case and clk_delay constants. Checks out with fx2la to <5%. I also tried emitting more than one SWD LINEREST (four) and I try to compensate for the static overhead of function calls, by subtracting eyeballed cycles taken. STM32F4 has 1-KiB ART cache, STM32F1 doesn't, GD32F1 runs from 0WS flash. STM32F0 also tested. Test a couple times to negate cold flash cache and IRQ uncertainty. JTAG could be implemented as a seprate command. Note that I did not use native linear regression calibration workflow, as the normal swdptap behaviour can be approximated as a linear law with no_delay point special-cased.

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) and should not affect it
• 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 new feature unused during actual debug. * The existing problem is most in-tree probe platforms misrepresent the SWCLK setting returned by `platform_max_frequency_get()` -- could run much slower or much faster. * This PR solves it for SWD but not JTAG by implementing an example remote monitor command (platform-specific) to emit example waveforms (in a blocking fashion, like always) and measure the CPU cycles it took (via DWT or TIM2 32-bit). Tested on `blackpill-f411ce`, `stlink`/`swlink` (GD32F1, GD32F3) and `f072` (32F072B-Disco) to enhance precision after correcting `timing_stm32.c`, both no_delay special case and clk_delay constants. Checks out with fx2la to <5%. I also tried emitting more than one SWD LINEREST (four) and I try to compensate for the static overhead of function calls, by subtracting eyeballed cycles taken. STM32F4 has 1-KiB ART cache, STM32F1 doesn't, GD32F1 runs from 0WS flash. STM32F0 also tested. Test a couple times to negate cold flash cache and IRQ uncertainty. JTAG could be implemented as a seprate command. Note that I did not use `native` linear regression calibration workflow, as the normal swdptap behaviour can be approximated as a linear law with no_delay point special-cased. ## Your checklist for this pull request * [x] I've read the [Code of Conduct](https://github.com/blackmagic-debug/blackmagic/blob/main/CODE_OF_CONDUCT.md) * [x] I've read the [guidelines for contributing](https://github.com/blackmagic-debug/blackmagic/blob/main/CONTRIBUTING.md) to this repository * [x] It builds for hardware native (see [Building the firmware](https://github.com/blackmagic-debug/blackmagic?tab=readme-ov-file#building-black-magic-debug-firmware)) * [x] It builds as BMDA (see [Building the BMDA](https://github.com/blackmagic-debug/blackmagic?tab=readme-ov-file#building-black-magic-debug-app)) and should not affect it * [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

This pull request doesn't have enough approvals yet. 0 of 1 approvals granted.

You are not authorized to merge this pull request.