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

Add option to turn SWIM/RST into UART RX/TX #396

Closed
wants to merge 1 commit into from

Conversation

silkeh
Copy link
Contributor

@silkeh silkeh commented Oct 1, 2018

This PR allows building for stlink with SWIM_AS_UART=1, which enables the use of the
SWIM and RST ports as RX and TX on cheap ST-Link V2 clones.

This is done by using USART1 (on the alternative port) instead of USART2.

Building for `stlink` with `SWIM_AS_UART=1` now enables the use of the
SWIM and RST ports as RX and TX on cheap ST-Link V2 clones.

This is done by using USART1 on the alternative port instead of USART2.
@UweBonnes
Copy link
Contributor

This is already done in the swlink. Did you test it?

@silkeh
Copy link
Contributor Author

silkeh commented Oct 1, 2018

@UweBonnes Yes, these changes have been tested on a cheap ST-Link/V2 clone.

The swlink does the remap with AFIO_MAPR |= AFIO_MAPR_USART1_REMAP in UART_PIN_SETUP() instead of calling gpio_primary_remap() (which this PR does), which is functionally the same.

@UweBonnes
Copy link
Contributor

Your last explanation does not make clear to me why you don't want to use the swlink platform. Please be more specific. #395 also brings up the swlink platform up to date. The stlink platform already has to distigush many platform and does not do it very good. Adding another variant will make the pending cleanup more difficult.

@silkeh
Copy link
Contributor Author

silkeh commented Oct 1, 2018

@UweBonnes I'm sorry, it was unclear to me what you were asking.

I have tested the swlink platform (with the patches from #395) and while the serial connection works, the debugger does not. With this PR both work.

@UweBonnes
Copy link
Contributor

Debugger does not work is not specific. SWD or JTAG? Connections as mentioned in README.md of #395? What target?

@silkeh
Copy link
Contributor Author

silkeh commented Oct 1, 2018

SWD. Connections as labelled.

I see the README.md from #395 has SWDIO/SWCLK on PA13/PA14, which is not compatible with the stlink platform, which has SWDIO/SWCLK on PB14/PA5.

@UweBonnes
Copy link
Contributor

But SWDIO/SWCLK on PA13/PA14 does come handy as the the "STM32F103 Minimum System Development Board" aka bluepill has these pins already available on P2. So no need to solder anything if you only want SWD.

@silkeh
Copy link
Contributor Author

silkeh commented Oct 1, 2018

For a bluepill I agree that layout is much better. This PR is just a modification for the cheap metal STlink/V2's though, which are a bit less customizable

@UweBonnes
Copy link
Contributor

You mean board that also are known as "baite"? I think "baite" boards should be handled like a real stand-alone stlink adapter ( the white one).
Is there any schematics of the board you talk about?

@silkeh
Copy link
Contributor Author

silkeh commented Oct 1, 2018

No, I'm talking about the one described in #62

@UweBonnes
Copy link
Contributor

Argh: Another variant...

@UweBonnes
Copy link
Contributor

I think, there are 3 variants of STM32F103 boards.

  1. SWIM/JTAG/SWD adapters like the standalone STlink https://www.st.com/content/st_com/en/products/development-tools/hardware-development-tools/development-tool-hardware-for-mcus/debug-hardware-for-mcus/debug-hardware-for-stm32-mcus/st-link-v2.html and all China clones claiming STlink compatibility.
    PC13/14 is open and there are the SWIM connections e.g. PB5 to PB6 and external SWIM connections . USART1 it accessible on the SWIM pins, USART2 is not accessible and USART3 TX and RX both connect to the same SWIM pin.
  2. SWD Only adapters
    Most have PC13 pull low, newer one need to handle PWR_EN. Some early one on the STM32-Discovery has no pull down on PC13, but also no SWIM connections. On newer boards USART2 is accessible on a header and is connected to the debugging target.
  3. SWIM Only and bluepills.
    At least host SWD connections and the SWIM connections are accessible. USART2 is not accessible. USART1 is accessible on the swim connector. However on the bluepill, USART2 is accessible as as any other GPIO not already on a header.

Type 3 is handled in the swlink platform. Host JTAG/SWD pins are reused as target JTAG/SWD pins and SWIM connector for serial via USART1. On the bluepill USART2 can be used for SWO.

Type 2 is handled in the stlink platform. SWD connector can be used obvious, USART1 is used for SWO and USART2 for serial communication. Serial and SWO can coexist.

For type 1 boards, SWO and serial can not coexist. Present stlink platform enables SWO leaving UsbSerial unconnected. SWO input can be used to connect to target SWO or to target serial out. Your patch drops SWO unconditional in exchange to exposing UsbSerial TX. Your patch should mention that consequence!

@UweBonnes
Copy link
Contributor

And the patch should also conditional exclude trace related parts.

@fmckeogh
Copy link

Is there any update on this?

@galileo-pkm
Copy link

This PR does not work with STLink clones as the one described (wrongly I belive) as "baite" in this image:
#504 (comment)
"swlink" serial does work but the SWD debug does not when using "swlink" platform. I tried to modify this PR by comparing it with "swlink" but that got me nowhere. Can someone provide some pointers on how it should be done?

@UweBonnes
Copy link
Contributor

Using TX/RX as proposed puts SWO on the slow uart. SWO on the fats uart is already used outside and changing this will result in confusion for existing users.

@galileo-pkm
Copy link

Using TX/RX as proposed puts SWO on the slow uart. SWO on the fats uart is already used outside and changing this will result in confusion for existing users.

I understand that but I'm asking for some help on how can I do a "private build" and solve my problem. It is much easier to modify code than to cut traces and solder tiny wires to QFN pins ;)

@galileo-pkm
Copy link

Anyone? I tried to modify the master branch and remap the pins (PB8 is connected to SWIM, PB6 to RST) and failed miserably.
How hard can it be for someone familiar with the code to remap 2 pins?

@UweBonnes
Copy link
Contributor

It is hard to help if information is scrambled around, highjacking some other thread. As this is no issue, but a help request, best is your write up your problems in a way that others, not in touch with your problem can understand it. Send it to the mailing list. Yes, there is a BMP mailing list.

And an error report " failed miserably" is not helpfull. What failed how? And what did you check yourself. Are the pins you choose compatible with the remap available on the F103? Do you really have a F103. Bluepills tend to use F101 or even GD32F103.

@galileo-pkm
Copy link

I thought that I was clear with my explanation but I guess I could do it better. Sorry to hijack this issue but I tried seeking help on Discord without much success and I had no idea that there is a mailing list. I will send a message there.
Thanks

@esden esden added BMP Firmware Black Magic Probe Firmware (not PC hosted software) New Host Board New hardware to run Black Magic firmware on labels Dec 19, 2021
@dragonmux
Copy link
Member

dragonmux commented Jun 28, 2022

Hi @silkeh, sorry this PR has dragged on and still hasn't been merged. Thank you for the contribution.

Given this PR is obviously rather old, could we ask you to rebase the changes and add some documentation to the ST-Link platform README.md talking about how to use your change please? We're looking at trying to get this or some variant of it into v1.9

@dragonmux dragonmux added this to the v1.9 release milestone Jun 28, 2022
@dragonmux dragonmux added Enhancement General project improvement HwIssue Mitigation Solving or mitigating a Hardware issue in Software and removed New Host Board New hardware to run Black Magic firmware on labels Jun 28, 2022
@dragonmux
Copy link
Member

Merging this should close #498 which is a duplicate of this PR

@dragonmux dragonmux mentioned this pull request Jun 28, 2022
@dragonmux
Copy link
Member

Given this appears to be a dead PR, we have rescued the contribution to a feature branch where we have rebased it and added some documentation. A new PR that supersedes this one has been opened as #1087.

Sorry to see this grind to a halt because it wasn't addressed in a timely manner, and thank you for the contribution. It is appreciated and we have preserved authorship in the new PR so you will be credited for the work in the release notes.

@dragonmux dragonmux closed this Jun 29, 2022
@silkeh
Copy link
Contributor Author

silkeh commented Jun 29, 2022

@dragonmux thanks for picking this up! Let me know if you need any help.

@dragonmux
Copy link
Member

We hope that, if you find any other things that aren't right or you want to work on, you feel able to contribute in the future.

The project has been handed over from Gareth to 1b² now and is under new maintainership, so you shouldn't see a repeat of what happened with this PR. We are aiming to be responsible and responsive maintainers moving forward.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
BMP Firmware Black Magic Probe Firmware (not PC hosted software) Enhancement General project improvement HwIssue Mitigation Solving or mitigating a Hardware issue in Software
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants