Debugger misses start of the program in STM32CubeIDE

[RPape.1]

When debugging my firmware using STM32CubeIDE, the debugger seems to miss the start of the program. As an example, when I put breakpoints right at the top of main(), they are ignored. It's not only a couple of lines that are affected, but pretty much all the initialization etc. cannot be debugged because breakpoints there do not have an effect.

It seems to me as if the program would start before the debugger is ready/active, therefore debugging is only possible with a delay.

To confirm this, I put the following code at the top of main:

int test = 1;
while(test) 
{
}

The while-loop is not left until I manually change the value of test to 0, which then makes it possible to set breakpoints to other lines following, where breakpoints were ignored before.

This is very frustrating, as it makes debugging very cumbersome.

Also, if I add a specific call to my main() (HAL_DMA_DeInit()), I get the following error, which also seems to be related to gdb...?

Open On-Chip Debugger 0.12.0-rc1+dev-00061-g5e9b46d77 (2022-10-20-14:47) [https://github.com/STMicroelectronics/OpenOCD]
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
srst_only srst_pulls_trst srst_gates_jtag srst_open_drain connect_deassert_srst
 
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : connected to stlink-server
Info : stlink-server API v3, version 2.1.0
Info : STLINK V2J40S7 (API v2) VID:PID 0483:3748
Info : Target voltage: 2.853841
Info : Unable to match requested speed 8000 kHz, using 4000 kHz
Info : Unable to match requested speed 8000 kHz, using 4000 kHz
Info : clock speed 4000 kHz
Info : stlink_dap_op_connect(connect)
Info : SWD DPIDR 0x6ba02477
Info : stlink_dap_op_connect(connect)
Info : SWD DPIDR 0x6ba02477
Warn : target STM32MP157CAAx.ap2 examination failed
Error: Fail reading CTRL/STAT register. Force reconnect
Warn : target STM32MP157CAAx.axi examination failed
Info : stlink_dap_op_connect(reconnect)
Info : SWD DPIDR 0x6ba02477
Info : STM32MP157CAAx.cpu0: hardware has 6 breakpoints, 4 watchpoints
Info : STM32MP157CAAx.cpu1: hardware has 6 breakpoints, 4 watchpoints
Info : gdb port disabled
Info : gdb port disabled
Info : gdb port disabled
Info : starting gdb server for STM32MP157CAAx.cpu0 on 3334
Info : Listening on port 3334 for gdb connections
Info : starting gdb server for STM32MP157CAAx.cm4 on 3333
Info : Listening on port 3333 for gdb connections
Info : accepting 'gdb' connection on tcp/3333
Error: Target not examined yet
Error executing event gdb-attach on target STM32MP157CAAx.cm4:
 
Info : New GDB Connection: 1, Target STM32MP157CAAx.cm4, state: examine deferred
Error: Target STM32MP157CAAx.cm4 not examined yet, refuse gdb connection 1!
Error: attempted 'gdb' connection rejected
shutdown command invoked

In this error, it says STM32MP157CAA, even though I am using an STM32MP153AAB3. The project was probably originally created for an STM32MP157, but as I understand the M4 part should be identical, so it should not cause the problem, right?

The error does not occur if I delay the start of the program using the while-loop from above.

As a debug configuration, I use ST-Link (OpenOCD) through Linux Core (Production Mode).

[Olivier GALLIEN]

Hi @RPape.1​ ,

In Production Mode the firmware is not started by CubeIDE but by OpenSTLInux/Remoteproc.

CubeIDE/OpenOCD just perform an attachement to running target.

So what you observe is the normal behavior and there's no alternative.

The while loop is just the right way to wait for debugger and allow stepping in early stage.

So far it has never been reported as an issue since the early stage can be mature using Engiboot where CubeIDE/OpenOCD load and start the firmware giving full control .

Anyway the issue you report with HAL_DMA_DeInit() is a concern.

Is it working in Engiboot ?

What the purpose of this call ? on which DMA instance ?

Do you properly assigned it to M4 core in Linux DTS ?

Hope it help

Olivier

[RPape.1]

Thank you for your answer.

So far, I haven't been able to successfully use Engiboot.

What would I have to do to make it work?

If I just change the Load Mode in the Debug Configuration, I get the error "Failed to insert all hardware breakpoints" on launch, even if I do not set any breakpoints.

HAL_DMA_DeInit() was called on a UART instance.

Using HAL_DMA_Init(), I always received a timeout in the following part of the function, which I wanted to solve by calling HAL_DMA_DeInit() first so the DMA Stream would be disabled.

    /* Check if the DMA Stream is effectively disabled */
    while ((((DMA_Stream_TypeDef *)hdma->Instance)->CR & DMA_SxCR_EN) != 0U)
    {
      /* Check for the Timeout */
      if ((HAL_GetTick() - tickstart) > HAL_TIMEOUT_DMA_ABORT)
      {
        /* Update error code */
        hdma->ErrorCode = HAL_DMA_ERROR_TIMEOUT;
 
        /* Change the DMA state */
        hdma->State = HAL_DMA_STATE_ERROR;
 
        return HAL_ERROR;
      }
    }

For now, I have moved away from using DMA and I use interrupts instead, although if someone has a solution for the problem I would still be interested.

[Olivier GALLIEN]

Hi @RPape.1​ ,

>> If I just change the Load Mode in the Debug Configuration, 

Maybe so obvious you didn't mention it, but just to be sure, did you change the target boot pins?

Did you try restart CubeIDE ?

Can you share CubeIDE version, HAL version and details of your code application ?

Request of DMA_Deinit is very strange after a platform reset.

Thanks,

Olivier

[RPape.1]

Oh okay, I was not aware of the boot pins so far, thanks for pointing that out.

Changing the boot pins on our target is apparently not so easy and would require soldering, so I would abandon that idea for now.

CubeIDE is v1.11.0, HAL is v1.6.0.

As I said, HAL_DMA_Init() / DeInit() was called on a UART instance. This is my initialization code for it:

static void MX_UART4_Init(void)
{
  huart4.Instance = UART4;
  huart4.Init.BaudRate = 9600;
  huart4.Init.WordLength = UART_WORDLENGTH_8B;
  huart4.Init.StopBits = UART_STOPBITS_1;
  huart4.Init.Parity = UART_PARITY_NONE;
  huart4.Init.Mode = UART_MODE_TX_RX;
  huart4.Init.HwFlowCtl = UART_HWCONTROL_RTS;
  huart4.Init.OverSampling = UART_OVERSAMPLING_16;
  huart4.Init.OneBitSampling = UART_ONE_BIT_SAMPLE_DISABLE;
  huart4.Init.ClockPrescaler = UART_PRESCALER_DIV1;
  huart4.AdvancedInit.AdvFeatureInit = UART_ADVFEATURE_NO_INIT;
  if (HAL_UART_Init(&huart4) != HAL_OK)
  {
    Error_Handler();
  }
  if (HAL_UARTEx_SetTxFifoThreshold(&huart4, UART_TXFIFO_THRESHOLD_1_8) != HAL_OK)
  {
    Error_Handler();
  }
  if (HAL_UARTEx_SetRxFifoThreshold(&huart4, UART_RXFIFO_THRESHOLD_1_8) != HAL_OK)
  {
    Error_Handler();
  }
  if (HAL_UARTEx_DisableFifoMode(&huart4) != HAL_OK)
  {
    Error_Handler();
  }
 
}

void HAL_UART_MspInit(UART_HandleTypeDef* huart)
{
  GPIO_InitTypeDef GPIO_InitStruct = {0};
  RCC_PeriphCLKInitTypeDef PeriphClkInit = {0};
  if(huart->Instance==UART4)
  {
  /* USER CODE BEGIN UART4_MspInit 0 */
 
  /* USER CODE END UART4_MspInit 0 */
  if(IS_ENGINEERING_BOOT_MODE())
  {
 
  /** Initializes the peripherals clock
  */
    PeriphClkInit.PeriphClockSelection = RCC_PERIPHCLK_UART24;
    PeriphClkInit.Uart24ClockSelection = RCC_UART24CLKSOURCE_PCLK1;
    if (HAL_RCCEx_PeriphCLKConfig(&PeriphClkInit) != HAL_OK)
    {
      Error_Handler();
    }
 
  }
 
    /* Peripheral clock enable */
    __HAL_RCC_UART4_CLK_ENABLE();
 
    __HAL_RCC_GPIOA_CLK_ENABLE();
    __HAL_RCC_GPIOB_CLK_ENABLE();
    /**UART4 GPIO Configuration
    PA15     ------> UART4_RTS
    PA13     ------> UART4_TX
    PB2     ------> UART4_RX
    */
    GPIO_InitStruct.Pin = GPIO_PIN_15|GPIO_PIN_13;
    GPIO_InitStruct.Mode = GPIO_MODE_AF_PP;
    GPIO_InitStruct.Pull = GPIO_NOPULL;
    GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_LOW;
    GPIO_InitStruct.Alternate = GPIO_AF8_UART4;
    HAL_GPIO_Init(GPIOA, &GPIO_InitStruct);
 
    GPIO_InitStruct.Pin = GPIO_PIN_2;
    GPIO_InitStruct.Mode = GPIO_MODE_AF;
    GPIO_InitStruct.Pull = GPIO_NOPULL;
    GPIO_InitStruct.Alternate = GPIO_AF8_UART4;
    HAL_GPIO_Init(GPIOB, &GPIO_InitStruct);
 
    /* UART4 DMA Init */
    /* UART4_TX Init */
    hdma_uart4_tx.Instance = DMA2_Stream1;
    hdma_uart4_tx.Init.Request = DMA_REQUEST_UART4_TX;
    hdma_uart4_tx.Init.Direction = DMA_MEMORY_TO_PERIPH;
    hdma_uart4_tx.Init.PeriphInc = DMA_PINC_DISABLE;
    hdma_uart4_tx.Init.MemInc = DMA_MINC_ENABLE;
    hdma_uart4_tx.Init.PeriphDataAlignment = DMA_PDATAALIGN_BYTE;
    hdma_uart4_tx.Init.MemDataAlignment = DMA_MDATAALIGN_BYTE;
    hdma_uart4_tx.Init.Mode = DMA_CIRCULAR;
    hdma_uart4_tx.Init.Priority = DMA_PRIORITY_LOW;
    hdma_uart4_tx.Init.FIFOMode = DMA_FIFOMODE_DISABLE;
    if (HAL_DMA_Init(&hdma_uart4_tx) != HAL_OK)
    {
      Error_Handler();
    }
 
    __HAL_LINKDMA(huart,hdmatx,hdma_uart4_tx);
 
    /* UART4 interrupt Init */
    HAL_NVIC_SetPriority(UART4_IRQn, 1, 0);
    HAL_NVIC_EnableIRQ(UART4_IRQn);
 
  /* USER CODE BEGIN UART4_MspInit 1 */
 
  /* USER CODE END UART4_MspInit 1 */
  }
 
}

[Olivier GALLIEN]

Hi @RPape.1​ ,

I notice you are using UART4 on M4 side, which is usually the default one assigned to Linux and BSP stdout ...

Did you use another one on Linux side ?

Olivier