Is there a way to get STM32CubeIDE 1.1.0 debugger run without coming back to same breakpoint?

[scottSD]

Excuse me if this question has been answered, but I have searched the community and didn't find an answer.

When I set a breakpoint in the STM32CubeIDE 1.1.0 debugger, it does break at that breakpoint. But if I "Resume", the debugger comes right back to that breakpoint, not advancing past that point. In order to advance, I need to remove the breakpoint.

Is this because of the interrupts, RTOS, or the framework (TouchGFX)?

Is there a way to change this behavior?

[TWebs.1]

As far as I've seen, breakpoints work the same in the cubeide as every other ide. Your code that has the breakpoint, must be executing repeatedly.

You can open the ide's breakpoint window to disable it if you no longer want to stop at that line of code. Not sure I understand, maybe post code if I'm off-base.

[scottSD]

Thanks for the reply!

I wonder if it is possible that TouchGFX screen functions are repeatedly being called. Even when I place a breakpoint in the setupScreen() function, it appears to be continually executed. This is not what I expected. I thought that it would setup the screen once on screen entry and not return there. I have been working around this by disabling the breakpoint after initial break, but was wondering if there was a debugger setting to prevent this behavior.

Note that I did find that "stepping" after the break in setupScreen(), the debugger took me to an interrupt handler, so it may be that this behavior is just inherent to debugging in the TouchGFX framework.

[TWebs.1]

Hi Scott - I'm learning touchgfx, freertos, and c++ all at the same time so I'm far from an expert, but I think you've got something unintended going on. When I put a breakpoint in the setupScreen() function, it only hits it once as you'd expect. Is reset occuring? Do you have freertos tasks set up properly?

[scottSD]

As with you, I am still learning it as well and not sure if/how freetos tasks are setup properly or not.

I started with the STM32CubeIDE (1.1.0) and created a project for the STM32F746G-Discovery kit. The only things I changed in STM32CubeMX is the QUADSPI and the TouchGFX settings.

Maybe I missed a step?

[TWebs.1]

I don't have that discovery kit, but you might be able compare to a touchgfx example to make sure that you have things set up correctly.

My gui task looks like this:

  /* Create the thread(s) */
  /* definition and creation of defaultTask */
  osThreadDef(defaultTask, StartDefaultTask, osPriorityNormal, 0, 4096);
  defaultTaskHandle = osThreadCreate(osThread(defaultTask), NULL);
 
 
/* USER CODE END Header_StartDefaultTask */
void StartDefaultTask(void const * argument)
{
/* Graphic application */
  GRAPHICS_MainTask();
  /* USER CODE BEGIN 5 */
  /* Infinite loop */
  for(;;)
  {
    //osDelay(1);
  }
  /* USER CODE END 5 */ 
}

If you are using it, you might look at handleTickEvent() to make sure you don't have a screen transition to the current screen that shouldn't be occurring. Without the code, I'm out of ideas.

[scottSD]

I appreciate you taking the time to reply.

Here is what my StartDefaultTask() function is in my project:

/* USER CODE END Header_StartDefaultTask */
void StartDefaultTask(void const * argument)
{
  /* init code for FATFS */
  MX_FATFS_Init();
 
  /* init code for USB_HOST */
  MX_USB_HOST_Init();
 
/* Graphic application */
  GRAPHICS_MainTask();
  /* USER CODE BEGIN 5 */
  /* Infinite loop */
  for(;;)
  {
    osDelay(1);
  }
  /* USER CODE END 5 */ 
}

I commented out the 3 lines of code that are different than yours and the debugger still constantly breaks at the breakpoint in setupScreen(). I wondered if an watchdog is enabled causing this (which is something I have run into in other development systems) and from what I can tell they aren't activated in STM32CubeMX.

[CKauf]

Hei Scott,

I observed the same behaviour. This seems to be a hardware bug in the STM32F746:

https://community.st.com/s/question/0D50X0000A4pIcQSQU/stm32f746-cortexm7-silicon-bug-singlestep-lands-in-interrupt-handler

What helped for me was to insert the following lines in the initialization in main():

/* USER CODE BEGIN 2 */
 
  DBGMCU->APB1FZ |= DBGMCU_APB1_FZ_DBG_TIM6_STOP; //enable timer 6 stop 
 
  ...
 
  /* USER CODE END 2 */

I didn't come up with this myself. I think this is where I found it, but I'm not sure. :downcast_face_with_sweat:

The solution in the link did contain some more lines but for me it works with setting just this bit.

Best regards

Christoph

Edit: This would also explain, why websterelec could not reproduce the issue as they don't have the same discovery kit.

[scottSD]

Christoph,

I really appreciate your input. I tried that line of code and it did not help me for some reason. I did some looking at the links you provided and tried the additional lines of code (which would compile):

  HAL_DBGMCU_EnableDBGStandbyMode();
  HAL_DBGMCU_EnableDBGStopMode();
  DBGMCU->APB1FZ |= DBGMCU_APB1_FZ_DBG_TIM6_STOP;

One of the posters provided a line of code that does not compile likely because it is not recognized for the STM32F746:

RCC->APB2ENR |= RCC_APB2ENR_DBGMCUEN; //enable MCU debug module clock

I have been looking at the stm32f746xx.h file and have not found a similar "MCU debug module clock" bit.

[CKauf]

You wrote that the debugger took you to an interrupt handler so I just assumed it would be the same as it was for me.

Maybe you can find out which peripheral is throwing the interrupt and disable it in the Debug-MCU as well.