search

grblHAL / STM32F1xx

grblHAL driver for ST STM32F1xx (Redpill, Bluepill)
Other
40 stars 27 forks source link

Can't use SWD on BTT SKR Mini E3 V2.0 #50

Closed dgangola closed 7 months ago

dgangola commented 7 months ago

The processor seems to be driving SWCLK, and SWDIO low. This pretty well kills the SWD debugger. The stock firmware has a two-second delay after reset before driving SWCLK low, (which in turn pulls up USB D+). SWDIO is not driven low with the stock firmware. I've tried lifting the BOOT0 pin (it's tied directly to GND) and pulling it high. After a reset, SWCLK and SWDIO are high, and the debug session will start, but fail at the end. (Possibly because the processor is not executing the expected code.) Perhaps a delay similar to the stock firmware could be implemented? (debug-by-printf and swapping sd cards is getting old)

terjeio commented 7 months ago

SWCLCK is driven low here, the 2 second delay could be added there? hal.delay_ms(2000, NULL);

dgangola commented 7 months ago

Yes, that works as advertised. SWDIO (PA13) is still driven low. I don't see a reference to that pin anywhere. It seems like driving it low is a default action.

terjeio commented 7 months ago

It seems like driving it low is a default action.

It is high level on my boards running grblHAL - with different board maps. I do not have a SKR board so cannot easily debug - must be bad code somewhere. Related to the TMC issue?

dgangola commented 7 months ago

The problem is the bootloader. Once the bootloader is removed (overwritten), you can connect and debug. For me, ST-Link devices (official and clones) did not "want" to connect, no matter what I tried. I tried de-initting the pins, and then also setting SWD enable and/or JTAG enable in AFIO_MAPR. For what it's worth, I placed the following code in board_init() in btt_skr_mini_e3_2.0.c:

#ifdef RELEASE_SWD_PINS
    HAL_GPIO_DeInit(GPIOA, GPIO_PIN_14|GPIO_PIN_13);
//    __HAL_AFIO_REMAP_SWJ_NOJTAG();
    __HAL_AFIO_REMAP_SWJ_ENABLE();
#endif

I also removed C30, the reset timing cap, to try to improve the reset timing with "connect_under_reset" options.
Before I could learn what else the problem could be, I tried a Segger J-Link. It connected immediately, the bootloader was gone, and I was debugging.

Mind you, the board does not support SWD and USB communication at the same time. (Unless you modify the board. I connected GPIO PB5 to the gate of U7 to pull D+ high, and modified the code in board_init() appropriately.)