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.

[Author]

Posts