Error erasing flash with vflasherase packet stm32

The chip must get an reset before options are reloaded. Manual reset, unpower or type «r» when you are attached.

Even with a power cycle the error happens, the programming only works when I erase the chip with JFlash

You have some sectors write protected, Write opttion byte 0x1ff80004 to zero. It seems, the L0 target missed the «monitor option erase» command other stm targets have.

Thanks for your help but it still fails

(gdb) monitor option show
0x1ff80000: 0x00aa 0xff55 OK
0x1ff80004: 0x0000 0xffff OK
0x1ff80008: 0x0000 0xffff OK

(power cycle)
..
..
(gdb) load build/test.elf
Error erasing flash with vFlashErase packet

Does the elf file do something special? Does programming succeed a second time when you erase by jlink, flash one time and immediate flash another time without starting the executable? Can you perhaps send me the elf file so I can test on some STM32L05 board?

I want to document this because my Dad and I spent two whole days solving this problem and I don’t want anyone else to waste their time like we did. We were using PlatformIO, but the underlying setup and GDB commands should be relatively easy to understand from our below configuration. We were working with the Arduino Due and Black Magic Probe v2.1 from Adafruit.

We avoided uploading/programming via the debugger altogether, and instead used another COM port with the sam-ba protocol instead. Whatever GDB commands PlatformIO thinks are right are no good either.

platformio.ini:

[env:due]
platform = atmelsam
board = due
board_build.mcu = at91sam3x8e
board_build.f_cpu = 84000000L
framework = arduino
; If any of your ports are 10 or over, use this format: \.COM10
debug_port = COM9
debug_tool = blackmagic
upload_port = COM5
upload_protocol = sam-ba
debug_load_cmd = preload
debug_load_mode = always
; debug_init_break = C:Users<Your Username>.platformiopackagesframework-arduinosamcoressammain.cpp main
debug_init_cmds = 
  define pio_reset_halt_target
    mon reset halt
    flushregs
  end
  define pio_reset_target
    mon reset
  end
  target extended-remote COM9
  monitor tpwr enable
  monitor swdp_scan
  set mem inaccessible-by-default off
  attach 1
  interrupt

Max, please state clearly where you think the error is. Is it with blackmagic or with PlatformIO? When you suspect BMP, did you upgrade the firmware to git head? And then, can you compile with ENASBLE_DEBUG=1 , open the UART console, enable debugging, type the commands by hand and post the output?
Otherwise while the thread started with STM32L0, a new issue would have been appropriate.

I see your point about STM32L0, so I think I’ll move the discussion over to #58.

Having the same error with the same target as well.

BMP Hardware: Official 2.1
Target Device: STM32L051C8T6

(gdb) mon ver
Black Magic Probe (Firmware v1.6.1) (Hardware Version 3)
Copyright (C) 2015  Black Sphere Technologies Ltd.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

(gdb) mon option show
0x1ff80000: 0x00aa 0xff55 OK
0x1ff80004: 0xffff 0x0000 OK
0x1ff80008: 0xffff 0x0000 OK
OPTR: 0x807f00aa, RDPROT 0, WPRMOD 0, WDG_SW 1, BOOT1 1
(gdb) file lorawan.elf
A program is being debugged already.
Are you sure you want to change the file? (y or n) y
Load new symbol table from "lorawan.elf"? (y or n) y
Reading symbols from lorawan.elf...done.
(gdb) load
Error erasing flash with vFlashErase packet
(gdb) load
Error erasing flash with vFlashErase packet
(gdb)

My STM32L0 is part of a RisingHF LoRaWAN module mounted on a custom breakout PCB. The device had read/write protection enabled. Based on whats above, it seems I was able to remove it. The elf file I’m using is a simple blinky application to get started messing around with the board. I have nTRST connected from the BMP to the target board as well.

This particular device seems to be tough to get attached to. I’m usually only able to attach to it right after power-up. I also can’t get any STLINK that I have to connect to it either. I’ve used a couple of the Nucleo and Discovery boards I have to try to get this thing erased or programmed with my code.

Thanks,
Andy

EDIT: code tags

Probably the device uses sleep for long periods. It is hard to attach to s long sleeping device. Connect under reset helps in this case, however voiding the program state. If you only want to program that is no problem.

Your version, also tagged stable, is ages old. Git head handles connect undr reset in a crude way, best is you try https://github.com/blacksphere/blackmagic/pull/507 (https://github.com/UweBonnes/blackmagic/tree/cortexm_romtable). Did you try with the STLINK and Stm32CubeProgrammer with connect under reset?
B.t.w. with recent f irmware, BMP can run pc-hosted as pc-stlinkv2 platform. As debug messages appear on the starting console, this can help too.

Can you make the elf file available somewhere? Is the source available/

Seen this a few times on various STM32 processors (currently working on STM32L073). I’ve found that its a problem with the NRST line on the STLINK. Don’t know why, the NRST is working and is not being held by anything. Go into the debugger setup and switch to «Software system reset», then it works.

I encounter same issue on my STM32F103ZE board.
It looks i had to press «reset» button during executing «mon swdp_scan», then it can detect the
target. after that, i have to attach 1 during a reset pulse, otherwise it wont work.
when I try to load hex file, it will fail erase error.

But I did program successfully one time after erase all and unlock security using J-Flash once.
Later it become this wired thing..

Any solutions?

Attaching to Remote target failed
(gdb) attach 1
Attaching to Remote target
Attaching to Remote target failed
(gdb) mon swdp_scan
Target voltage: ABSENT!
Available Targets:
No. Att Driver
1 STM32F1 high density M3/M4
(gdb) attach 1
Attaching to Remote target
warning: No executable has been specified and target does not support
determining executable automatically. Try using the «file» command.
0xfffffffe in ?? ()
(gdb) load
No executable file specified.
Use the «file» or «exec-file» command.
(gdb) load C://test.hex
Error erasing flash with vFlashErase packet
(gdb)

Does the program use deep sleep modes or long periods using WFI? Anything other special?

I also tried use very simple program just turn on LED by Ardunio, the result is same as Command execution from ARM Tool Chain, no much special… need manual reset during scan, and release reset during attachments, but some memory not accessible.

#define pinLED PB5

void setup() {
Serial.begin(9600);
pinMode(pinLED, OUTPUT);
Serial.println(«START»);
}

void loop() {
digitalWrite(pinLED, HIGH);
delay(2000);
digitalWrite(pinLED, LOW);
delay(2000);
Serial.println(«Hello World»);
}

Target voltage: ABSENT!
Available Targets:
No. Att Driver
1 STM32F1 high density M3/M4
Cannot access memory at address 0x8000004
Target does not support this command.
Cannot access memory at address 0x8000004
Remote failure reply: EFF
Remote failure reply: EFF
Error erasing flash with vFlashErase packet
Remote failure reply: EFF
Cannot access memory at address 0x80022d2
Running the default executable on the remote target failed; try «set remote exec-file»?

First test with ./blackmagic_stlinkv2 does not reproduce the problem:

./blackmagic_stlinkv2 -t
…
ROM: Table END
*** 1 STM32F1 medium density M3/M4
. ./blackmagic_stlinkv2 /tmp/arduino_build_495792/sketch_mar23b.ino.bin
…
*** 1 STM32F1 medium density M3/M4
Erase 11600 bytes at 0x08000000
Flashing 11600 bytes at 0x08000000
Success!

I can repeat that sequence.
Will now try with firmware BMP

Now with stlink/firmware:

(gdb) att 1
Attaching to program: /tmp/arduino_build_495792/sketch_mar23b.ino.elf, Remote target
0x08001144 in getCurrentMillis ()
(gdb) load
Loading section .isr_vector, size 0x10c lma 0x8000000
Loading section .text, size 0x2638 lma 0x800010c
Loading section .rodata, size 0x56c lma 0x8002744
Loading section .init_array, size 0x10 lma 0x8002cb0
Loading section .fini_array, size 0x8 lma 0x8002cc0
Loading section .data, size 0x88 lma 0x8002cc8
Start address 0x8001e20, load size 11600
Transfer rate: 16 KB/sec, 682 bytes/write.
(gdb) load
Loading section .isr_vector, size 0x10c lma 0x8000000
Loading section .text, size 0x2638 lma 0x800010c
Loading section .rodata, size 0x56c lma 0x8002744
Loading section .init_array, size 0x10 lma 0x8002cb0
Loading section .fini_array, size 0x8 lma 0x8002cc0
Loading section .data, size 0x88 lma 0x8002cc8
Start address 0x8001e20, load size 11600
Transfer rate: 16 KB/sec, 682 bytes/write.

Target is a Nucleo-F103RB board.

my BMP flashed with «blackmagic_dfu-swlink.bin» & «blackmagic_swlink.bin», only this works for my blue pill. I happen to try one time success on Ardunio, that is when i change BOOT(1/0) from «00» to «X0», i can see no need to hold «RESET» button and release during scan and attach etc. whole process is running, but when i reset to turn on the blue LED ligtening flash, when I try flash it again with BMP, it again not work, i tried many times same, even erase all flash sectors again with Jlink..

Okay, so you have a BMP/bluepill(swlink).
I think, my experiments show that there is no fundamental problem. So have a close look at your setup? Long wires? Flaky connection? Missing ground wire? What happens when you add additional ground wires? Can you look with a scope at the signals? Do they look rather clean?

If you add «mon conn(ect_reset) ena(ble)» and have the GND wire connected, you can spare to hold reset manually. If you loose connection, run «mon s» and «att 1» again.

I have sent the setup picture to your email box.
From my setup, use blue pill remote on another stm32F103ZE board, the SWD wire less than 10cm, tried add another GND same. I tired to add “mon connect_reset enable”,says target doesn’t support this command, the interesting finding is when I hold reset, click upload in arduino,when it pop up first red line show “stm32F1” target found, I immediately release reset, the timing is very tricky have chance to flash success as I state before, after that, it can continue success several times then again fail in access memory or write error,sometimes ACK or parity fail… thank you for help. Sorry, I don’t have scope in hand so not able to capture waveform

Will try with bluepill asap

Looks Like manual hold and release timing is quit sensitive during flash process with my setup, i may get one success case out of many tries , not like j-flash, it can halt cpu and connect at any time you want…

SRST on Bluepill should be available on P4/9 (40) , as written in platforms/swlink/README.md

What is your reset circuit? Can you try #601?

The reset circuit as below.
For the #601 try, i have stuck at #394

The image gives 404, not found.

@UweBonnes hi, I geneated new blackmagic_dfu.bin/blackmagic.bin/blackmagic_dfu.hex.
Try to upload to BMP with DFU interface, it says serial number not match.
does it mean it was a clone BMP, the DFU tool doesnt support it ?
If yes, how to fix it? thanks.

./stm32_mem.py -s Interface4 -a 0x08000000 -m ./upgrade/blackmagic_dfu.bin
Device ID: 1d50:6018
Manufacturer: b’Black Sphere Technologies’
Product: b’Black Magic Firmware Upgrade (SWLINK)’
Serial: b’E4D295B7′
Serial number doesn’t match!

stm32_mem.py -s is purely for upgrading the the debugger. Upgrading the bootloader is not needed for you, and was mostly done to be able to upgrade the bootloader on Stlink/Nucleo/Disco boards where soldering was needed to get access.

I just use Jlink to flash «blackmagic_dfu.bin» @0x08000000, then flash «blackmagic.bin» @0x08002000″, after that, reset BMP, it didnt blink DFU with green LED, just keep Red.
Is i flash wrong ?
-rwxrwx—+ 1 Administrator None 88388 3月 25 16:23 blackmagic.bin
-rwxrwx—+ 1 Administrator None 7024 3月 25 16:23 blackmagic_dfu.bin
-rwxrwx—+ 1 Administrator None 19819 3月 25 16:23 blackmagic_dfu.hex

Does anybody tried the #601 reset updates for cortexm.c, the rebuilt firmware is ok to use on BMP ?
refer to the latest built i test, the BMP is hang..

Did you build for the right Platform?
And why did you update the bootloader even when I said before it is not needed?

Do one step at a time:

• rebuild for your platform
• try to force entry to bootloader for your platform
• if unsuccessfull, reflash the bootloader
• Look, if bootloader gets active, if not, Un/Replug and look again
• if still not, investigate
• if yes, flash the BMP executable.
• Look if BMP gets active. If not, Un/Replug and look again
• if still not, can you force bootloader entry?

i have host_probe=swlink before, after rebuil, it works. now i test with my target board, i found as long as i hold reset there, use ‘mon swdp_scan’, it always can detect the hardware, but once i release the reset, it will not able to detect the target.

then, i switch to Ardunio, i have to hold the reset when click upload, once i see 1st red line showing detect the target, then i release reset (within ~1-2s), it can flash success. then i did’nt hold the reset, repeat flash can success as max as to 12 times. once it fail again. i have to reset target and BMP again, every first setup must hold reset during it detect target then release before it do attach, otherwise it will fail. sometimes i saw BMP hang with no green led on, need to do reset. Maybe it also affect by temperature since i keep flashing, but with this modificaiton ,it looks more stable than before. But for GNU command line, step by step run command will not work since need hold reset for target detection then release will not attach.

As told before, your reset time constant is about 50 times smaller than the manufacturer recommendation. Remove the strong pullup, and you get 50 times more time to responds.

Otherwise, I tried hard to reproduce your problem and I was not able to do so. I I strongly suggest you review your board for good design practice. E,g, the 1 k strong pull up is one example of no good design practice.

If your board is flaky, there is nothing that BMP can do about that.

If you find out what is flaky and you can get me to reproduce, I can however try to harden BMP.

OK, appreciate for your help !

The discussion already resulted in better libopencm3 compilation…

I have one quesiton, since the 1k pu result in 0.1 ms reset time, too slow to response leading to ACK fail etc.. but same target circuit, using Jlink (32F205), i see it can reset and halt CPU when connect it every time successfully. So, it looks like BMP MCU performance difference, if we want to make program such design target circuit stable and successfully, shall we choose another STM chip to convert it to BMP instead using F103? kindly help advise.

No, some other chip as debugger probably will not behave different. What you should try however is to use BMP/SWLIN/PC-Hosted and see if behaviour is different. And be sure to try with current git head and the stripped down Arduino example you sent me, so we talk on a common base!

I decide to change the pu resistor to 10k to test if it is stable.
Another quesiton is how fast the BMP SWD flash speed can reach? assue Clocking rate could up to 30~40 MB.
From current flash speed, it is only 22 KB/s, What is the default speed ?
Can we configure to change the Clocking Speed ?
thanks!
Start address 0x8000130, load size 45964
Transfer rate: 22 KB/sec, 957 bytes/write.

First: So you tell that it works now. But again you are not explicit and you probably did more than one step at a time.

• Did you test with 1k Pull Up and Git head?
• Did you test 50 k Pullup with a checkout before hardening reset?

Second: Does it work now and you keep controll after flashing?

Third: Look at the data sheet for flash timing. 22 kB/sec is close to what is possible with flash erase and programming times. Other device families with other flash IP go up to 80 KB/sec.Speed is mostly limited by device.

This test still with 1k pull up with Hardening reset. I wrote an automation script to run from GDB to get the test result. But it is quite unstable after flash as before communicaiton, need hold reset to try. it will interrupted by ACK fail or erase error or write error… So I decide to going to change 1K to 10K resistor then will test it again. will update result then.

That make sense on the chip device speed limitation, thanks.

Sorry, I don’t have time to flash my st-linkv2 over to BMP. Is there any way to slow down the baud rate of SWD on the BMP?

You should use blackmagic_stlinkv2 with the Stlink as it is, beside that if the firmware is too old you need it to update.

Otherwise, I have not yet seen any sensible reason to slow down the BMP/SWD.

I tried 10k pullup, after 1 time reset, it can flash more stable for couple of times
I use the latest version from Github clone, which had the harden target updated
I test ~1MB size hex file, the speed is about ~18s..

Available Targets:
No. Att Driver
1 * STM32F1 high density M3/M4
0x8000000 expect 0xffffffff after erase
Loading section .sec1, size 0x10000 lma 0x8000000
Loading section .sec2, size 0x10000 lma 0x8010000
Loading section .sec3, size 0x10000 lma 0x8020000
Loading section .sec4, size 0x10000 lma 0x8030000
Loading section .sec5, size 0x10000 lma 0x8040000
Loading section .sec6, size 0xa2e4 lma 0x8050000
Start address 0x8000130, load size 369380
Transfer rate: 23 KB/sec, 977 bytes/write.
Section .sec1, range 0x8000000 — 0x8010000: matched.
Section .sec2, range 0x8010000 — 0x8020000: matched.
Section .sec3, range 0x8020000 — 0x8030000: matched.
Section .sec4, range 0x8030000 — 0x8040000: matched.
Section .sec5, range 0x8040000 — 0x8050000: matched.
Section .sec6, range 0x8050000 — 0x805a2e4: matched.
[Inferior 1 (Remote target) detached]

Question:

• Does same BMP swlink firmware support to convert other libopencm3 supported MCU to a new BMP without any modificaiton ? I tried to convert my Target MCU board (STM32F103ZE) to BMP, but failed. i understand that the IO mapping need to make change, but dont know where to change it. Does BMP support Doc Gen to generated help document to help us understand the whole structure?

• Besides to libopencm3 supported MCU target, what else MCU can add into this BMP project?
  Any development guideline can help to understand how to add new MCU target into this BMP
  project once we had developed the flash C source files.

thanks ！

and it looks it doesnt support blank check?

Q1: Each BMP platform must define GPIOs for JTAG/SWD/UART/SWO and USB. So as soon as there are differences you need to either extend an existing platform or create a new platform. Study the differences of the different F103 platforms (native, stlin, swlink) in schematic and their corresponding platform directory. Understand the differences of your F103xE platform and then code these difference in your own platform directory. Documentation is mostly as comments in the code and comments in the git log.
Q2: Look on github for examples.
And no, there is no blank check. Where is a blank check needed?

when in automation running, if chip is blank, no need do erase whole chip for saving time.
also if have check sum verification, will save verify time for more efficiency.
Other feature like add sector program /verify; range program/verify will help completing
this magical tool.

Blank check e.g. either needs to be done one time in central BMP code, but then all flash data needs to be read via JTAG/SWD and that will take similar time as erase w/o blank check. Or for every supported target specific code needs to be written to run on the target and tested, but nobody has all supported targets to test. This is an effort that a voluntary project can do. You can either add what you need as monitor commands for your target and offer Pull Request or if you really need and you are not willing to implement yourself, buy e.g. Segger.

I am facing same issue when trying to program STM32H743 using STMCube IDE and STLINK V2.

Error: «Error erasing flash with vFlashErase packet»

Here is my workaround.
Erased the chip using STM32CubeProgrammer then reprogrammed my board.

I tried a lot of things like rebooting PC and resetting chip manually, but they don’t always work and has to be done multiple times.

Was was your problem and what errors happened? What debugger version, what chip to programm? This is not clear from your post.

This issue is becoming an aggregate for multiple problems with the same symptom. I think this is counterproductive. Can we collect the most common solutions from this issue and collect them as an FAQ in the wiki?

As >6 months passed since my inquiry with no response I am closing this issue.

This issue is closed, but if you land up here due to the magic of search engines, in your gdb console first after you did an:

attach 1

run:

monitor option erase

In some rare cases, e.g locked bootloader and try to overwrite with you new firmware one will get the dreaded «Error erasing flash with vFlashErase», trying does not hurt, maybe it fixes your issue and your development day