Issue with latest GDB

[Ancaritha]

I recently updated from the GCC 10.3.1 release to the latest 14.2.1 release (yeaa, we got real far behind) and I’m running into issues with debugging using the latest GDB.  When I do Debug->Start Debugging with GDB I get the error:

The memory location used for the stack (0x2407fffx) is not writable.
Please check the select device type and the linker script.
You can disable automatic stack checking via VisuaGDB Project Properties.

If I then go to VisualGDB Propeties->Makefile settings tab, and switch to the old compiler/gdb and redo Debug->Start debugging with GDB, it programs everything file and connects fine.
Just to make sure it wasn’t a GCC issue, I compiled it using 10.3.1 and then tried programming it with both.  I then compiled it with 14.2 and programmed it with both.  Same results both times.

I am on the STM32H7Eval board
I am using the latest OpenOCD (20240916)
I am writing to the external flash so I am using the QSPI plugin option with a driver I wrote using your walk through

OpenOCD command:
-c “debug_level 3” -f interface/stlink.cfg -f target/stm32h7x.cfg -c “flash bank qspi plugin 0x90000000 0 0 0 0 $(ProjectDir.forwardslashes)/../../../StarfirePlatform/bin/FlashDrivers/H7QspiFlashDriver.elf” -c init -c “reset init”

GDB Startup commands:
set remotetimeout 60
target extended-remote :$$SYS:GDB_PORT$$
mon halt
mon reset init
load

Are there any changes I had to make when upgrading to newer versions of GCC/GDB that were common knowledge when those versions came out but have fallen off the radar since those changes happened so long ago?  Any idea on where to look?  I am uploading my GDB output just in case.

Attachments:

You must be logged in to view attached files.

[Ancaritha]

My GDB 10.2 file was slightly too large, so I’ve split it into two at the halfway mark

Attachments:

You must be logged in to view attached files.

[support]

Hi,

Sorry, this looks like the project just crashes in a random location. Most likely there is a bug somewhere that is triggered by something about the new toolchain.

[Ancaritha]

If I erase my eval board using CubeProgrammer it behaves the same way.  It never starts downloading the executable so none of my code should be interfering as there’s nothing on the processor to run.

Any recommendations on where to look/what to do?  Am I cloning your OpenOCD again and tossing breakpoints in there again like while I was developing the QSPI Flash driver?  Do I need to rebuild that driver with the new GCC?

[Ancaritha]

Ok, so I installed a couple of the older toolchains and ran some tests

GCC 10.3.1 \ GDB 10.2.90: Works
GCC 12.3.1 \ GDB 13.2: Works
GCC 13.3.1 \ GDB 14.2: Fails
GCC 14.2.1 \ GDB 15.2: Fails

So something between 13.2 and 14.2 broke stuff.  Guess I get to go dig into the GDB notes for the first time ever and see if I can find anything… that’ll be fun…

[bflannery]

I thought this only happens when your linkerscript incorrectly describes your RAM regions.

The memory location used for the stack (0x2407fffx) is not writable.
Please check the select device type and the linker script.
You can disable automatic stack checking via VisuaGDB Project Properties

Can you attach your linkerscript?

[Ancaritha]

/* Entry Point */
ENTRY(Reset_Handler)
/* Highest address of the user mode stack */
_estack = ORIGIN(RAM) + LENGTH(RAM);    /* end of RAM */
/* Generate a link error if heap and stack don't fit into RAM */
_Min_Heap_Size = 0x1000;      /* required amount of heap  */
_Min_Stack_Size = 0x1000; /* required amount of stack */
/* Specify the memory areas */
MEMORY
{
RAM (rwx)         : ORIGIN = 0x24000000, LENGTH = 512K
FLASH (rx)        : ORIGIN = 0x08000000, LENGTH = 1024K
RAM_DTCM0 (rwx)   : ORIGIN = 0x20000000, LENGTH = 128K
ITCMRAM (rwx)     : ORIGIN = 0x00000000, LENGTH = 64K
RAM_SHARED (rwx)  : ORIGIN = 0x38000000, LENGTH = 64K

    /* External memory bus */
    QSPI    (rx)      : ORIGIN = 0x90000000, LENGTH = 128000K
SDRAM2 (rwx)      : ORIGIN = 0xd0000000, LENGTH = 16384K
}

/* Define output sections */
SECTIONS
{
  /* The startup code goes first into FLASH */
  .isr_vector :
  {
    . = ALIGN(4);
    KEEP(*(.isr_vector)) /* Startup code */
    . = ALIGN(4);
  } >FLASH

  /* The program code and other data goes into FLASH */
  .text :
  {
    . = ALIGN(4);
    *(.text)           /* .text sections (code) */
    *(.text*)          /* .text* sections (code) */
    *(.glue_7)         /* glue arm to thumb code */
    *(.glue_7t)        /* glue thumb to arm code */
    *(.eh_frame)
    KEEP (*(.init))
    KEEP (*(.fini))
    . = ALIGN(4);
    _etext = .;        /* define a global symbols at end of code */
  } >FLASH

  /* Constant data goes into FLASH */
  .rodata :
  {
    . = ALIGN(4);
    *(.rodata)         /* .rodata sections (constants, strings, etc.) */
    *(.rodata*)        /* .rodata* sections (constants, strings, etc.) */
    . = ALIGN(4);
  } >FLASH

  .ARM.extab (READONLY) : /* The "READONLY" keyword is only supported in GCC11 and later, remove it if using GCC10 or earlier. */ { *(.ARM.extab* .gnu.linkonce.armextab.*) } >FLASH
  .ARM : {
    __exidx_start = .;
    *(.ARM.exidx*)
    __exidx_end = .;
  } >FLASH

  .preinit_array (READONLY) : /* The "READONLY" keyword is only supported in GCC11 and later, remove it if using GCC10 or earlier. */
  {
    PROVIDE_HIDDEN (__preinit_array_start = .);
    KEEP (*(.preinit_array*))
    PROVIDE_HIDDEN (__preinit_array_end = .);
  } >FLASH

  .init_array (READONLY) : /* The "READONLY" keyword is only supported in GCC11 and later, remove it if using GCC10 or earlier. */
  {
    PROVIDE_HIDDEN (__init_array_start = .);
    KEEP (*(SORT(.init_array.*)))
    KEEP (*(.init_array*))
    PROVIDE_HIDDEN (__init_array_end = .);
  } >FLASH

  .fini_array (READONLY) : /* The "READONLY" keyword is only supported in GCC11 and later, remove it if using GCC10 or earlier. */
  {
    PROVIDE_HIDDEN (__fini_array_start = .);
    KEEP (*(SORT(.fini_array.*)))
    KEEP (*(.fini_array*))
    PROVIDE_HIDDEN (__fini_array_end = .);
  } >FLASH

  /* used by the startup to initialize data */
  _sidata = LOADADDR(.data);
  /* Initialized data sections goes into RAM, load LMA copy after code */
  .data :
  {
    . = ALIGN(4);
    _sdata = .;        /* create a global symbol at data start */
    *(.data)           /* .data sections */
    *(.data*)          /* .data* sections */
    . = ALIGN(4);
    _edata = .;        /* define a global symbol at data end */
  } >RAM AT> FLASH

  /* Uninitialized data section */
  . = ALIGN(4);
  .bss :
  {
    /* This is used by the startup in order to initialize the .bss secion */
    _sbss = .;         /* define a global symbol at bss start */
    __bss_start__ = _sbss;
    *(.bss)
    *(.bss*)
    *(COMMON)
    . = ALIGN(4);
    _ebss = .;         /* define a global symbol at bss end */
    __bss_end__ = _ebss;
  } >RAM

  /* User_heap_stack section, used to check that there is enough RAM left */
  ._user_heap_stack :
  {
    . = ALIGN(8);
    PROVIDE ( end = . );
    PROVIDE ( _end = . );
    . = . + _Min_Heap_Size;
    . = . + _Min_Stack_Size;
    . = ALIGN(8);
  } >RAM

  /* Remove information from the standard libraries */
  /DISCARD/ :
  {
    libc.a ( * )
    libm.a ( * )
    libgcc.a ( * )
  }

.RAM_DTCM0_Section :
{
  . = ALIGN(4);
  KEEP (*(.RAM_DTCM0_Section ))
  . = ALIGN(4);
} >RAM_DTCM0

.ITCMRAM_Section :
{
  . = ALIGN(4);
  KEEP (*(.ITCMRAM_Section ))
  . = ALIGN(4);
} >ITCMRAM

.RAM_SHARED_Section :
{
  . = ALIGN(4);
  KEEP (*(.RAM_SHARED_Section ))
  . = ALIGN(4);
} >RAM_SHARED

.SDRAM2_Section (NOLOAD) :
{
  _ssdram2 = .;         /* define a global symbol at extbss start */
      __sdram2_start__ = _ssdram2;

      /* Frame buffers must be first due to how CubeMX sets it up */
      *(TouchGFX_Framebuffer TouchGFX_Framebuffer.*)

      /* Probably don't want to use unless we really need to so we don't use up the FMC bus when the display might need it */
  *(.SDRAM2_Section)
      *(.SDRAM2_Section*)

  . = ALIGN(4);
  _esdram2 = .;         /* define a global symbol at extbss end */
      __sdram2_end__ = _esdram2;
} >SDRAM2

    ExtFlashSection :
    {
      ExtThirdPartyHeader = .;
      KEEP(*(.ExtFlashSection));
      ExtThirdPartyHeader_end = .;
    } >QSPI

    TextFlashSection :
    {
      ExtThirdPartyHeader = .;
      KEEP(*(.TextFlashSection));
      ExtThirdPartyHeader_end = .;
    } >QSPI

}

• This reply was modified 1 day ago by Ancaritha.
• This reply was modified 1 day ago by Ancaritha.
• This reply was modified 1 day ago by Ancaritha.
• This reply was modified 1 day ago by Ancaritha.
• This reply was modified 1 day ago by support. Reason: fixed div formatting

[Ancaritha]

I apologize for the div formatting… I don’t know how to get rid of it.  I’ve edited the post a number of times trying to fix it and it always shows up despite the numerous ways I’ve tried putting it in… and I apparently hit some sort of editing limit as I can’t edit the post anymore.

[Ancaritha]

I ripped out all the complicated QPI external flash stuff and rebuilt the program without it.  Fortunately the project is still in it’s early phases so the external flash hasn’t been filled up with a bunch of UI assets yet so it all still fits in internal memory.

It now… mostly works?  I was going to say that I stopped getting the stack error, but it didn’t actually program the board and no code was loaded, but I went back to check something else and now it does work?  I know I’m not hallucinating because I grabbed a copy of the GDB output and saved it to a file with the intention of uploading it here.  The ‘working’ version’s output is about 6000 lines, the other one is about 1000.  Comparing the output, it looks like the non-functional one is writing the program in a completely different manner.  It’s writing directly to the flash address, where as the other one is writing to internal ram (which is presumably then being copied into flash by the CPU?)  There is a non-zero chance the CPU had been erased before the bad (I don’t remember exactly) but I have been completely unable to replicate that weird GDB output.  For anyone that is curious, the divergence happens around line 550 in the attach files.

So, I’m going to muck around with that a bit more, see if I can find a sequence of events to reproduce it.  If I can’t I’m going to choke it up to some sort of user error as I’ve been switch around between versions of GCC/GDB a lot as I’ve been working on this and maybe screwed something up.  That aside, has SysProgs done any testing with creating a custom flash driver and GDB 15.2?  The one I’m using I created using this tutorial: https://visualgdb.com/tutorials/arm/stm32/flash/ and it’s the inclusion of that driver that seems to be breaking GDB.

• This reply was modified 23 hours, 26 minutes ago by Ancaritha.

Attachments:

You must be logged in to view attached files.

[Ancaritha]

Nope, not user error.  Even pulled in my co-worker to confirm I wasn’t hallucinating anything.  It will load fine, then I can change a single line of code (often just duplicating an existing line of code) and then it’ll stop working.  I can comment out the line of code I added and it will still fail.  At some random point, it will start working again.  And then it’ll stop working again.

Chunk of GDB output from a ‘bad’ run.

Info : 548 3182 stm32h7x.c:858 stm32x_probe(): Bank (0) size is 1024 kb, base address is 0x08000000
Debug: 549 3182 gdb_server.c:400 gdb_log_outgoing_packet(): [stm32h7x.cpu0] {1} sending packet: $O42616e6b202830292073697a652069732031303234206b622c2062617365206164647265737320697320307830383030303030300a#b9
Debug: 550 3183 gdb_server.c:400 gdb_log_outgoing_packet(): [stm32h7x.cpu0] {1} sending packet: $666c6173685f62616e6b5f73756d6d6172793a3078383030303030307c30783130303030307c73746d33326837782e62616e6b312e637075300a464c4153482070726f6772657373207265706f7274696e67206973206e6f77206f6e0a#94
Debug: 551 3211 gdb_server.c:383 gdb_log_incoming_packet(): [stm32h7x.cpu0] {1} received packet: X8000000,0:
Debug: 552 3211 gdb_server.c:400 gdb_log_outgoing_packet(): [stm32h7x.cpu0] {1} sending packet: $OK#9a
Debug: 553 3212 gdb_server.c:383 gdb_log_incoming_packet(): [stm32h7x.cpu0] {1} received packet: X8000000,298:
Debug: 554 3212 gdb_server.c:400 gdb_log_outgoing_packet(): [stm32h7x.cpu0] {1} sending packet: $OK#9a

It then goes on to write directly to flash memory.

 

Chunk of GDB output from a ‘good’ run

Info : 552 3152 stm32h7x.c:858 stm32x_probe(): Bank (0) size is 1024 kb, base address is 0x08000000
Debug: 553 3152 gdb_server.c:400 gdb_log_outgoing_packet(): [stm32h7x.cpu0] {1} sending packet: $O42616e6b202830292073697a652069732031303234206b622c2062617365206164647265737320697320307830383030303030300a#b9
Debug: 554 3153 gdb_server.c:400 gdb_log_outgoing_packet(): [stm32h7x.cpu0] {1} sending packet: $666c6173685f62616e6b5f73756d6d6172793a3078383030303030307c30783130303030307c73746d33326837782e62616e6b312e637075300a464c4153482070726f6772657373207265706f7274696e67206973206e6f77206f6e0a#94
Debug: 555 3179 gdb_server.c:383 gdb_log_incoming_packet(): [stm32h7x.cpu0] {1} received packet: vFlashErase:08000000,00060000
Debug: 556 3180 target.c:1784 target_call_event_callbacks(): target event 24 (gdb-flash-erase-start) for core stm32h7x.cpu0
Debug: 557 3180 target.c:4781 target_handle_event(): target: stm32h7x.cpu0 (hla_target) event: 24 (gdb-flash-erase-start) action: reset init

It then goes on to write to internal RAM.

It almost looks like the H7 is responding differently to the different versions of GDB despite being sent the same commands and then behaving differently after that.  The bad run never gets the reset event, never specifically erased flash and writes directly to internal flash.  After getting one of these bad runs (on a CPU that I had previously erased) I checked flash memory and it was still erased.  I have also gotten bad runs on CPUs that were previously programmed, and it still has that same response packet of X8000000,0.

… Unless anyone has any good ideas on where to look, I think I’m just going to have to revert this one specific project to GCC 12 while all of our other projects run on GCC 14.  The only other open system I have that I can get a programming onto is an L4 processor, which doesn’t seem to exhibit this same problem (or maybe I just haven’t tried it enough?).   I’m hoping it’s just going to be an issue with H7s, of which this is our only project.

[Ancaritha]

After even more playing around, it seems to be some sort of weird interaction between Visual Studios, VisualGDB and GDB.

I reverted all of my weird changes and went back to stock code which is trying to write external flash.
Try to Program/Debug, get the same weird stack error from before.
Close Visual Studios
Open File Explorer, and delete all .vs, .visualgdb and debug folders for the project
Reopen Visual Studios
After building, I am able to program and debug and it works perfectly fine.
Change the size of the executable (i.e. add/remove a line of code- simply touching a file is not sufficient).
After building, I get the same stack error as before.
Close VS, delete folders, reopen.  Build and program, succeeds.

 

So… that’s an annoying work around.  A different work around would be to revert the entire thing to GCC 12, or to copy the GDB included with GCC12 to the current folder.
What do I need to do that?  I copied over just  C:\SysGCC\12.3.1\arm-eabi\bin\arm-none-eabi-gdb.exe  and that does seem to work but I haven’t tested it extensively.  Is there anything else I should be porting over, or is just the exe file sufficient?

[Author]

Posts