boards: Common STM32 programmer/debugger/serial config #12697
Conversation
|
Those are the boards not yet included in the PR. So the claimed de-duplication will finally yield some reducing in lines of code, when the transition is complete. |
|
|
||
| # this board uses openocd by default | ||
| DEBUG_ADAPTER ?= stlink | ||
| STLINK_VERSION ?= 2 |
There was a problem hiding this comment.
This specific configuration is lost with the current change: the default is to use st-link2.1. I know the distinction no longer exists is OpenOCD master and some people are trying to merge the config (#11824) but the default version of OpenOCD is still 0.10 on release/LTS Linux distros.
At least, this PR should not change this.
There was a problem hiding this comment.
The bluepill/blackpill has no integrated st-link. Instead, the user will have to provide an external st-link. Thus, to me it makes sense to have it default to version 2.1, which is the more common hardware. Users that use an old versions of the st-link and at the same time an old version OpenOCD can still set this manually.
There was a problem hiding this comment.
I totally with how we should deal with ST-Link, don't worry. It's just that the default version is changed. What I'm saying is that, for clarity, this should be in its own commit or in its own PR. Because for the moment, the commit doesn't mention the reason why it's removed (the default st-link version).
There was a problem hiding this comment.
I added the change of the ST-Link version as own commit on top and added the reasoning to the commit message details.
There was a problem hiding this comment.
Thus, to me it makes sense to have it default to version 2.1, which is the more common hardware.
Is it though? The common cheap ST-Link probe reports as STLINK V2J34S7 (API v2) VID:PID 0483:3748.
Unfortunately it seems like both by ST-Link (v2) probes are broken (can't flash with either config) but replacement from China is on it's way.
I wish OpenOCD would make another release already so we could just use interface/stlink.cfg and not care about the version difference.
There was a problem hiding this comment.
Hmm, I have the same cheap programmers and they are (or at least were prioir to the BMP upgrade) v2.1. I bought like 40 of those for students from different vendors and every vendor had his own PCB design with a different pinout. It was quite a mess to make Black Magic Probes out of them due to the different pinouts. Apparently they also differ in software...
I'll adapt to keep it v2 for now and we can later clean up, if OpenOCD ever starts making new releases again.
There was a problem hiding this comment.
If it works with those probes with STLINK_VERSION ?= 2-1 than you can keep it - I'm just saying I can't flash it with either version with my probes, so I can't tell if it makes a difference.
There was a problem hiding this comment.
Sounds like the reset signal is not properly send, likely due a misconfiguration in the ST-Link firmware. I had the same issue with mine. Try pressing and holding the reset button and release the button when OpenOCD is trying to connect the bluepill during "make flash". That should work
Added common configuration for the programmer, debugger and serial for STM32 based boards.
0ee9c71 to
59d73f4
Compare
|
Sounds like the RST signal is not received. I also had some that didn't
provide that signal properly. Keep the reset button pressed and run
"make flash". Relieve the reset button only when OpenOCD is starting to
contact the BluePill. This way it should work even without RST signal.
|
|
@benpicco: Sorry for the long delay. I actually wanted to revert the version change, but forgot about this PR. I'll do it now. |
59d73f4 to
c510ad8
Compare
|
OK. I just dropped the last commit that added the version change. Hopefully, |
|
@benpicco: Is your ACK still valid? |
|
Without the version change there is nothing controversial about this. |
Contribution description
De-duplicated code by adding a common configuration for setting the programmer/debugger/serial. This also brings some new programmer support to other boards.
Testing procedure
Programmering, debugging and
make termshould still work as previouslyIssues/PRs references
None. (But some follow up PRs are needed to also apply the config for other boards. But to keep testing to a reasonable amount, I purposely left a bunch of boards out for now.)