Why is the ST-LINK connection lost when enabling the SysTick interrupt?

Question

I am trying to use the SysTick on an STM32F767ZI.

When trying this:

#include "./headers/stm32f767xx.h"
 
void init_sysTick(void)
{
    SysTick->LOAD = 18749UL; // set the reload value, speed is 18.75MHz
    SysTick->VAL = 0UL; // set the starting value
    SysTick->CTRL = 0b111; // enable SysTick, SysTick interrupt and set clock source to the processor clock
}

The GDB server returned this error:

Error! Failed to read target status
Debugger connection lost.
Shutting down...

As well as the GDB client returning this:

warning: Remote failure reply: E31
Remote communication error.  Target disconnected.: No error.

I asked around, and came to the conclusion that the most likely reason for the ST-LINK connection being lost was due to the clocks which keep the ST-LINK going being put into low power mode.

However from having a read of the STM32F76xxx documentation, on low power modes specifically, it seems this may not be the case. The documentation states:

Low-power modes are entered by the MCU by executing the WFI (Wait For Interrupt), or WFE (Wait for Event) instructions, or when the SLEEPONEXIT bit in the Cortex®-M7 System Control register is set on Return from ISR.

...and as far as I am aware, I have not executed any WFI or WFE instructions.

From playing around with this code a little more, I found something quite surprising:

#include "./headers/stm32f767xx.h"
 
void init_sysTick(void)
{
    SysTick->LOAD = 18749UL; // set the reload value, speed is 18.75MHz
    SysTick->VAL = 0UL; // set the starting value
    SysTick->CTRL = 0b101; // enable SysTick and set clock source to the processor clock
}

Setting the CTRL register (also known as the SYST_CSR or SysTick Control and Status Register in the ARM documentation) as I did before, but without enabling the interrupt, did not cause the ST-LINK to lose connection as it did before.

I am using the vector table provided by ST, and have created an ISR for the SysTick interrupt: void SysTick_Handler(void);. The vector table has also been set to the start of flash, as it should be. I have managed to get GPIO interrupts working in the past.

I also tried using the Cortex-M7 CMSIS drivers as well as the code provided by STM32CubeIDE, but it is essentially the same as what I wrote and have shown above, so produced the same result.

Any support or suggestions would be appreciated, and I wonder if I am heading in the wrong direction in terms of thinking it is due to a low power mode?

SysTick_Hander function:

global.h

volatile uint32_t sysTicks;

void SysTick_Handler(void);

global.c

#include "./global.h"

void SysTick_Handler(void)
{
    sysTicks++;
}

Answer 1

ST-LINK connection being lost was due to the clocks which keep the ST-LINK going being put into low power mode

ST-Link has its own micro controller. You can't "put" it to the low power mode using your program.

Test procedure:

1. Check if you have declared the vector table in the startup files. If not it is the issue.
2. Check in the vector table definition what symbol is used for the systick handler. If it differs it will end up in the HF.
3. Generate the Cube project (judging from your code you have own startup which causes the problems) and see how vector table is defined and compare it to your own.

If nothing of the above works - zip the project, send it to some storage (like google drive and post the link)