Skip to content
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

blackpill-f4: change slew speed frequency cutoff to 3 MHz #2073

Merged
merged 1 commit into from
Feb 11, 2025

Conversation

birkenfeld
Copy link
Contributor

Detailed description

In #1717, the output slew rate for the JTAG/SWD pins on bluepill-f4 was changed to 25MHz. This leads to failing target scans even with low bus speeds when the target isn't connected by e.g. two ground wires. In #2065, this was mitigated by switching output slew rate depending on requested speed. However, the cutoff was set at 2MHz, while the default bus speed is 3MHz. This keeps the bad out-of-the-box experience for users that don't know or are not able to set their own bus frequency.

The 2MHz slew rate is fine for a signal frequency of 3MHz, see datasheet DS10314.

cc @ALTracer

Your checklist for this pull request

Closing issues

@dragonmux
Copy link
Member

dragonmux commented Feb 11, 2025

Because the datasheet only gives us a guarantee that this slew rate will work to 2MHz (this is why the constant is "2MHz", not "4MHz" or another frequency; even if your specific silicon can do better, at your given voltage and temperature conditions, this does not mean all of the silicon used on Black Pills can at all voltages and temperatures), we would prefer the default frequency be dropped for this platform rather than bumping the slew cut-over point.

No need to close this PR to do that though, just switch the default target_clk_divider for this platform to one that achieves approximately 2MHz. Given how that particular global gets its default value, we would suggest making this change in the platform's platform_init() function toward the end of its execution.

@dragonmux dragonmux added HwIssue Mitigation Solving or mitigating a Hardware issue in Software Foreign Host Board Non Native hardware to runing Black Magic firmware on labels Feb 11, 2025
@dragonmux dragonmux added this to the v2.0 release milestone Feb 11, 2025
@ALTracer
Copy link
Contributor

we would prefer the default frequency be dropped for this platform

I agree with that approach, @birkenfeld edit this commit to reduce 3000000 to 2000000 argument in last call in platform_init() while keeping PR open, then I'll also agree with you. The fact that it initially worked for me on my wiring was one of strongest reasons this was contibuted (and lack of wide testing). Apparently we can't rely on 25°C and 3.3 Vdd.

so that the probe works on more targets out of the box (see blackmagic-debug#2065).
@birkenfeld
Copy link
Contributor Author

Done!

Copy link
Member

@dragonmux dragonmux left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, merging. Thank you for the contribution!

@dragonmux dragonmux merged commit 3148437 into blackmagic-debug:main Feb 11, 2025
36 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Foreign Host Board Non Native hardware to runing Black Magic firmware on HwIssue Mitigation Solving or mitigating a Hardware issue in Software
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants