Error finishing flash operation STM32L476RC

[tanevitt]

Hello!
I’m currently experiencing an issue when flashing a program to my STM32L476RC chip. When I try to run the VisualGDB Debugger I get the following error message:

 
“Error finishing flash operation”

 
The output from “All GBD interaction” is attached in a .txt file. As far as I can tell, the relevant section reads:

 
load
&”load\n”
Loading section .isr_vector, size 0x188 lma 0x8000000
+download,{section=”.isr_vector”,section-size=”392″,total-size=”811749″}
+download,{section=”.isr_vector”,section-sent=”392″,section-size=”392″,total-sent=”392″,total-size=”811749″}
Loading section .text, size 0x23c7c lma 0x80001c0
+download,{section=”.text”,section-size=”146556″,total-size=”811749″}
Loading section .exidx, size 0x8 lma 0x8023e3c
+download,{section=”.exidx”,section-size=”8″,total-size=”811749″}
Loading section .init_array, size 0x4 lma 0x8023e44
+download,{section=”.init_array”,section-size=”4″,total-size=”811749″}
Loading section .fini_array, size 0x4 lma 0x8023e48
+download,{section=”.fini_array”,section-size=”4″,total-size=”811749″}
Loading section .data, size 0xc0 lma 0x8023e4c
+download,{section=”.data”,section-size=”192″,total-size=”811749″}
&”Error finishing flash operation\n”
Error finishing flash operation

I’m only experiencing this issue when I make a specific function call that runs some numerical simulations (which increases the code size quite significantly.) When I do not include this specific function call, the program compiles and flashes without issue. I do not believe the issues with the simulation code, as I’m able to run this code without issues on a STM32L476VG.  The biggest difference between the RC and VG is ROM size (256k vs 1024k, respectively.) This, coupled with the flash error, pointed me towards looking at memory issues. So I changed my compiler optimization settings to Minimize size, however, this still did not work. When I look at the “MemoryUtilizationReport” generated though, I get the following:
<?xml version=”1.0″?>
<MemoryUtilizationReport xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance&#8221; xmlns:xsd=”http://www.w3.org/2001/XMLSchema”&gt;
<Memories>
<MemoryUtilization>
<MemoryName>FLASH</MemoryName>
<Used>147156</Used>
<Total>262144</Total>
</MemoryUtilization>
<MemoryUtilization>
<MemoryName>SRAM</MemoryName>
<Used>656</Used>
<Total>98304</Total>
</MemoryUtilization>
<MemoryUtilization>
<MemoryName>RAM2</MemoryName>
<Used>0</Used>
<Total>32768</Total>
</MemoryUtilization>
</Memories>
</MemoryUtilizationReport>

So it does not look like I am running out of flash memory.

Any suggestions on where to look or additional things to try?

Thank you, and please let me know if any additional information would be helpful.

• This topic was modified 5 years, 7 months ago by tanevitt.
• This topic was modified 5 years, 7 months ago by tanevitt.

Attachments:

You must be logged in to view attached files.

[support]

Hi,

This looks like a known OpenOCD issue – some combination of section sizes and alignment causes it to fail the FLASH programming on STM32L4 devices. Please try checking the section sizes/alignments in Embedded Memory Explorer and see if increasing the alignment via the linker script (e.g. aligning every section to 16 or 64 bytes) solves the problem.

Another option would be to use Segger J-Link instead of OpenOCD. The J-Link comes with its own highly optimized gdb stub that handles memory programming better than OpenOCD, works faster and supports software breakpoints in FLASH memory.

[tanevitt]

Hello,

Thank you for your response. I was pulled to another project for the past couple weeks, but now I am getting back to this.

Regarding your first suggestion of checking sizes/alignment in Embedded Memory Explorer, I’m able to open Embedded Memory Explorer and see the flash progress of various sections of my code (see attached screenshot, embedded_explorer.png) but I’m unable to locate my linker script to adjust the alignment. Where can I find my linker script to begin editing it?

Regarding your second suggestion of using Segger J-Link instead of OpenOCD, I was able to download J-Link and I can select it in my DeBug settings. It even autodetects the correct debugging device, however, when I click the “Test” button with Segger J-Link selected, I get the message that “No emulators connected via USB”. See attached sceen shot, “J_link.png” Some googling around suggested that perhaps this could be an issue with the default USB drivers not being compatible with J-Link, but another coworker suggested that J-Link may not work without using a physical J-Link debugging probe, such as the J-Link Pro. To get Segger J-link to work in this situation, is it a matter of changing my USB drivers around to work, or perhaps re-flashing ST-LINK onboard to work with J-Link? Or do I need to buy a J-Link Pro?

Thank you, and please let me know if you need any additional clarifying information.

-Zander

Attachments:

You must be logged in to view attached files.

[tanevitt]

At least one problem solved:

I was able to locate my linker script by doing the following:

Right click VisualGBD Project -> VisualGBD Project Properties -> MSBuild settings

There I was able to find the path for my linker script.

[support]

Hi,

No problem, we will try to clarify. VisualGDB relies on many different 3rd-party tools to handle low-level device access, FLASH programming, etc. The most popular tools for ARM devices are:

• OpenOCD. It’s completely free and actively maintained (e.g. support for ST devices is contributed by ST itself), but may be sometimes buggy or require complex setup.
• Segger J-Link. It is normally designed to be used with the Segger J-Link Pro and other Segger debug probes. The J-Link hardware is more expensive than ST-Link, as Segger maintains a fully supported replacement to OpenOCD that works out-of-the-box with many devices, supports FLASH breakpoints, etc. They also provide functionally limited versions of it that could be FLASHed into ST-Link, but they are normally not covered by their support.

VisualGDB works with both underlying tools, so you can choose one depending on your preferences.

The issue you encountered with Segger software is likely caused by a missing driver, but it’s hard to say for sure. Generally, if you prefer something that works 100% of the time and is fully supported, please consider getting a J-Link Pro.

Alternatively, please try making a copy of your linker script (via VisualGDB Project Properties) and adding the following line before the end of each section:

. = ALIGN(64);

This will align each section to the 64-byte boundary and might solve the problem with the FLASH programming.

 

 

[Author]

Posts