search

blackmagic-debug / blackmagic

In application debugger for ARM Cortex microcontrollers.
GNU General Public License v3.0
3.23k stars 768 forks source link

Error writing data to flash #1128

Closed silverv closed 2 years ago

silverv commented 2 years ago 
arm-none-eabi-gdb /home/silver/zubax/sapog2/firmware/build/compound.elf -ex "target extended-remote /dev/ttyACM0" -ex "monitor connect_srst enable" -ex "mon swdp_scan" -ex "attach 1" -ex "load" -ex "kill" -ex "quit" -nh --batch

warning: Loadable section "bootloader" outside of ELF segments
Assert SRST during connect: enabled
Target voltage: 3.3V
Available Targets:
No. Att Driver
 1      STM32F1  VL density M3
0x08000e9e in ?? ()
Loading section bootloader, size 0xaf2c lma 0x8000000
Loading section startup, size 0x1a0 lma 0x8008800
Loading section constructors, size 0xf8 lma 0x80089a0
Loading section .padding1, size 0x8 lma 0x8008a98
Loading section .text, size 0x1aa61 lma 0x8008aa0
Error writing data to flash

I am unable to get a more precise error. I opened a vcom: picocom --quiet \$(realpath /dev/serial/by-id/usb-Black*-if02) -b 115200 to see that it provides no output. I am flashing using a native Blackmagic (https://shop.zubax.com/products/dronecode-probe-v2-2-jtag-swd-adapter-usb-uart-adapter-with-dcd-m-cable?variant=8797640687715) I am flashing the STM32F105/107 chip

I am attaching the ELF file that I am trying to upload and the map file zipped. build.zip This is the open source Sapog firmware which I have previously successfully flashed onto the device (hundreds of times). https://github.com/Zubax/sapog/tree/v3

UweBonnes commented 2 years ago

Is the device protected? After attaching, check with "mon opt". If protected, reset protection with "mon opt erase".

silverv commented 2 years ago

General commands: version -- Display firmware version info help -- Display help for monitor commands jtag_scan -- Scan JTAG chain for devices swdp_scan -- Scan SW-DP for devices targets -- Display list of available targets morse -- Display morse error message halt_timeout -- Timeout (ms) to wait until Cortex-M is halted: (Default 2000) connect_srst -- Configure connect under SRST: (enable|disable) hard_srst -- Force a pulse on the hard SRST line - disconnects target tpwr -- Supplies power to the target: (enable|disable) traceswo -- Start trace capture, Manchester mode: (decode channel ...) heapinfo -- Set semihosting heapinfo Black Magic Probe (Firmware v1.7.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

silverv commented 2 years ago

I can use these commands

UweBonnes commented 2 years ago

Start arm-none-eabi-gdb. Connect to the debugger "tar ext /dev/ttyACM0". Scan SWD "mon s". Attach to the device "att 1". See monitor commands available for that device "mon help". Read the option bits "mon opt". Eventually erase the protection "mon opt erase".

silverv commented 2 years ago

I think that command is still not available, but attaching first helped get access to more commands

arm-none-eabi-gdb /home/silver/zubax/sapog2/firmware/build/compound.elf 
-ex "target extended-remote /dev/ttyACM0" 
-ex "monitor connect_srst enable" 
-ex "mon swdp_scan" 
-ex "attach 1" 
-ex "mon help" 
-ex "mon version" 
-ex "mon option" 
-ex "mon opt erase" 
-ex "load" 
-ex "kill" 
-ex "quit" -nh --batch

warning: Loadable section "bootloader" outside of ELF segments
Assert SRST during connect: enabled
Target voltage: 3.3V
Available Targets:
No. Att Driver
 1      STM32F1  VL density M3
0x08000e9e in ?? ()
General commands:
        version -- Display firmware version info
        help -- Display help for monitor commands
        jtag_scan -- Scan JTAG chain for devices
        swdp_scan -- Scan SW-DP for devices
        targets -- Display list of available targets
        morse -- Display morse error message
        halt_timeout -- Timeout (ms) to wait until Cortex-M is halted: (Default 2000)
        connect_srst -- Configure connect under SRST: (enable|disable)
        hard_srst -- Force a pulse on the hard SRST line - disconnects target
        tpwr -- Supplies power to the target: (enable|disable)
        traceswo -- Start trace capture, Manchester mode: (decode channel ...)
        heapinfo -- Set semihosting heapinfo
ARM Cortex-M specific commands:
        vector_catch -- Catch exception vectors
STM32 HF/CL/VL-HD specific commands:
        erase_mass -- Erase entire flash memory
        option -- Manipulate option bytes
Black Magic Probe (Firmware v1.7.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>

usage: monitor option erase
usage: monitor option <addr> <value>
0x1FFFF800: 0x5AA5
0x1FFFF802: 0xFFFF
0x1FFFF804: 0xFFFF
0x1FFFF806: 0xFFFF
0x1FFFF808: 0xFFFF
0x1FFFF80A: 0xFFFF
0x1FFFF80C: 0xFFFF
0x1FFFF80E: 0xFFFF
0x1FFFF800: 0x5AA5
0x1FFFF802: 0xFFFF
0x1FFFF804: 0xFFFF
0x1FFFF806: 0xFFFF
0x1FFFF808: 0xFFFF
0x1FFFF80A: 0xFFFF
0x1FFFF80C: 0xFFFF
0x1FFFF80E: 0xFFFF
Loading section bootloader, size 0xaf2c lma 0x8000000
Loading section startup, size 0x1a0 lma 0x8008800
Loading section constructors, size 0xf8 lma 0x80089a0
Loading section .padding1, size 0x8 lma 0x8008a98
Loading section .text, size 0x1aa61 lma 0x8008aa0
Error writing data to flash
UweBonnes commented 2 years ago

Changed option bits only take effect after reset/repower. Rescan and try again. With "connect_srst enable" , "mon s" dose a reset.

silverv commented 2 years ago

Our devices have no flash protection

UweBonnes commented 2 years ago

So this means that even after option erase and a reset/replug flashing failed? Can you compile BMDA and run "blackmagic .../compound.bin". This should give more verbose output and maybe show the place where "Error writing data to flash" happens.

dragonmux commented 2 years ago

Ignore Uwe here, we can see this is a bug and we'll look into what's going on here.

Edit: Correction we can see you're running firmware v1.7.1 - please update to v1.8.2 and try again. If you can recreate the issue on the most recent release firmware we'll consider it a bug and dive deeper.

silverv commented 2 years ago

I will provide you with info on v1.8.2 but I've tried with 1.8.0 and it errored at the same place

silverv commented 2 years ago

Confirmed bug on 1.8.2

silver@silver:~/zubax/sapog2/firmware$ arm-none-eabi-gdb /home/silver/zubax/sapog2/firmware/build/compound.elf -ex "target extended-remote /dev/ttyACM0" -ex "monitor connect_srst enable" -ex "mon swdp_scan" -ex "attach 1"
GNU gdb (GNU Arm Embedded Toolchain 10.3-2021.10) 10.2.90.20210621-git
Copyright (C) 2021 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 "--host=x86_64-linux-gnu --target=arm-none-eabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://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"...
Reading symbols from /home/silver/zubax/sapog2/firmware/build/compound.elf...

warning: Loadable section "bootloader" outside of ELF segments
Remote debugging using /dev/ttyACM0
Assert SRST during connect: enabled
Target voltage: 3.3V
Available Targets:
No. Att Driver
 1      STM32F1  VL density M3
Attaching to program: /home/silver/zubax/sapog2/firmware/build/compound.elf, Remote target
0x08000e9e in ?? ()
(gdb) mon help
General commands:
        version -- Display firmware version info
        help -- Display help for monitor commands
        jtag_scan -- Scan JTAG chain for devices
        swdp_scan -- Scan SW-DP for devices
        frequency -- set minimum high and low times
        targets -- Display list of available targets
        morse -- Display morse error message
        halt_timeout -- Timeout (ms) to wait until Cortex-M is halted: (Default 2000)
        connect_srst -- Configure connect under SRST: (enable|disable)
        hard_srst -- Force a pulse on the hard SRST line - disconnects target
        tpwr -- Supplies power to the target: (enable|disable)
        traceswo -- Start trace capture, Manchester mode: (decode channel ...)
        heapinfo -- Set semihosting heapinfo
ARM Cortex-M specific commands:
        vector_catch -- Catch exception vectors
STM32 HF/CL/VL-HD specific commands:
        erase_mass -- Erase entire flash memory
        option -- Manipulate option bytes
(gdb) mon traceswo
C2D6BBE4:05:85
(gdb) load
Loading section bootloader, size 0xaf2c lma 0x8000000
Loading section startup, size 0x1a0 lma 0x8008800
Loading section constructors, size 0xf8 lma 0x80089a0
Loading section .padding1, size 0x8 lma 0x8008a98
Loading section .text, size 0x1aa60 lma 0x8008aa0
Error writing data to flash
(gdb) version
Undefined command: "version".  Try "help".
(gdb) mon version
Black Magic Probe v1.8.2, Hardware Version 3
Copyright (C) 2022 Black Magic Debug Project
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

(gdb)
dragonmux commented 2 years ago

Thank you for verifying that it is non-functional on v1.8.2 - we'll do what we can to look into why this is not working for the F105/F107 devices while it does work for F103 et al.

One thing that would be most helpful now you've confirmed it's a bug on the most recent release is if you could try the debug build we dropped in the 1b² Discord #blackmagic channel and as per #1140 provide the output from minicom -D /dev/ttyBmpTarg -8 after enabling the extra debug information with monitor debug_bmp enable right after connecting into BMP. This will give us a lot more detail as to what is going on and a direction in which to look.

Small nitpick from the original issue post, the Zubax dronecode probe is not an official BMP but rather a clone so there is the off-chance that we're looking at an issue they've caused rather than a bug in the Black Magic Firmware itself - but in the off chance it is our bug, we'll ignore that for now.

silverv commented 2 years ago

Can I use picocom instead, minicom didn't work and froze. I used picocom like this:

picocom -b 115200 /dev/serial/by-id/usb-Black_Magic_Debug_Black_Magic_Probe_v1.8.0-276-g7c14b624-dirty_C2D6BBE4-if00
picocom v3.1

port is        : /dev/serial/by-id/usb-Black_Magic_Debug_Black_Magic_Probe_v1.8.0-276-g7c14b624-dirty_C2D6BBE4-if00
flowcontrol    : none
baudrate is    : 115200
parity is      : none
databits are   : 8
stopbits are   : 1
escape is      : C-a
local echo is  : no
noinit is      : no
noreset is     : no
hangup is      : no
nolock is      : no
send_cmd is    : sz -vv
receive_cmd is : rz -vv -E
imap is        : 
omap is        : 
emap is        : crcrlf,delbs,
logfile is     : none
initstring     : none
exit_after is  : not set
exit is        : no

Type [C-a] [C-h] to see available commands
Terminal ready
+$#00$#00$#00$#00
Terminating...
Thanks for using picocom
dragonmux commented 2 years ago

If you're going to use by-id rather than the /dev/tty* paths, it's -if02 not -if00 as you're attaching into the GDB server there, not the debug UART. This would also be why minicom (correctly) froze

silverv commented 2 years ago

So after doing 

silver@silver:~/zubax/blackmagic$ arm-none-eabi-gdb /home/silver/zubax/sapog2/firmware/build/compound.elf -ex "target extended-remote /dev/serial/by-id/usb-Black_Magic_Debug_Black_Magic_Probe_v1.8.0-276-g7c14b624-dirty_C2D6BBE4-if00" -ex "mon debug_bmp enable" -ex "mon swdp_scan" -ex "attach 1" -ex "load"
GNU gdb (GNU Arm Embedded Toolchain 10.3-2021.10) 10.2.90.20210621-git
Copyright (C) 2021 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 "--host=x86_64-linux-gnu --target=arm-none-eabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://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"...
Reading symbols from /home/silver/zubax/sapog2/firmware/build/compound.elf...

warning: Loadable section "bootloader" outside of ELF segments
Remote debugging using /dev/serial/by-id/usb-Black_Magic_Debug_Black_Magic_Probe_v1.8.0-276-g7c14b624-dirty_C2D6BBE4-if00
Debug mode is enabled
Target voltage: 3.3V
Available Targets:
No. Att Driver
 1      STM32F1  VL density M3
Attaching to program: /home/silver/zubax/sapog2/firmware/build/compound.elf, Remote target
0x08000e9e in ?? ()
Loading section bootloader, size 0xaf2c lma 0x8000000
Loading section startup, size 0x1a0 lma 0x8008800
Loading section constructors, size 0xf8 lma 0x80089a0
Loading section .padding1, size 0x8 lma 0x8008a98
Loading section .text, size 0x1aa60 lma 0x8008aa0
Error writing data to flash
(gdb)

in one terminal and having opened the serial interface with picocom in the other one, I got this output:

silver@silver:~/zubax/sapog2/firmware$ picocom -b 115200 /dev/serial/by-id/usb-Black_Magic_Debug_Black_Magic_Probe_v1.8.0-276-g7c14b624-dirty_C2D6BBE4-if02
picocom v3.1

port is        : /dev/serial/by-id/usb-Black_Magic_Debug_Black_Magic_Probe_v1.8.0-276-g7c14b624-dirty_C2D6BBE4-if02
flowcontrol    : none
baudrate is    : 115200
parity is      : none
databits are   : 8
stopbits are   : 1
escape is      : C-a
local echo is  : no
noinit is      : no
noreset is     : no
hangup is      : no
nolock is      : no
send_cmd is    : sz -vv
receive_cmd is : rz -vv -E
imap is        : 
omap is        : 
emap is        : crcrlf,delbs,
logfile is     : none
initstring     : none
exit_after is  : not set
exit is        : no

Type [C-a] [C-h] to see available commands
Terminal ready
DPIDR 0x1ba01477 (v1 rev0)
RESET_SEQ failed
AP   0: IDR=14770011 CFG=00000000 BASE=e00ff003 CSW=23000040 (AHB-AP var1 rev1)
Halt via DHCSR: success 01030003 after 0ms
ROM: Table BASE=0xe00ff000 SYSMEM=0x00000001, Manufacturer  20 Partno 410
0 0xe000e000: Generic IP component - Cortex-M3 SCS (System Control Space) (PIDR = 0x04001bb000  DEVTYPE = 0x0hx ARCHID = 0x0000-> cortexm_probe
CPUID 0x411fc231 (M3 var 1 rev 1)
1 0xe0001000: Generic IP component - Cortex-M3 DWT (Data Watchpoint and Trace) (PIDR = 0x04001bb002  DEVTYPE = 0x0hx ARCHID = 02 0xe0002000: Generic IP component - Cortex-M3 FBP (Flash Patch and Breakpoint) (PIDR = 0x04000bb003  DEVTYPE = 0x0hx ARCHID = 3 0xe0000000: Generic IP component - Cortex-M3 ITM (Instrumentation Trace Module) (PIDR = 0x04001bb001  DEVTYPE = 0x0hx ARCHID 4 0xe0040000: Debug component - Cortex-M3 TPIU (Trace Port Interface Unit) (PIDR = 0x04001bb923  DEVTYPE = 0x0hx ARCHID = 0x0015 0xe0041000: Debug component - Cortex-M3 ETM (Embedded Trace) (PIDR = 0x04101bb924  DEVTYPE = 0x0hx ARCHID = 0x0013)
ROM: Table END
stm32f1 flash write error 0x24
dragonmux commented 2 years ago

Thank you, we'll dive into how Flash error 0x24 can be generated and what the manual for that processor says about the subject.

silverv commented 2 years ago

And this device is flashable with an elf which is generated using: https://gist.github.com/pavel-kirienko/6835194423df07f6160af19f7ea33a4d which generates a sectionless elf as far as I understand. But I do need the sections for GDB debugging. Also is flashable using STLink v2.

silverv commented 2 years ago

https://www.st.com/en/microcontrollers-microprocessors/stm32f105-107.html#documentation

esden commented 2 years ago

Hi @silverv,

Thank you for reporting your problem. First of all the zubax dronecode-probe is not an official native Black Magic Probe. It is a 3rd party device. The official hardware is the Black Magic Probe offered by 1BitSquared and Adafruit. The zubax people don't test their hardware or contribute to this project. They just made a low effort hardware that is trying to be compatible with the firmware we distribute. So we have no way to make sure the issue is not related to the programmer hardware you have.

We currently don't have the STM32F105/107 chips to test with and try to reproduce your issue with. If you want to contribute one of your chips to the cause that would be greatly appreciated. That said I will add them to my "to obtain" list so we can add it to our target hardware zoo, but that might take quite a while. As far as I can see it from your attempts, it will be pretty difficult for us to figure out what the issue is without having the target hardware on our bench.

That said, we do program STM32F103 quite a lot as that used to be on every black magic probe from the past, so I will be very surprised if the issue is actually with the flashing routine, also you have shown your hardware is not locked so that is not the problem.

There is one more potential issue. I have seen flashing issues when the power supply to the target STM32 is not well filtered, stable and strong enough. The flashing process does draw quite a lot of power, with a lot of spikes so it can cause issues. The documentation does show voltage requirements depending on PSIZE, so if your supply dips below the required voltage it might be an issue. I think an option here would be to decrease the size of flash write word size. We don't currently have an option to adjust that through the monitor commands so you will have to change that in the firmware itself.

I will add the word write size adjustment monitor command to our list of future enhancements.

I hope you can find a way to resolve your issue.

Cheers, Piotr

silverv commented 2 years ago

@esden I also have this device: Black Magic Probe v1.8.2, Hardware Version 1 Copyright (C) 2022 Black Magic Debug Project License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html

Do you think this would be more likely to replicate the problem?

silverv commented 2 years ago

This flash writing problem is also elf file dependent, just bringing this out once more. It's got to do with the alignment or different sections.

silverv commented 2 years ago

20220729_124548 This is the Hardware version 1 device I have

silverv commented 2 years ago

The same error happens with this device and the same elf file.

silverv commented 2 years ago

I am attaching two elf files, they are different in their sections. They are named to show which one uploads well and which one doesn't. elf files.zip

silverv commented 2 years ago

I am also attaching another elf file which also successfully uploads but contains the much needed debug data and a lot of sections. useful-and-works.elf.zip

silverv commented 2 years ago

If you want to reproduce this then maybe try uploading the same ELF on any of the available platforms you have and see what kind of result you get. If there's at least 158 KB of memory then it should work although I am not sure.

silverv commented 2 years ago

I also found a major alignment issue on my side in the elf, please ignore this issue for now.

silverv commented 2 years ago

My bootloader was overlapping my application and alignment wasn't correct, only a pure image transfer would work but then it would be hiding problems.