Trying to setup CLion environment with ST-LINK_gdbserver

[nilssonm]

Hi everyone,

I am a little desperate due to my problem in debugging my programs on my newly purchased STM32N6570-DK discovery board. I am running all the software on my Macbook Pro 2024 with M4 Max processor with macOS Sequoia 15.6.1.

I have been using STM32 Cube IDE version 1.19 and have successfully managed to debug a binary. It was the classic blink example. It seems to be working fine in the Cube IDE but not when I am trying to setup a debug target in my CLion environment. I have been comparing all of the parameters to the debugger between Cube IDE and CLion and tried using exact same. I have also tried using the separate CLT package for the programmer and debugger from ST.

It always results in a timeout and releasing debugger with a disconnection and the following message:

Error in initializing ST-LINK device.
Reason: Target not halted.
GDB Server stopped, exit code 9

Anyone having ideas?

[Ghofrane GSOURI]

Hello @nilssonm 

Thank you for reaching out regarding your setup with CLion. Our support is focused on STM32CubeIDE and the tools officially provided by STMicroelectronics. While we understand the importance of integrating with other development environments, we are unable to provide detailed assistance for third-party IDEs such as CLion, as it falls outside our official support scope.

For issues related to STM32CubeIDE, we are more than happy to assist you. If you encounter any problems or have questions about STM32CubeIDE, please let us know, and we will do our best to help.

THX

Ghofrane

[nilssonm]

Hello,

I would like to say that this is not a CLion problem. I only mentioned it because of the context. I would like to describe this as a problem when I am trying to use the command line tools from ST instead of running all in the CubeIDE. I am getting this error when starting my application using the command line tools to debug. I have been able to successfully debug the application when clearing all pin-assignments in the CubeMX tool before using the generated code, but because I thought that I could let the default assignments be when running this on the Discovery board results in the problem described.

Is there some default assignment that could be a conflict with debugging?

Thanks,

Mats

[Ghofrane GSOURI]

Hello @nilssonm 

As shown in the following screenshot 

CubeMX is warning about a debug conflict:

Debug Conflict with:
PE0 mapped with GPIO_Output and
PA15(TDI) mapped with ULTCD_RS and/or
PA05 mapped with GPIO_input and/or
PD0 mapped with GPIO_input and/or
PD1 mapped with GPIO_input

This prevents the debugger from working because the hardware cannot use the same pin for both debugging and another peripheral at the same time.
This is the root cause of your "Target not halted" and ST-LINK errors.

CubeMX is intentionally designed to offer flexibility, allowing you to customize or reassign pin functions according to your project’s requirements. While it provides warnings about such conflicts, it leaves the final decision to you.

THX

Ghofrane

[nilssonm]

Hello,

Thanks for the quick response.

This is good to know but I have now confirmed that I was wrong about this. I have tried so many configurations that my memory couldn't remember all. I cleared the pins in a project that only have a GPIO configuration for the pin PO1 and the built in LED on the board. I have only two rows in main for the FSBL-part and no Appli-part. The result is still not working for me when trying with VS-Code this time with the plugins from ST that should do it.

Main-function looks like this:

int main(void)
{

  /* USER CODE BEGIN 1 */

  /* USER CODE END 1 */

  /* MCU Configuration--------------------------------------------------------*/
  HAL_Init();

  /* USER CODE BEGIN Init */

  /* USER CODE END Init */

  /* Configure the system clock */
  SystemClock_Config();

  /* USER CODE BEGIN SysInit */

  /* USER CODE END SysInit */

  /* Initialize all configured peripherals */
  MX_GPIO_Init();
  MX_ICACHE_Init();
  /* USER CODE BEGIN 2 */

  /* USER CODE END 2 */

  /* Infinite loop */
  /* USER CODE BEGIN WHILE */
  while (1)
  {
    HAL_GPIO_TogglePin(LED_GPIO_Port, LED_Pin);
    HAL_Delay(500);
    /* USER CODE END WHILE */

    /* USER CODE BEGIN 3 */
  }
  /* USER CODE END 3 */
}

The following is the result from the debugger:

Temporary breakpoint 1, main () at /Users/mats/School/EL038A/NEW-TRY/stm32n6-cpp-crack-classifier/FSBL/Core/Src/main.c:74
74	  HAL_Init();
GDB session, device event: 3
GDB session, device event: 1
ST-LINK device status: Failed to get status, Target not responding, retrying... 19
9
Target is not responding, retrying...
ST-LINK device status: Failed to get status, Target not responding, retrying... 32
Target is not responding, retrying...
ST-LINK device status: TMO (Max Retries)
GDB session, device event: 2
GDB session terminated: Device connection lost
GdbSessionManager, session terminated: 1
GdbSrv, last session terminated, signal dispose
Stopping port 61234
Cleanup session: 1
GDB session disposed: 1
Remote connection closed
Received stop for port 61234, not accepting new connections.
GdbSrv, deInit entry.
Shutting down...
GdbSessionManager, deInit entry.
Stm32Device, pollAndNotify stopped
GdbSessionManager, deInit exit
SwvSrv deInit entry
Stopping port 61235
Received stop for port 61235, not accepting new connections.
SwvSrv deInit exit
Stm32Device, closeDevice() entry
Stm32Device, closeDevice() exit
Stm32Device, deInit success
GdbSrv, deInit exit.
Exit.
cube has exited with code 0