kernelgurumeditation commented 5 years ago

Failing to flash an unprotected chip If I erase the chip before in JFlash it will be able to program the chip one time, after that it will fail with "Error erasing flash with vFlashErase packet"

GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.5) 7.11.1 Copyright (C) 2016 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/. Find the GDB manual and other documentation resources online at: http://www.gnu.org/software/gdb/documentation/. For help, type "help". Type "apropos word" to search for commands related to "word". (gdb) target extended-remote /dev/ttyACM0 Remote debugging using /dev/ttyACM0 (gdb) monitor swdp_scan Target voltage: unknown Available Targets: No. Att Driver 1 STM32L0x (gdb) attach 1 Attaching to Remote target 0x00000000 in ?? () (gdb) monitor option show 0x1ff80000: 0x00aa 0xff55 OK 0x1ff80004: 0x8060 0x7f9f OK 0x1ff80008: 0x0000 0xffff OK OPTR: 0x806000aa, RDPROT 0, WPRMOD 0, WDG_SW 0, BOOT1 1 (gdb) load build/stm32_tamper.elf Error erasing flash with vFlashErase packet

UweBonnes commented 5 years ago

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

kernelgurumeditation commented 5 years ago

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

UweBonnes commented 5 years ago

What chip exact?

kernelgurumeditation commented 5 years ago

STM32L051R8

UweBonnes commented 5 years ago

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.

kernelgurumeditation commented 5 years ago

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

UweBonnes commented 5 years ago

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?

Maxattax97 commented 5 years ago

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>\.platformio\packages\framework-arduinosam\cores\sam\main.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

UweBonnes commented 5 years ago

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.

Maxattax97 commented 5 years ago

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

svcguy commented 5 years ago

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

UweBonnes commented 5 years ago

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.

UweBonnes commented 5 years ago

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

svcguy commented 5 years ago

Are the prebuilt binaries available on http://builds.blacksphere.co.nz/blackmagic/ newer than 1.6.1?

UweBonnes commented 5 years ago

http://builds.blacksphere.co.nz/blackmagic/ is git head

MReed1959 commented 4 years ago

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.

suibin0127 commented 4 years ago

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)

UweBonnes commented 4 years ago

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

suibin0127 commented 4 years ago

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"?

UweBonnes commented 4 years ago

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

UweBonnes commented 4 years ago

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.

suibin0127 commented 4 years ago

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..

UweBonnes commented 4 years ago

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.

suibin0127 commented 4 years ago

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

UweBonnes commented 4 years ago

Will try with bluepill asap

suibin0127 commented 4 years ago

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...

UweBonnes commented 4 years ago

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?

suibin0127 commented 4 years ago

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

UweBonnes commented 4 years ago

The image gives 404, not found.

suibin0127 commented 4 years ago

Try this link, i can see from browser. thanks. https://github.com/suibin0127/bmp/raw/master/reset.jpg

suibin0127 commented 4 years ago

if not, try this https://raw.githubusercontent.com/suibin0127/bmp/master/reset.jpg?token=AMVEGD5VNHC4WTC7YPWQDB26PIF3M

UweBonnes commented 4 years ago

Both still 404

suibin0127 commented 4 years ago

How about this ? https://raw.githubusercontent.com/suibin0127/reset/master/reset.jpg

UweBonnes commented 4 years ago

Finaly some picture. I see a strong pull up of 1 k while STM proposes to only use the internal Pullup, about 50 k. So time constants are 50 times smaller.I will try the Ardunio code soon with scuh a small pull up an will try to reproduce the error.

AlexKlimaj commented 4 years ago

I am seeing this same

Error erasing flash with vFlashErase packet

problem on a native BMP with today's binary.

UweBonnes commented 4 years ago

And what target?

AlexKlimaj commented 4 years ago

STM32F412

UweBonnes commented 4 years ago

And anything special you uploaded to the target? Help me to reproduce! Even with 1 k Pullup, I can programm and keep control of the arduino testprogram on a Nucleo-F103 and did not loose control with multiple repetitions..

UweBonnes commented 4 years ago

Can you test if #601 changes something?

AlexKlimaj commented 4 years ago

Pulled that branch into master, rebuilt, flashed, and no change.

arm-none-eabi-gdb
target extended-remote //./COM10
monitor swdp_scan
attach 1
load code.elf

UweBonnes commented 4 years ago

Do you have some Stlink e.g. on a nucleo or disco board? Can you try with blackmagic_stlinkv2.

AlexKlimaj commented 4 years ago

I can flash with an ST-Link V2 no problem.

UweBonnes commented 4 years ago

Flash with "blackmagic_stlinkv2" not the St programs.

suibin0127 commented 4 years ago

@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!

UweBonnes commented 4 years ago

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.

suibin0127 commented 4 years ago

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

suibin0127 commented 4 years ago

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..

UweBonnes commented 4 years ago

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?

suibin0127 commented 4 years ago

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.

UweBonnes commented 4 years ago

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.

blackmagic-debug / blackmagic

Error erasing flash with vFlashErase packet, Again... #414

define pinLED PB5