Eclipse/GDB: How to set an automatic breakpoint after hardware reset?

Question

I am using a self-built embedded IDE with Eclipse and GDB - pretty much what this website describes: https://gnu-mcu-eclipse.github.io/

When I use OpenOCD or any other Debug Config (like SEGGER JLink) to flash my STM32F407 hardware, it breaks at the first line of my main.c. Nothing unusual.

// ----- main() ---------------------------------------------------------------
int main(void)
{

    //Initialization, if unsuccessful -> quit
    if (!INIT_bInit())
        return 0;

    //infinite Loop
    while (0x1337)
    {
        //Nothing
    }

    //Must not end here
    return 0;
}

//main() 

This might be due to the behaviour setup in the Eclipse OpenOCD debug console.

However, I'd like to have an automatic breakpoint mecahnism as well which halts the program in case there is a

• hard fault or a
• hardware reset

As my software generally bases on automatic tasks with void function pointers, I'd like to know when there is a hardfault occurring due to a problem with the function to be called,

But as of now, the only time I notice a HardFault is when I pause my program after a while and check if it ends up in my (custom) Default_FaultHandler (which implements the HardFault_Handler and others).

void Default_FaultHandler(void)
{
  while(0xDEAD){} 
}

Same thing with hardware reset. No indication, not even an automated (re-)break at main.c.

I know from eclipse-based IDEs like NXP's MCUXpresso or Atollic Studio that it is possible to automatically break the program when any fault handler or a hardware reset is called.

Any ideas on how to automate the debugging behaviour with my own-built OpenOCD/Eclipse solution?

Your help is warmly welcome

Cheers

-Henni

Answer 1

To analyze your hardfaults you can write a more sophisticated handler, cf https://www.freertos.org/Debugging-Hard-Faults-On-Cortex-M-Microcontrollers.html :

The implementation of prvGetRegistersFromStack() is shown below. prvGetRegistersFromStack() copies the register values from the stack into the C variables, then sits in a loop. The variables are named to indicate the register value that they hold. Other registers will not have changed since the fault occurred, and can be viewed directly in the debugger’s CPU register window.

Also cf How do I debug unexpected resets in a STM32 device?

You can not detect hardware resets because they erase entire memory. When booting up again you can find what caused the hardware reset, this is in STM32 how to get last reset status. Possibly store the result on some permanent memory that is not erased during next hardware reset