[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?

[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]

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 3 weeks, 6 days ago by Ancaritha.

Attachments:

You must be logged in to view attached files.

[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]

/* 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 3 weeks, 6 days ago by Ancaritha.
• This reply was modified 3 weeks, 6 days ago by Ancaritha.
• This reply was modified 3 weeks, 6 days ago by Ancaritha.
• This reply was modified 3 weeks, 6 days ago by Ancaritha.
• This reply was modified 3 weeks, 6 days ago by support. Reason: fixed div formatting

[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…

[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]

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.

[Ancaritha]

Doh, ok.  I was hoping that a particular shell program was included with the VisualGDB installs (since it comes with it’s own make.exe) and there was a high probability that was the one that would be called.  Back to trying to figure out which shell program is being executing via makefile commands.

I do really hate makefiles, but unfortunately it would be a substantial effort to migrate off of them.  We’ve made heavy modifications to various parts of it and have probably two dozen projects running on the same foundational code.

 

Thanks!

[Ancaritha]

So the source of the infinite build error was not the Echo vs echo command (which was still a weird issue), but is actually a sub-makefile we call that I ripped directly from the TouchGFX Designer program that ST makes for their UI stuff.  It checks to find if the CubeProgrammer utility is installed on the machine.  This is the section we believe to be causing it to fail:

ifneq (“$(shell find “$(program_files_win64)/$(stm32cube_programmer_filepath)” 2> nul )”,””)
program_files_path := $(program_files_win64)
else ifneq (“$(shell find “$(program_files_win32)/$(stm32cube_programmer_filepath)” 2> nul )”,””)
program_files_path := $(program_files_win32)
else ifneq (“$(shell find “$(program_files_CLT)/$(stm32cube_programmer_filepath)” 2> nul )”,””)
program_files_path := $(program_files_CLT)
endif

It works perfectly fine on my machine, unsure why it is failing on Kurt’s.  Would you be able to tell me which shell program/exe VisualGDB makefiles are going to end up calling?

 

Thanks!

[Ancaritha]

Yup, and VisualGDB is great 🙂

After testing with the Segger… it would appear that the RAMcode they use for loading external flash isn’t quite right for the current release of the H757 eval board.  There were previous revisions of this board and I’m not sure if the timings on the flash chip changed, but Segger fails to program it with the correct values.  Sigh

What external memory looks like when programmed via OpenOCD (with my flash driver) or CubeProgrammer

0x0 0x230057ff 0x5d035aff 0xea045aff
0xd60559ff 0xa70559ff 0x490357ff 0x170059ff

What Segger creates

0xff00ff00 0xff00ff00 0xff57ffff 0xff5affff
0xff5dff03 0xff5bffff 0xffa9ff05 0xff5affff

Seems like it’s only writing 16 bits to each 32 bit spot. Well, off to the Segger forums I go…

Thanks for the help!

[Ancaritha]

Yea, I might have to look into using the Segger J-Link.  We’ve used OpenOCD and ST-Links on all of our products up this point but this is the first time we’ve tried to use either external flash or a dual core processor, so hitting some growing pains.  We have a few J-Links in house and there does appear to be a JTAG port on the H7 Eval board (which is the only thing we have at the moment) so I’m going to try that.  It’s too bad those things are like 10x the price of ST-Links….

 

[Ancaritha]

I’m giving up for the time being on figuring out why it can’t read memory.  I can debug and it does program external flash, so I can deal with it for now.

I did all the development work using OpenOCD as that was what was in the tutorial.  However, this is a Dual Core part so ideally I’d be using the ST Fork of OpenOCD.  Doing so… does not work great.  Or at all really.  Would you expect the QSpiDriver to work with both OpenOCD and the ST Fork?

 

mon report_flash_progress 1
&"mon report_flash_progress 1\n"
@"Device: STM32H74x/75x\n"
@"flash size probed value 2048k\n"
@"STM32H7 flash has dual banks\n"
@"Bank (0) size is 1024 kb, base address is 0x08000000\n"
@"Device: STM32H74x/75x\n"
@"flash size probed value 2048k\n"
@"STM32H7 flash has dual banks\n"
@"Bank (1) size is 1024 kb, base address is 0x08100000\n"
@"Device: STM32H74x/75x\n"
@"STM32H757XIXx.cm4 cannot read the flash size register\n"
@"assuming 2048k flash\n"
@"STM32H7 flash has dual banks\n"
@"Bank (2) size is 1024 kb, base address is 0x08000000\n"
@"Device: STM32H74x/75x\n"
@"STM32H757XIXx.cm4 cannot read the flash size register\n"
@"assuming 2048k flash\n"
@"STM32H7 flash has dual banks\n"
@"Bank (3) size is 1024 kb, base address is 0x08100000\n"
@"Failed to read memory at 0x00003000\n"
@"Failed to read memory at 0x00003000\n"
=thread-exited,id="1",group-id="i1"
=thread-group-exited,id="i1"
&"Remote communication error. Target disconnected.: Not a directory.\n"
^error,msg="Remote communication error. Target disconnected.: Not a directory."
load
&"load\n"
&"You can't do that when your target is `exec'\n"</code>
<code>^error,msg="You can't do that when your target is `exec'"

[Ancaritha]

Ok, so pretty sure it comes down to the fact that it can’t read the values at the QSPI flash address even though it can write there.

x/20xw 0x90000000
&"x/20xw 0x90000000\n"
~"0x90000000 <_ZL14_acarrow_right>:\t0x00000000\t0x00000000\t0x00000000\t0x00000000\n"
~"0x90000010:\t0x00000000\t0x00000000\t0x00000000\t0x00000000\n"
~"0x90000020:\t0x00000000\t0x00000000\t0x00000000\t0x00000000\n"
^done
(gdb)

Using the CubeProgrammer I can look at the values at 0x90000000 and they are not 0.  I can even print them out to a UART in my code, so I know that my code is capable of reading the memory.  OpenOCD  is using some very low level driver read functions to try and read memory that I can’t quite figure out, so I don’t know why it’s not working.

Another thing I can’t figure out that I’m hoping you might be able to tell me… how exactly does the QspiFlash.elf file I made work?  I’ve read the address in RAM that it should be loaded at and it never changes.  Does OpenOCD actually load it onto the processor at any point, or does it just use the Elf file and like, execute it’s assembly code directly on the target cpu or something?  It’s obviously working as I can write to the external flash, but I can’t figure out how it’s work.

[Ancaritha]

Oh yea, I wouldn’t expect you guys to have a tutorial for every CPU.  That would be just, an absurd amount of work that never ended.  The example got me 98% of the way there, I just had to make some tweaks to get it running for the H7 eval board.  There was always the off chance someone would post “oh yea, don’t forget to do XYZ on the H7, it’s different!”.  For example, enabling the CRC peripheral.  Which might be a thing you have to do… unclear.

As far as I can tell, the “compare-sections” command doesn’t utilize any of the functions in FLASHPlugin.c (I put a breakpoint in all of them).  This is the error message that get spit out around the time it fails to read the flash section

Debug: 4317 94061 hla_target.c:278 adapter_debug_entry(): entered debug state in core mode: Handler at PC 0x000002de, target->state: halted
Debug: 4318 94068 target.c:1784 target_call_event_callbacks(): target event 17 (debug-halted) for core stm32h7x.cpu0
Debug: 4319 94076 hla_target.c:323 adapter_poll(): halted: PC: 0x000002de
Debug: 4320 94080 armv7m.c:656 armv7m_wait_algorithm(): failed algorithm halted at 0x2de, expected 0x2000002e
Error: 4321 94087 armv7m.c:921 armv7m_checksum_memory(): error executing cortex_m crc algorithm
Debug: 4322 94093 target.c:2111 target_free_working_area_restore(): freed 52 bytes of working area at address 0x20000000
Debug: 4323 94098 target.c:1910 print_wa_layout(): 0x20000000-0x2000ffff (65536 bytes)
Debug: 4324 94102 target.c:2419 target_read_buffer(): reading buffer of 12 byte at 0x90000000
Debug: 4325 94110 hla_target.c:601 adapter_read_memory(): adapter_read_memory 0x90000000 4 3
Debug: 4326 94115 stlink_usb.c:1102 stlink_usb_error_check(): STLINK_SWD_AP_FAULT
Debug: 4327 94120 gdb_server.c:1493 gdb_error(): Reporting -4 to GDB as generic error
Debug: 4328 94126 gdb_server.c:400 gdb_log_outgoing_packet(): [stm32h7x.cpu0] {1} sending packet: $E0E#ba

When I got look at stlink_usb.c, this is the part of the case statement that handles the error code

case STLINK_SWD_AP_FAULT:
/* git://git.ac6.fr/openocd commit 657e3e885b9ee10
* returns ERROR_OK with the comment:
* Change in error status when reading outside RAM.
* This fix allows CDT plugin to visualize memory.
*/
LOG_DEBUG("STLINK_SWD_AP_FAULT");
return ERROR_FAIL;

I have yet to try having that just return ERROR_OK yet, still poking at other stuff.

I did notice this error message in there:
Error: 4321 94087 armv7m.c:921 armv7m_checksum_memory(): error executing cortex_m crc algorithm
so I turned on the CRC peripheral in both the QSpiFlashDriver project and my own project, but I still get that error so unclear if it is related or not.

These are the commands I’m using to connect to the GDB instance and load/program

arm-none-eabi-gdb.exe --interpreter mi C:\SrcGit\STM32H757Eval\Project\Solution\STM32H757Eval-CM7\Debug\STM32H757Eval-CM7.elf
-list-features
-gdb-set verbose on
-gdb-set filename-display absolute
-gdb-set disassembly-flavor intel
-gdb-set print demangle off
set remotetimeout 60
target remote :3333

mon halt
info shared
mon reset init
mon report_flash_progress 1

x/20xw 0  // This is just to check that my QSpiDriver is in memory

load

compare-sections

I have attached the entire debug output… because why not.   I have also attached the call stack for when it hits that "STLINK_SWD_AP_FAULT" error.

Attachments:

You must be logged in to view attached files.

[Author]

Posts