SDRAM is configured with TIM6 as a tick source. While I am using GDB this interrupt continuously is interrupting the debug flow. How do we disable such interrupts in stm32cubeide ? This interrupt is continuously hogging gdb.

[rohan_m]

These stack gets called repetitively and does not let me debug.

If I reduce the priority of the ticks then HAL_Delay does not work.

I am in a fix here dont know what to do ?

I have changed the tick priority also as shown in the figure.

[Sarra.S]

Hello @rohan_m​,

There is no ready to check box in STM32CubeIDE to disable such interrupts.

So you need to do it in code  or as GDB run commands :

#ifdef DEBUG

__HAL_DBGMCU_FREEZE_TIM6();

#endif

Have a look at: xyz_hal.h file depending on your STM32 product !

By the way, what MCU are you using? is it Cortex-M7 based ?

Thank you!

Sarra

[rohan_m]

STM32H743IITx.

This does imply that the interrupt is enabled just it does not interrupt the gdb right ?

[Sarra.S]

hello again @rohan_m​ 

You need to check first whether your timer period is too short resulting in being stuck in the ISR

[rohan_m]

 

I did like this but just the same result

[rohan_m]

And the most important thing is that I have not configured the TIM6 manually or by cubemx. It was always used in the background by SDRAM. Even in cubemx the TIM6 appears grayed out

[Bob S]

So TIM6 is the SDRAM clock AND the tick clock? And is the interrupt period really 1ms (as it kinda looks like it should be from the code you posted). Is the TIM6 clock really 1MHz as that calculation presumes? And it seems strange to me to use a 1ms timer to increment a "high frequency tick" variable (1ms isn't very "high freq" in my book).

There is a bug in the F7 that causes single-stepping to step into any pending interrupt handler. I don't know if that same issue is present in the H7 family. As I recall, the Segger JLink implemented a work-around for that issue, but I don't know if the ST-Link does (it didn't when I last tried it over a year ago).

[rohan_m]

I feel like TIM6 being that clock but not something we explicitly configured. When we go to stm32cubemx it is grayed out.

[Sarra.S]

Hi @Bob S​,

Regarding the Arm Cortex M7 limitation "Single stepping Cortex M7 enters pending exception handler", it is only on Arm Cortex-M7 based device with core revisions r0p0 or r0p1.

which is not applicable for STM32H743IITx with core revision r1p1 (check errata)

At first, I thought about the same issue but it's not applicable in this case.