STM32h753 External Memories Loading

[Lucas Rolfes]

I am seeing an issue that I haven’t been able to hone in exactly where it is coming from when attempting to use VisualGDB to load data into the external flash. Right now, I am just testing a simple 20 byte array to prove everything is working.

I am using an STM32h753ZI, and connecting a WinBond W25Q01JV via QSPI as the external memory. I have tested that the configurations / commands are working, as I was able to read and write 4 bytes just as a proof that the drivers are working accordingly, which is what the stubs should be interfacing to for my seperate flashloader application.

 

I setup my flash loader application according to these guides:

https://visualgdb.com/tutorials/arm/stm32/flash/

https://visualgdb.com/tutorials/arm/memories/

and when testing the flash loader independently, I am able to see data being programmed into the QSPI.

However, when I attempt use the flashloader .elf according to the guide in the primary application, I see this failure:

“The memory location used for the stack (0x2001fffc) is not writable.

Please check the selected device type and the linker script.

You can disable automatic stack checking via VisualGDB project Properties.”

 

When checking the GDB log, probably the most interesting piece of the OpenOCD log is:

”

Error: 6130 3644 arm_adi_v5.c:457 mem_ap_write(): Failed to write memory and, additionally, failed to find out where

”

 

I am just not certain exactly what this means and how to proceed here, as it is quite the generic error and isn’t indicating things that stubs are missing or other issues.. Any suggestions?

Attachments:

You must be logged in to view attached files.

[support]

Hi,

This could be a bug in OpenOCD, or something specific to a device (e.g. the firmware disabling the JTAG/SWD pins). The best way to troubleshoot it would be to break it down into smaller parts:

1. Try running OpenOCD manually. Check if you can read/write the memory at the end of stack using the mdw/mww commands.
2. If yes, try connecting gdb manually and running the “print *((void **)0x2001fffc)” command.
3. If it works, try manually running the gdb commands executed by VisualGDB (from the log file) to see which of them causes the memory to stop working. E.g. some part of the FLASH loader might interfere with the pins, clocks or other settings.

You can also try building OpenOCD from sources as shown here and double-checking what exactly happens when it tries to read memory, or run specific commands.

[Lucas Rolfes]

Hello,

 

Thanks for getting back to me!  I’ve attempted to run the following:

openocd.exe -c “gdb_port 64986” -c “telnet_port 64984” -c “debug_level 3” -f interface/jlink.cfg -c “transport select swd” -c “adapter speed 3000” -c “mdw 0x2001ffc” -c “exit”

and I get the error message that it does not understand the command mdw. Is this an inappropriate usage of mdw? If so, how would I get it to execute properly?

I am not explicitly setting the SWD pins, so they are not being configured via either the flash loader application nor the main application. I will explicitly set those and let you know if that changes anything.

Thanks,
Lucas

 

[support]

Hi,

You are likely missing the “init” command. In general, we would advise first running OpenOCD using exactly the same command line VisualGDB uses, then connecting to the telnet_port via telnet and running the “mdw” command via it. This should produce results consistent with regular debug sessions.

[Lucas Rolfes]

Hello again.

 

Thank you for the suggestion of checking the telnet connection. I was able to probe the address that was claiming the device was failing to write to – 0x2001fffc , and it did return *a* value indicating that there was not an error.

GDB also did not have issues probing that address nor nearby addresses.

I ran this test via the primary application, with the flash plugin command removed to simplify things.

Whats interesting is 0x2001fffc is the end of the DTCRAM, and it appears to occur even if I remove the that reference in both linker files.

This issue only occurs when including the command -c “flash bank qspi plugin 0x90000000 0 0 0 0 C:/Users/Public/FlashLoader.elf”

It appears as though the flash loader plugin is communicating and working mostly as I would expect, as if I remove the call to FLASHPlugin_InitDone() from main.cpp’s main() function, the tool does claim it is missing.

I can’t say I know well enough how the flash plugin operates, but I did add a LED toggle for a few seconds inside of the main loop of the flash loader .elf output, and I did not see the LED toggle at least indicating to me the file was not loaded into memory prior to the main app.

Is there maybe a command I can issue inside of the FlashLoader.elf to confirm that it is being executed / entered correctly?

 

[support]

Hi,

You can find the logic used by OpenOCD to load and run the plugin in this file: https://github.com/sysprogs/openocd/blob/master/src/flash/FLASHPlugin.c.

You should be able to understand what is going on by building a debug version of OpenOCD and running it under debugger (see this tutorial).

[Lucas Rolfes]

Interesting bit of follow up – it appears as though this process will not work with Jlinks as it exists today.

I moved over to an STLINK, and kept nearly identical code on both sides, and nearly identical configurations beyond the necessary means to use the JLINK, and the tools no longer error out in the manner that I was seeing before.

Also from the debug logs, I am seeing notes programming flash sections of 20 bytes (which is my test usage size), so far that I can tell things should be working correctly now.

Now my sample implementation appears to not be either memory mapping correctly or the .elf is not properly loading, data into the QSPI, but that is my problem to solve.

 

Thanks for the support!

[support]

Good to know it works with ST-Link.

J-Link is generally better than OpenOCD out-of-the-box (with its own software), but the FLASH plugin interface is indeed specific to OpenOCD.

OpenOCD support for J-Link devices uses a separate open-source implementation that might contain its own bugs. If switching to ST-Link solves the problem, it could be a reasonable workaround.

[Author]

Posts