Error finishing flash operation

Sysprogs forums Forums VisualGDB Error finishing flash operation

Viewing 15 posts - 1 through 15 (of 15 total)
  • Author
    Posts
  • #12538
    samo4
    Participant

    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
    #12548
    support
    Keymaster

    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.

    #24491
    mcipjvw
    Participant

    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, 9 months ago by mcipjvw.
    #24493
    support
    Keymaster

    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.

    #24546
    mcipjvw
    Participant

    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

     

    #24547
    support
    Keymaster

    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.

    #24744
    Ancaritha
    Participant

    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?

    #24745
    Ancaritha
    Participant

    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 🙂

    #24746
    Ancaritha
    Participant

    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.

    #24747
    Ancaritha
    Participant

    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.
    #24751
    Ancaritha
    Participant

    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.
    #24759
    support
    Keymaster

    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.
    #24786
    Ancaritha
    Participant

    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!

    #24814
    Ancaritha
    Participant

    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.

    #24818
    support
    Keymaster

    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.

Viewing 15 posts - 1 through 15 (of 15 total)
  • You must be logged in to reply to this topic.