Why is the MCU disconnecting (due to the ST-LINK losing connection) from the GDB when enabling the SysTick (TICKINT) interrupt register?

[Starman]

I am using the ST-LINK which is built onto/attached to the Nucleo-F767ZI in order to connect to the MCU and interact with it.

I am trying to use SysTick but am unable to enable interrupts with it. Everything else appears to work as it should.

I initially tried 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
}

However, this was causing the GDB client to return the message of:

warning: Remote failure reply: E31

Remote communication error. Target disconnected.: No error.

And the GDB server to return the messages:

...

ST-LINK device initialization OK

TraceCaptureStart and SWV event set to APP_TRUE

ST-LINK device status: LOCKUP

Enter STM32_AppReset() function

NVIC_DFSR_REG = 0x0000000B

NVIC_CFGFSR_REG = 0x00000000

Error! Failed to read target status

Debugger connection lost.

Shutting down...

The same happens even when using the Cortex-M7 CMSIS drivers to initialise the SysTick too.

Though after playing around with the code a little, I modified the write to the control and status register (CTRL) to not enable the SysTick interrupt:

#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
}

I am able to run this without any issues or disconnections.

It is clear that there is an issue with enabling the interrupt, but I am unsure as to what specifically that issue is.

[waclawek.jan]

Is there a valid ISR handler, with properly inserted vector in the vector table, VTOR is set properly etc.?

Other interrupts work?

JW

[Starman]

forgot to mention that, sorry

i have included a valid ISR (or at least I believe it to be valid):

#include "../headers/global.h"
 
void SysTick_Handler(void)
{
    sysTicks++;
    if (sysTicks % 1000 == 0) seconds++;
}

and initialising the variables used in this ISR from the other file:

volatile uint32_t sysTicks = 0;
volatile uint32_t seconds = 0;

my startup file, which is one provided by ST, does contain a vector table. it is a standard one and i have not modified it. you can check it out here

the vector location should also be set properly, here is my linker file (I have kept only the relevant parts here, for the full file, check here:(

/* Define the end of RAM and the limit of stack memory */
/* (512KB SRAM on the STM32F767ZI line, 524288 = 0x80000) */
/* (RAM starts at address 0x20000000) */
ENTRY(reset_handler)
 
_estack = 0x20080000;
 
/* Set minimum size for stack and dynamic memory. */
/* (1KB) */
_Min_Leftover_RAM = 0x400;
 
MEMORY
{
    FLASH ( rx )        : ORIGIN = 0x08000000, LENGTH = 2048K
    RAM ( rxw )         : ORIGIN = 0x20000000, LENGTH = 512K
}
 
SECTIONS
{
    /* Put vector table at the start of flash. */
    .vector_table :
    {
        . = ALIGN(4);
        KEEP (*(.vector_table))
        . = ALIGN(4);
    } >FLASH
 
...

and yes, I have managed to get interrupts working before (although never attempted the SysTick interrupt before).

[Tesla DeLorean]

I've used SysTick on these parts with no issues, but I'm not using the GDB/OCD circus.

A​ WFI instruction has the potential to dump the whole Debug Interface, because it turns it off.

Point of note 2**32 is not divisible by 1000​

[Starman]

ah i see,

how else would you go about debugging the device then? is it even possible? or is the better option just to flash the program and not have it connected to any debugging software?

[Tesla DeLorean]

The code in the repository doesn't look to have an idle loop with a WFI in it.

Assuming it is an issue related to GDB, you could perhaps try some more professional tools, say IAR or Keil.

Check the DBGMCU settings

Also you should watch the issue related to enabling GPIO clocks, and then immediately touching the peripheral.

[Starman]

sorry, linked the wrong branch earlier (although the linked startup and linkerscript files have not changed on this other branch)

this is the branch where I am trying to get the SysTick working on:

https://github.com/Starman3787/motor-driver-test/tree/experimental

i dont quite understand what is meant by "an idle loop with a WFI in it", would you mind clarifying?

i think it is unlikely to be an issue with the GDB, as I am using the STM32CubeIDE GDB server to connect to the ST-LINK, with the ARM GDB client (arm-none-eabi-gdb)

and in response to the last part about enabling the GPIO clocks, currently they do work, though i should be able to add delays once i have gotten the SysTick working

[Tesla DeLorean]

Say an RTOS or USB main() loop, where nothing actually happens in a system unless there is an interrupt, and those move things along.

while(1) __WFI(); or say of have a delay loop where you're waiting on HAL_GetTick() to change. A while(1)loop that grinds endlessly is very power hungry. The interrupt(s) you wait on may be things other than the SysTick, but in any case it's likely to decimate the looping by thousands of iteration. The WFI turns off clocks you'd need for the debug interface to work. The connection will drop.

From the F7 Reference Manual

40.16.1 Debug support for low-power modes

To enter low-power mode, the instruction WFI or WFE must be executed.

The MCU implements several low-power modes which can either deactivate the CPU clock or reduce the power of the CPU.

The core does not allow FCLK or HCLK to be turned off during a debug session. As these are required for the debugger connection, during a debug, they must remain active. The MCU integrates special means to allow the user to debug software in low-power modes.

[Starman]

ah i understand, thanks

so based on what the manual says, in theory the connection to the debugger should not drop/lose connection unless a low power mode has been activated (such as using the WFI or WFE instruction)? (though it sounds as if the MCU has some sort of prevention even against this, so it shouldnt lose connection?)

i have not included either of these instructions, so i would assume it may be another issue that is to blame? please correct me if i am wrong

or does the processor somehow go into low power mode when enabling the interrupts?

[Starman]

hey,

so after a few weeks, i've come back to this but started from scratch.

for some reason, i am no longer experiencing the same issue with the ST-LINK dropping out, which is great.

however, the SysTick_Handler interrupt does not appear to get called?

here is my new code: https://github.com/Starman3787/Stepper-Motor-Music

as before, i am using the standard startup file (with a vector table) which is provided by ST, so i highly doubt that is the issue here.