Error finishing flash operation

[samo4]

When trying to debug STM32L082 (without crystal) using STLINK/v2 I get the following error:
“Error finishing flash operation”

When I use ST tool everything works correctly.

Any ideas?

Here’s the output of openocd:

Open On-Chip Debugger 0.10.0 (2017-06-09) [https://github.com/sysprogs/openocd]
Licensed under GNU GPL v2
For bug reports, read
 http://openocd.org/doc/doxygen/bugs.html
3
Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'.
adapter speed: 300 kHz
adapter_nsrst_delay: 100
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
none separate
Info : Unable to match requested speed 300 kHz, using 240 kHz
Info : Unable to match requested speed 300 kHz, using 240 kHz
Info : clock speed 240 kHz
Info : STLINK v2 JTAG v28 API v2 SWIM v7 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 3.200000
Info : stm32l0.cpu: hardware has 4 breakpoints, 2 watchpoints
Info : Unable to match requested speed 300 kHz, using 240 kHz
Info : Unable to match requested speed 300 kHz, using 240 kHz
adapter speed: 240 kHz
target halted due to debug-request, current mode: Thread 
xPSR: 0xf1000000 pc: 0x08005e4c msp: 0x20005000
STM32L0: Enabling HSI16
Info : Unable to match requested speed 2500 kHz, using 1800 kHz
Info : Unable to match requested speed 2500 kHz, using 1800 kHz
adapter speed: 1800 kHz
VisualGDB_OpenOCD_Ready
Info : accepting 'gdb' connection on tcp/42368
Info : Device: STM32L0xx (Cat.5)
Info : STM32L flash has dual banks. Bank (0) size is 96kb, base address is 0x8000000
Info : Unable to match requested speed 300 kHz, using 240 kHz
Info : Unable to match requested speed 300 kHz, using 240 kHz
adapter speed: 240 kHz
target halted due to debug-request, current mode: Thread 
xPSR: 0xf1000000 pc: 0x08005e4c msp: 0x20005000
STM32L0: Enabling HSI16
Info : Unable to match requested speed 2500 kHz, using 1800 kHz
Info : Unable to match requested speed 2500 kHz, using 1800 kHz
adapter speed: 1800 kHz
Info : Unable to match requested speed 300 kHz, using 240 kHz
Info : Unable to match requested speed 300 kHz, using 240 kHz
adapter speed: 240 kHz
target halted due to debug-request, current mode: Thread 
xPSR: 0xf1000000 pc: 0x08005e4c msp: 0x20005000
STM32L0: Enabling HSI16
Info : Unable to match requested speed 2500 kHz, using 1800 kHz
Info : Unable to match requested speed 2500 kHz, using 1800 kHz
adapter speed: 1800 kHz
Error: jtag status contains invalid mode value - communication failure
Info : Previous state query failed, trying to reconnect
Error: error writing to flash at address 0x08000000 at offset 0x00000000
Info : Unable to match requested speed 300 kHz, using 240 kHz
Info : Unable to match requested speed 300 kHz, using 240 kHz
adapter speed: 240 kHz
target halted due to debug-request, current mode: Thread 
xPSR: 0xf1000000 pc: 0x08005e4c msp: 0x20005000

[support]

Hi,

The “jtag status contains invalid mode value – communication failure” message usually indicates a wiring error. Lowering the JTAG frequency or enabling “connect under reset mode” might help.

If not, please try a different board. Wiring problems are often intermittent and can get triggered semi-randomly.

[mcipjvw]

Hi,

I’ve a simular problem here with my stm32l071, see the log below. A wiring problem seems not to be the issue here,  the “STM32CubeProgrammer” does the programming well.

Tried two boards….

Any news around this topic? Did you solve the problem?

Thnx

Martin

Open On-Chip Debugger 0.10.0 (2017-06-09) [https://github.com/sysprogs/openocd]
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport “hla_swd”. To override use ‘transport select <transport>’.
adapter speed: 240 kHz
adapter_nsrst_delay: 250
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
none separate
Info : clock speed 240 kHz
Info : STLINK v2 JTAG v31 API v2 SWIM v7 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 3.184252
Info : stm32l0.cpu: hardware has 4 breakpoints, 2 watchpoints
adapter speed: 240 kHz
target halted due to debug-request, current mode: Thread
xPSR: 0xf1000000 pc: 0x0800b324 msp: 0x20005000
STM32L0: Enabling HSI16
adapter speed: 1800 kHz
VisualGDB_OpenOCD_Ready
Info : accepting ‘gdb’ connection on tcp/64516
Info : Device: STM32L0xx (Cat.5)
Info : STM32L flash has dual banks. Bank (0) size is 96kb, base address is 0x8000000
adapter speed: 240 kHz
target halted due to debug-request, current mode: Thread
xPSR: 0xf1000000 pc: 0x0800b324 msp: 0x20005000
STM32L0: Enabling HSI16
adapter speed: 1800 kHz
adapter speed: 240 kHz
target halted due to debug-request, current mode: Thread
xPSR: 0xf1000000 pc: 0x0800b324 msp: 0x20005000
STM32L0: Enabling HSI16
adapter speed: 1800 kHz
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000000e msp: 0x20005000
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000000e msp: 0x20005000
Error: jtag status contains invalid mode value – communication failure
Info : Previous state query failed, trying to reconnect
target halted due to debug-request, current mode: Thread
xPSR: 0x81000000 pc: 0x20000006 msp: 0x20005000
Error: error writing to flash at address 0x08000000 at offset 0x00000000
Warn : keep_alive() was not invoked in the 1000ms timelimit. GDB alive packet not sent! (1389). Workaround: increase “set remotetimeout” in GDB
adapter speed: 240 kHz
target halted due to debug-request, current mode: Thread
xPSR: 0xf1000000 pc: 0x0800b324 msp: 0x20005000

• This reply was modified 5 years, 7 months ago by mcipjvw.

[support]

This looks like a known OpenOCD bug that sometimes triggers on STM32L0 and L4 devices.

The easiest workaround would be to switch to Segger J-Link that comes with its own FLASH programming logic. Alternatively, please try experimenting with section sizes and alignment – the OpenOCD bug is usually triggered by small sections.

[mcipjvw]

Hi,

Thanks for your reply. I just played with the adapter speed. Setting to 1200 kHz did the job for now. Remarkable that programming with the stm32cube programmer does not give any problem.

Martin

 

[support]

Good to know it works. As OpenOCD is a separate open-source tool that is independent from the regular ST-Link tool, this makes sense. That said, aside from occasional issues with the STM32L4 FLASH driver, OpenOCD is pretty reliable and usable.

[Ancaritha]

I’ve noticed that OpenOCD has issues with L0’s  (at the very least, the L071 that I use) if you are using a version after the 2018 release (before that works A-OK).  We had to update to the latest version to support the L496 processor and when I did that I stopped being able to program my L0 board.  We ended up manually building OpenOCD from a slightly older package and adding support for the L496 ourselves so that we could use both.

I recently decided to give the latest OpenOCD another shot and my initial test worked OK but recently I tried to use it again and it usually failed, so I started looking at this again  (I actually posted on the forums about this around a year ago but became swamped and was unable to experiment with it and just had to go with a known working).

When comparing the two OpenOCD outputs, I did notice something odd:

Old version (that works):
Info : Device: STM32L0xx (Cat.5)
Info : STM32L flash has dual banks. Bank (0) size is 128kb, base address is 0x8000000

New Version (that fails):
Info : Device: STM32L0xx (Cat.5)
Info : STM32L flash has dual banks. Bank (0) size is 64kb, base address is 0x8000000

 

Clock speed and adapter speeds match between the two versions.  Could this be as simple as the config file for the L0 is incorrect?

[Ancaritha]

Heh, yup, found the old post: https://sysprogs.com/w/forums/topic/issues-using-newest-version-of-openocd-0-10-0/

Looks like I definitely dropped the ball, I’ll try and pick that up again now 🙂

[Ancaritha]

Alrighty, I’ve attached two text files.  The “New” one is using the 2018-12-12 release of OpenOCD.  The “Old” is using our custom built one based off of 2017-04-14.

I placed a breakpoint at the first instruction of Main().  Using our custom built one, I’ll hit it every time.  Using the new one it never gets there.  If I pause the debugger and look at the hardware registers in the debugger and there are some… dubious values there.  R0 through R12 all have a value of 0xffffffff.  SP is 0x20004fe0.  LR is 0xfffffffe.  PC is 0xfffffffe.  I tried looking at the OpenOCD output but theres kind of a lot going on in there…

It should be noted that if I program the board using ST-Link and then do “Attach to running firmware”, it works fine.  It just appears to have an issue with programming the board.

[Ancaritha]

Ok, well the text files are too large to be uploaded, clocking in at an enormous 1.3 megs and 1.8 megs…  So i’m going to do it two different ways.

Full files using google drive (in case you want to look at everything all at once):
Here is the New (broken) version: https://drive.google.com/file/d/1B7g_HdNXt1BKeRnigwQTaDTLI5gMJwSI/view?usp=sharing
Old (working) version: https://drive.google.com/file/d/1636131gweiYT9em3aO28TmsUjIXy07lw/view?usp=sharing

I’m also attaching the files split into 3 and 5 parts respectively.  You can only upload 4 files at once sooooooooooooooooooo yea

Attachments:

You must be logged in to view attached files.

[Ancaritha]

I’m gonna ignore the 5th file.  I feel like you get the general idea at this point…

Attachments:

You must be logged in to view attached files.

[support]

Thanks for the log files. We have looked through them (the links to Google Drive were OK), however unfortunately there is no obvious indication of the problem there. Generally, as the OpenOCD’s STM32L0 driver is not maintained by us, it’s hard to suggest a definitive way of fixing this.

That said, please consider one of the following workarounds:

1. Try using Segger J-Link instead of OpenOCD. Segger maintains their own fully supported replacement for OpenOCD that is specifically focused on out-of-the-box support for most of the devices on the market, so it should not share any of the OpenOCD bugs.
2. Alternatively, please try building our OpenOCD fork from sources (see this tutorial for detailed steps) and try stepping through the relevant FLASH loader code. If you could pinpoint a specific cause for this, we will be happy to include a fix in our fork as long as it doesn’t break the backward compatibility.
3. If you can reliably reproduce the problem, please consider filing a bug report via the OpenOCD mailing list. The maintainer of the STM32L0 driver might be able to pinpoint the problem and fix it based on the logs you have collected. If the fix is included in the regular OpenOCD repository, we should be able to pick it up and include in our builds promptly.

[Ancaritha]

I opened a ticket with OpenOCD and posted basically the same information I posted here.  If I hear back anything interesting I’ll update this thread so you guys are made aware of it as well.

 

Thanks!

[Ancaritha]

It would appear that the incorrect target configuration file is being selected.  The “Debugged Device” drop down list just has the STM32L0xx option, which selects target/stm32l0.cfg

According to OpenOCD, approximately 2 years ago a patch was merged that makes it so now dual bank devices (such as the L07x) need to use a new configuration file, stm32l0_dual_bank.cfg.  When I manually switch to that file by modifying the command line options, it programs fine.

[support]

Thanks for pointing this out. This looks like a different issue from the other STM32L0 bug we were aware of (FLASH programming errors triggered by section alignment).

We have just released an updated OpenOCD package adding the dual-bank devices to the device selection menu (and also including latest updates from the OpenOCD repository). Please feel free to install it via Tools->VisualGDB->Manage VisualGDB Packages.

We will also review the STM32L0 device parameters during the next STM32 BSP update and will see if there is an easy way to detect the dual-bank devices automatically.

[Author]

Posts