SWDIO and SWCLK issue with blackpill STM32F411 ?

[camelator]

Hi, I already installed blackmagic debug on my bluepill STM32f101, compiled on target swlink to directly use the pins SCK/DIO of the board. I would like like to do the same on a blackmagic debug on a blackpill STM32F411. Unfortunately, the exposed pins for debugging mode are not SCK/DIO so I tried to change the config file:

I can see on pinout diagram that SCK is on PA14 and DIO on PA13. I can also see that the register definition is in the file blackpill-f4.h so I tried to change part of the code like that:

define TMS_PORT GPIOA

define TMS_PIN GPIO13

define SWDIO_PORT TMS_PORT

define SWDIO_PIN TMS_PIN

and

define TCK_PORT GPIOA

define TCK_PIN GPIO14

define SWCLK_PORT TCK_PORT

define SWCLK_PIN TCK_PIN

But unfortunately it does not work.

compilation options with the modified file are: make PROBE_HOST=blackpill-f411ce ENABLE_RTT=1

Any help will be really appreciate,

many thanks.

[dragonmux]

Unsure quite what you're aiming to achieve, but the debug interfaces exposed by BMD are bit-banged so there is absolutely no reason or need for it to be mapped over the processor's SWD interface - if anything, doing that turns off the ability to debug the probe with no other benefits of any kind.

When you say "SCK" and "DIO", we presume you actually mean SWCLK and SWDIO at least.. "SCK" in particular could mean a SPI bus clock, I²C clock, or USART clock, which is why the project always uses the term SWCLK to refer explicitly and specifically to a SWD clock pin.

It would be helpful if you could include some information on what exactly you're trying to run BMD on (if it's actually a Black Pill, which of the 3 variants, for example?) and what pinout is exposed. The project has good documentation on how those boards are normally pinned out for use with the firmware.

[camelator]

Dear Dragonmux, many thanks for your comment, well... yes I agree I am not an expert of Blackmagic-debug as I am more a simple user (I have to say it is an amazing tool, and I use it for years!) To clearly describe what I am trying to do: on the bluepill, it is possible to compile the project for 2 targets : stlink or swlink. Using the bluepill on swlink looks like the better way for me, because we can directly use the pins at the opposed face of the USB plug (GND,SCK,DIO,3V3). So I made a special plug, and linked blackpill DIO to target DIO, SCK to SCK, GND to GND, and voila! It is easiest to build a cable, it is easiest to memorise... But it looks like there is not enough memory to compile blackmagic debug with flag ENABLE_RTT on bluepill.

As I have some blackpill STM32F411 I'd like to have the same 'swlink' behaviour : I's like to use the pins SCK,DIO at the opposed face of the USB plug, and I would like to also have the RTT mode.

I have these two models of blackpill: https://stm32world.com/wiki/Black_Pill https://www.linkedin.com/pulse/detailed-explanation-stm32f4-series-mcu

Is it possible ? Do you know how to do that?

[dragonmux]

You're going to have to edit the blackpill platform in a highly unsupported way to do it, and in the process knee-cap yourself to SWD only, no target UART, no JTAG, no SWO [we're saying this so you are aware of the limitations you are imposing on yourself - and why we think it's a terrible idea].

It looks like you're using the blackpill-f411ce platform which does indeed match your board. Given this, you're looking at a change like:

    gpio_set_af(GPIOA, GPIO_AF0, GPIO13 | GPIO14);
    gpio_mode_setup(SWCLK_PORT, GPIO_MODE_OUTPUT, GPIO_PUPD_NONE, SWCLK_PIN);
    gpio_mode_setup(SWDIO_PORT, GPIO_MODE_INPUT, GPIO_PUPD_NONE, SWDIO_PIN);
    gpio_set_output_options(SWCLK_PORT, GPIO_OTYPE_PP, GPIO_OSPEED_25MHZ, SWCLK_PIN | SWDIO_PIN);

applied to src/platforms/common/blackpill-f4/blackpill-f4.c line 90. We have not tested this but it looks like it /should/ work to reconfigure the I/O's appropriately. Edit only the SWDIO and SWCLK macros, not the JTAG ones - otherwise you'll screw up the bitbanging for JTAG if you ever feel like breaking out the platform listed pins for that.

NB: Doing this will entirely disable the ability to ever debug this processor ever again. You will have to use another adaptor in connect-under-reset mode with the reset pin hooked up if you need to rescue it. This is your "Danger, Will Robinson, Danger" note and why it is unsupported.

[camelator]

dragonmux, many thanks for the code you shared, I inserted it llike that: ` gpio_set_output_options(TDI_PORT, GPIO_OTYPE_PP, GPIO_OSPEED_25MHZ, TDI_PIN); gpio_set_output_options(TDO_PORT, GPIO_OTYPE_PP, GPIO_OSPEED_25MHZ, TDO_PIN); gpio_set_output_options(TCK_PORT, GPIO_OTYPE_PP, GPIO_OSPEED_25MHZ, TCK_PIN); gpio_set_output_options(TMS_PORT, GPIO_OTYPE_PP, GPIO_OSPEED_25MHZ, TMS_PIN);

gpio_set_af(GPIOA, GPIO_AF0, GPIO13 | GPIO14);
gpio_mode_setup(SWCLK_PORT, GPIO_MODE_OUTPUT, GPIO_PUPD_NONE, SWCLK_PIN);
gpio_mode_setup(SWDIO_PORT, GPIO_MODE_INPUT, GPIO_PUPD_NONE, SWDIO_PIN);
gpio_set_output_options(SWCLK_PORT, GPIO_OTYPE_PP, GPIO_OSPEED_25MHZ, SWCLK_PIN | SWDIO_PIN);

/* Set up LED pins */

` But it look likes it produces the same result, black magic is successfully found, but it can't any board attached on the debugger :( Do I have to change something in header files as I tried before?

Looking for BlackMagic port... Auto-detected: /dev/ttyACM0 Uploading .pio/build/blackpill_f411ce/firmware.elf SWD scan failed! Failed Attaching to Remote target failed Loading section .isr_vector, size 0x198 lma 0x8000Load failed 0warning: One or more sections of the target image does not match 0the loaded file 0

[dragonmux]

Do I have to change something in header files as I tried before?

Yes, "Edit only the SWDIO and SWCLK macros, not the JTAG ones - otherwise you'll screw up the bitbanging for JTAG if you ever feel like breaking out the platform listed pins for that." - that affects what you did here:

define TMS_PORT GPIOA

define TMS_PIN GPIO13

define SWDIO_PORT TMS_PORT

define SWDIO_PIN TMS_PIN

and

define TCK_PORT GPIOA

define TCK_PIN GPIO14

define SWCLK_PORT TCK_PORT

define SWCLK_PIN TCK_PIN

Only the SW* macros are permitted to be changed here, you need to put the JTAG ones (TCK and TMS) back how they were so the JTAG pin setup block doesn't screw things up for you. This is still not guaranteed to be fully working either as it may require further poking the alternate function registers like swlink does https://github.com/blackmagic-debug/blackmagic/blob/d9a4030b94fe9cf95dc51c8b28d802b41a8ab89f/src/platforms/swlink/platform.c#L63-L67

[camelator]

dragonmux, You are right, it is not working. Well, I'll stay on my bluepill without RTT mode... Having a debugger without RTT is still a good option. Many thanks

[ALTracer]

If you wanted to incompatibly break the platform header in your local working copy -- please at least do it properly :) #define SWDIO_MODE_REG_MULT_PA13 (1U << (13U << 1U)) #define SWDIO_MODE_REG_MULT SWDIO_MODE_REG_MULT_PA13 is the missing piece, I believe. Sometime before, swapping just the TMS and TCK defines may have worked because there was a costly gpio_mode_setup() function call everytime swdptap commanded a bus turnaround.

Also of note that platform.c does not use SWDIO_PIN nor SWCLK_PIN, only TMS_PIN and TCK_PIN. Doing gpio_set_af(GPIOA, GPIO_AF0, GPIO13 | GPIO14); will effectively re-map some of DP pins back. There is no F103-style AFIO_MAPR SWJ_CFG on F401/F411. No changes to platform.c code are thus needed. @camelator Please try either this or PR1798 and report back whether it works and RTT is better (I measured about 150 kchars/s). A bluepill has much less ram and is prone to crashing especially because (compared to native) there is an 8 KiB traceswo async idle buffer at all times, so heap is even more constrained. Caveat that you really can't inception-debug under this pinout. @dragonmux Thanks for the efforts but did you test this on your Nucleo-F411RB? I despise swlink pinout but it is what it is, see new PR.

[dragonmux]

We are neither set up to test such a change, nor have the time and bandwidth available with our other obligations - hence the "We have not tested this" in our replies above.

Also of note that platform.c does not use SWDIO_PIN nor SWCLK_PIN, only TMS_PIN and TCK_PIN. Doing gpio_set_af(GPIOA, GPIO_AF0, GPIO13 | GPIO14);

Yes, hence having the user define macros for the SWD pins specifically and then using them in our snippet..

[camelator]

Hi AlTracer & dragonmux, sorry for the delay, I successfully ran PR1798. I didn't tested RTT yet but the debugger works perfectly with the SWDIO_PIN & SWCLK_PIN Thanks a lot !