STM32H757 External Memory Loading

[Ancaritha]

I’m trying to get the QSPI memory loading from inside of Visual Studios and I’m running into something very weird.  It works, but VisualGDB throws an error and says it failed (but not if I do Program with Debugging).

First off, I followed this procedure: https://visualgdb.com/tutorials/arm/memories/
I had to make a couple of changes to make it H757 eval board friendly, but I am able to run that project and run the TestProgramming function and it writes 0x55 into flash.  I removed that test call and put the .elf file into my main stm32h7 eval project.

When I do “Program and Start without debugging” it will hang for about 5 to 10 seconds at the end, and then error out.  If I use STM32CubeProgrammer to look at the memory address, it was written with the new value despite saying it failed.  I have attached a text file that shows the entire GDB output.  I am using GDB with this command:

_{-f interface/stlink.cfg -f target/stm32h7x_dual_bank.cfg -c “flash bank qspi plugin 0x90000000 0 0 0 0 $(ProjectDir.forwardslashes)/QspiFlashDriver.elf” -c init -c “reset init”}

Also interesting, if I do “Start Debugging with GDB”… it works fine.  It both programs it and does not throw an error.

While writing this up, I did a deeper dive into comparing the GDB outputs, and it seems that running it with the debugger does not do a memory compare, and the compare is what’s failing.  I tried relocating my QspiFlashDriver into ITCMRAM, which the main application does not use, just in case the main application was corrupting it or something but that did not resolve the issue.  Any suggestions on what I could try?  Are there any other GDB flags I should be turning on?

Thanks!

Attachments:

You must be logged in to view attached files.

[support]

Hi,

There are a couple of debugging techniques to try here. You can try building a debug build of OpenOCD and setting breakpoints in FLASHPlugin.c to see what requests it gets from gdb, and what it passes to the plugin. You can then try modifying the plugin code to pass these values explicitly and hope to reproduce the problem in a debuggable context.

Another technique would be to reproduce the problem, terminate OpenOCD via Task Manager when it stops responding (it will leave the plugin loaded and running on the device), and do Debug->Attach to Running Program from another Visual Studio instance where you have the plugin project. This will let you see the state of the plugin and determine what it’s doing. You can also modify the plugin to keep some kind of a circular log in the RAM, that can be examined when you attach the debugger.

[Ancaritha]

Not gonna lie, I was really hoping you’d say something like “oh, for the H7 the example is inaccurate, you also need to do X” 🙂

Looks like I’m in for the long haul… It’s been about half a decade since I last built and debugged OpenOCD, I’m assuming these instructions still accurate? https://visualgdb.com/tutorials/arm/openocd/build/

I’ll post back here when I figure out what’s up (or have more questions), it might help someone else.

[support]

Sorry, when we publish tutorials showing how to do something with external source code, we do it to demonstrate specific VisualGDB features, and provide general ideas of what can be done.

Please do not take it as a pledge to port the shown code to every conceivable device and investigate how it works together with other external code that we have never seen. We can always do the porting at our consulting rate, but if we included this work in our regular support, the backlog would be measured in years due to the sheer amount of different devices and libraries.

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

[support]

No worries. It’s usually hard to suggest anything meaningful based on just “framework X doesn’t work on device Y” because the problem space is just too huge, but now that you narrowed it down to STLINK_SWD_AP_FAULT, we do have some advice:

1. If it’s a multi-core device, it should have 2 APs (one AP per core) and OpenOCD sometimes glitches out with one AP but not the other one. You can try hacking it around to forcibly switch between the APs. It could be theoretically doable with just the scripts, but you can do a quick test by hardcoding it in the C code in OpenOCD.
2. There is another bug with some STM32 devices where frequently switching them between running/stopped, while trying to read memory, triggers some weird internal state where it starts throwing sticky errors until you restart it. We don’t know a good way to fix it per se, but if switching the plugin from asynchronous mode to synchronous one should mostly avoid triggering it.

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

[support]

Hi,

Sorry, this is for you to figure out. Our support is limited to VisualGDB-specific issues, and this looks like something between OpenOCD, ST-Link and a particular device.

[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'"

[support]

All we did with the FLASH plugin was looked how OpenOCD handles FLASH drivers and made a convenient adapter that lets you create your own FLASH drivers as ELF files, so instead of digging and patching OpenOCD internals, all you need to do is implement a relatively simple interface on he device side. A small improvement to a free open-source tool that makes it a bit more convenient, that’s all.

We have not tested it with every available device. Our fork of the ST fork does include the logic for loading the plugins, but we have not tested it for compatibility with every ST device family.

If you want something more streamlined, you can look into Segger J-Link. They have their own software stack that doesn’t rely on open-source parts like OpenOCD, and usually just works. VisualGDB supports it out-of-the-box, fully interchangeably with OpenOCD. Another option would be to disable memory programming on the VisualGDB side, and run the STM32CubeProgrammer as a custom pre-debug step (see this tutorial).

As for the open-source parts like the FLASH plugin, please consider them reference designs. Like you can go to the ST’s website and get schematics for typical uses of different microcontrollers. But if you make your own board based on one, and it doesn’t work, it’s generally up to you to figure out why.

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

 

[support]

It’s too bad those things are like 10x the price of ST-Links….

That’s how much it costs to rigorously test the low-level logic with all the combinations of the devices and modes. The fact that nobody in the several decades managed to offer comparable quality, totally speaks for itself.

As for us, we focus on high-level features: visualizations, analysis, live monitoring, while delegating the low-level to those who excel at it.

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

[support]

No worries. Their support is usually great and they release updates very frequently, so if you can get them something they can reproduce in their lab, they should be able to fix it.

[Author]

Posts