The Dreaded “Cannot connect to ST-LINK!” Error Message

I got an STM32F4-Discovery board a while ago, but have not had much time to play with it. So the other day I decided to check out the GPIO functions to get myself familiarized with the board.

STM32F4-Discovery breaks out most (more on this later) of its 16-bit GPIO pins (GPIOA through GPIOE) so it is easy enough to use these GPIO pins to interface external devices.

Using the GPIOs is also fairly straightforward. For instance, to toggle PB0 we can initialize port B (GPIOB) and configure PB0 as an output and use either BSRRL/BSRRH in GPIOB or GPIO_SetBits function to toggle the pin. Here is an example using Atollic TrueSTUDIO:

#include <stm32f4xx.h>
#include <stm32f4xx_gpio.h>

void main()
    GPIO_InitTypeDef GPIO_InitStruct;

    RCC_AHB1PeriphClockCmd(RCC_AHB1Periph_GPIOB, ENABLE);
    GPIO_InitStruct.GPIO_Pin = GPIO_Pin_0;
    GPIO_InitStruct.GPIO_Mode = GPIO_Mode_OUT; 
    GPIO_InitStruct.GPIO_Speed = GPIO_Speed_100MHz;
    GPIO_InitStruct.GPIO_OType = GPIO_OType_PP; 
    GPIO_InitStruct.GPIO_PuPd = GPIO_PuPd_NOPULL;
    GPIO_Init(GPIOB, &GPIO_InitStruct);

    while (1)
        GPIOB->BSRRL = GPIO_Pin_0;
        GPIOB->BSRRH = GPIO_Pin_0;

The code above generates a square wave of roughly 4 MHz at PB0 by rapidly toggling the pin, nothing fancy.

Curiously enough, the discovery board breaks out all the GPIO pins except PA11 and PA12. At first I did not pay enough attention to this and configured all port A pins as output in a test setup. After uploading the code I quickly realized that I had lost the ability to debug and upload programs through USB.

Realizing that I might have “bricked” the device somehow, I used the STM32 ST-Link utility to try loading a test HEX file just to be sure. But all I got was the dreaded “Cannot connect to ST-LINK!” error message. At this point, I started wondering whether by writing to PA11 and PA12 could have caused this problem.

The STM32F4-Discovery board uses either SWD (Serial Wire Debug) or JTAG for programming, and a bootloader is in place for serial communications via the USB. And by default, programming is done via USB using SWD. By checking the user’s manual, it became clear to me that the issue was caused by re-configuring PA11 and PA12 since these two pins are dedicated as DM DP pins for USB communications. By re-configuring these pins in code we essentially interfered with the USB communication mechanism. This may be the reason why these two pins were not broken out in the first place.


Fortunately, this problem can be corrected using the STM32 ST-Link UTILITY. When the USB cable is first plugged in, hold down the reset button and upon release immediately select Target->Erase Chip. You may need to try this a few times to get the timing correctly. Once the chip is erased, the bootloader will be able to utilize the USB connection correctly and you will be able to use USB port to program your STM32F4-Discovery board again.

Be Sociable, Share!


  1. Francesco says:

    Hi Kerry,
    you have saved my board! Many thanks.
    Just a comment about the sequence. After a few no successfull trials I’ve tried to release the button after having pressed the Erase Chip option.
    This worked for me immediately. Thanks again!

  2. Tom says:

    Yesterday i had this problem.
    I configured the PA11 and PA12 Pin (which is apparently used for the usb connection) and then Keil does’nt recognize the discovery board anymore.
    I played over one hour with the “Earse Chip” function, but i didn’t work (I used the Segger JLink Ultra +).
    Then, after 3 hours searching, I fund a solution, a very easy solution.
    So I saved my current board and the board, which I thought I killed it.

    When the problem really is that your programm code is wrong (in my situation the configure of PA11 and PA12) the only thing what you must do is to connect the BOOT0 Pin with High (3V from an other pin of your board), then your board will not load the false programm anymore and the USB-Connection is working again. Then you can programm your board with a right programm and all things a working again. The summary:

    1.) Disconnect your board from usb or other voltage supply.
    2.) Connect the BOOT0 Pin with High (3V).
    3.) Plugin the usb cable again.
    4.) Download a write programm to the board which doesn’t configure the PA11 and PA12 Pins.
    5.) Disconnect the usb again.
    6.) Disconnect the BOOT0 from High (3V) again.
    7.) Plugin the USB again and see if the board works normal again.

    I hope I could help you and unterstand what I have written. I am not the best in english ^^

  3. Prasan says:

    It worked for me first time. I tested the hex code and all things worked fine. But again I started getting the same error message and this chip erase functionality doesn’t work. Looking for some permanent fix.

    I’m using STM32F3. Referring Tom’s solution, my board doesn’t have BOOT0 pin as a header, it is permanently soldered through a bridge. So this is again not an option for me.

  4. Ales says:

    Thanks, you saved my day!

    I had troubles with erasing the chip (probably bad timing in releasing pushbutton and mouse clicking) so I did it this way:

    ST-Link Utility -> Target -> Automatic mode -> Full chip erase option -> Start -> Now reset the board with bushbutton whenever you want…

    Have a nice day!

  5. desperate says:

    Please help. I have stm32vldiscovery. When i try to connect it via STM32 ST LINK UTILITY i get: error Can not connect to target. Please select Connect under reset mode from target-> settings menu and try again. If you re trying to connect to a low freuqency application please select a lower SWD freuqency mode from Target-> Settings menu. Wierd part is that i can upgrade firmware but only after i plug in cable after i go ST LINK-> Firmware upgrade. Also i can do full chip erase like ales described. I’m going crazy

  6. Jay says:

    BOOT0 to 3.3V FTW! Thank you!

  7. Waleed Nassar says:

    Well, I know it is a 5 years old post. But I can’t help thanking you. you saved me a big day. THANKS

  8. Piotr says:


    I have a similar problem. I tried many solutions but it still doesn’t work :( Still getting ‘Cannot connect to the target…’
    Anybody maybe could give me an advice?


  9. Brad says:

    Be sure to check the jumper settings. I spent an hour trying different fixes that I saw online before I realized that the PWR jumper was set to use an external power source instead of the USB voltage. This allowed the ST-LINK to connect and update firmware, but the MCU wasn’t ever powered, preventing all programming and erasure.

Leave a Reply