search

blackmagic-debug / blackmagic

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

unknown device with Designer 0x20 Part ID 0x4950 #1787

Closed DavidZemon closed 3 months ago

DavidZemon commented 8 months ago

Looks like the ST-LINK-V3MINIE is unsupported. Or maybe it's our specific STM32WB55?

captain@balrog:/$ blackmagic --verbose 1 --freq 1000000 --write ./fw_images/ringlet-bootloader.bin 0x08000000
Black Magic Debug App f3ca744a
 for Black Magic Probe, ST-Link v2 and v3, CMSIS-DAP, J-Link and FTDI (MPSSE)
Using 0483:3754 002400303033511735393935 STLINK-V3 (STMicroelectronics)

ST-Link firmware version: V3J13M4B0S0
Leaving DEBUG Mode
Target voltage: 1.79V Volt
Available speed settings: 24000/8000/3300/1000 kHz for SWD
Speed set to 1.000MHz for SWD
Leaving MASS Mode
DP DPIDR 0x6ba02477 (v2 rev0) designer 0x43b partno 0xba
TARGETID 0x04950041 designer 0x20 partno 0x4950
RESET_SEQ succeeded
AP   0: IDR=24770011 CFG=00000000 BASE=e00ff003 CSW=a3000040 (AHB3-AP var1 rev2)
Halt via DHCSR(01030003): success after 2ms
ROM: Table BASE=0xe00ff000 SYSMEM=0x00000001, Manufacturer 020 Partno 495
0 0xe000e000: Generic IP component - Cortex-M4 SCS (System Control Space) (PIDR = 0x00000004000bb00c DEVTYPE = 0x00 ARCHID = 0x0000)
-> cortexm_probe
CPUID 0x410fc241 (M4 var 0 rev 1)
Calling stm32f1_probe
Calling stm32f4_probe
Calling stm32h5_probe
Calling stm32h7_probe
Calling stm32l0_probe
Calling stm32l4_probe
Calling stm32g0_probe
Please report unknown device with Designer 0x20 Part ID 0x4950
1 0xe0001000: Generic IP component - Cortex-M3 DWT (Data Watchpoint and Trace) (PIDR = 0x00000004003bb002 DEVTYPE = 0x00 ARCHID = 0x0000)
2 0xe0002000: Generic IP component - Cortex-M3 FBP (Flash Patch and Breakpoint) (PIDR = 0x00000004002bb003 DEVTYPE = 0x00 ARCHID = 0x0000)
3 0xe0000000: Generic IP component - Cortex-M3 ITM (Instrumentation Trace Module) (PIDR = 0x00000004003bb001 DEVTYPE = 0x00 ARCHID = 0x0000)
4 0xe0040000: Debug component - Cortex-M4 TPIU (Trace Port Interface Unit) (PIDR = 0x00000004000bb9a1 DEVTYPE = 0x11 ARCHID = 0x0000)
5 0xe0041000: Debug component - Cortex-M4 ETM (Embedded Trace) (PIDR = 0x00000004000bb925 DEVTYPE = 0x13 ARCHID = 0x0000)
6 0xe0043000: Debug component - CoreSight CTI (Cross Trigger) (PIDR = 0x00000004005bb906 DEVTYPE = 0x14 ARCHID = 0x0000)
ROM: Table END
AP   1: IDR=84770001 CFG=00000000 BASE=f0000002 CSW=8b800040 (AHB3-AP var0 rev8)
0 0xf0000000: 0x00000000 <- does not match preamble (0xb105000d)
***  1   Unknown ARM Cortex-M Designer 20 Part ID 4950 M4
Unhandled exception: STLINK_SWD_DP_ERROR
dragonmux commented 8 months ago

👋🏼 Unsure where you've got your BMDA build from but that's not built from this repo directly, or was built without tags having been pulled, so the git describe tag doesn't give us any clues on where you are in the repo history.. however there are two things going on at once here:

The ST-Link v3 protocol implementation is known to have issues with multi-drop parts and needs further work to get TARGETSEL working properly, this is a known issue so if you can use a different BMDA backend such as the J-Link backend, or BMP backend, you'll have a better time of it with that as those backends do properly support multi-drop.

We suspect your BMDA build is from an older point in the repo history when the STM32WB55 was broken due to changes that had to be made in how parts were identified, and if that isn't the case then stm32l4.c needs adjusting as the part number we have matches.

DavidZemon commented 8 months ago

Indeed it is from a fork. Since you think it is our fork, I will try switching to upstream and test it out. I'll get back soon, thanks!

DavidZemon commented 8 months ago

No dice :(

Black Magic Debug App v1.10.2
 for Black Magic Probe, ST-Link v2 and v3, CMSIS-DAP, J-Link and FTDI (MPSSE)
Using 0483:3754 002400303033511735393935 STMicroelectronics
 STLINK-V3 ---
ST-Link firmware version: V3J13M4B0S0
Leaving DEBUG Mode
Target voltage: 1.79V Volt
Available speed settings: 24000/8000/3300/1000 kHz for SWD
Speed set to 1.000MHz for SWD
Leaving MASS Mode
DP DPIDR 0x6ba02477 (v2 rev0) designer 0x43b partno 0xba
TARGETID 0x04950041 designer 0x20 partno 0x4950
AP   0: IDR=24770011 CFG=00000000 BASE=e00ff003 CSW=a3000040 (AHB3-AP var1 rev2)
Halt via DHCSR(01030003): success after 2ms
ROM: Table BASE=0xe00ff000 SYSMEM=0x00000001, Manufacturer 020 Partno 495
0 0xe000e000: Generic IP component - Cortex-M4 SCS (System Control Space) (PIDR = 0x00000004000bb00c DEVTYPE = 0x00 ARCHID = 0x0000)
-> cortexm_probe
CPUID 0x410fc241 (M4 var 0 rev 1)
ID Code: 00004950
STM32W security enabled
1 0xe0001000: Generic IP component - Cortex-M3 DWT (Data Watchpoint and Trace) (PIDR = 0x00000004003bb002 DEVTYPE = 0x00 ARCHID = 0x0000)
2 0xe0002000: Generic IP component - Cortex-M3 FBP (Flash Patch and Breakpoint) (PIDR = 0x00000004002bb003 DEVTYPE = 0x00 ARCHID = 0x0000)
3 0xe0000000: Generic IP component - Cortex-M3 ITM (Instrumentation Trace Module) (PIDR = 0x00000004003bb001 DEVTYPE = 0x00 ARCHID = 0x0000)
4 0xe0040000: Debug component - Cortex-M4 TPIU (Trace Port Interface Unit) (PIDR = 0x00000004000bb9a1 DEVTYPE = 0x11 ARCHID = 0x0000)
5 0xe0041000: Debug component - Cortex-M4 ETM (Embedded Trace) (PIDR = 0x00000004000bb925 DEVTYPE = 0x13 ARCHID = 0x0000)
6 0xe0043000: Debug component - CoreSight CTI (Cross Trigger) (PIDR = 0x00000004005bb906 DEVTYPE = 0x14 ARCHID = 0x0000)
ROM: Table END
AP   1: IDR=84770001 CFG=00000000 BASE=f0000002 CSW=8b800040 (AHB3-AP var0 rev8)
0 0xf0000000: 0x00000000 <- does not match preamble (0xb105000d)
Failed to setup AP (bad AP)
ST-Link v3's only support up to AP 8, tried to setup AP 9
Failed to setup AP (bad AP)
ST-Link v3's only support up to AP 8, tried to setup AP 9
***  1   STM32WBxx (secure) M4
Unhandled exception: ST-Link error
Aborted (core dumped)
dragonmux commented 8 months ago

That's showing the STM32WB55 being properly found and detected. It's also showing the current broken (but less broken) ST-Link v3 behaviour from BMDA. That at least gives us hope as it means the probe routine for the STM32WB55 is not broken and you're actually only having issues with the adaptor backend. We're aware of approximately what needs to change in the ST-Link backend but haven't managed to find time yet to address this as it will be quite time-consuming to implement a fix for.

You'd be welcome to try your hand if you like - the main problem is that the backend doesn't know how to issue what OpenOCD calls "DAP direct" commands which inhibits properly issuing TARGETSEL for DPv2+ multi-drop targets under ST-Link adaptors. This leads to the crash you see when the ST-Link v3 gets angry and throws its toys at us.

DavidZemon commented 8 months ago

Makes sense :) I wish I had time to contribute, but alas, no. The environment I'm using this in already has the STM32CubeProgrammer suite installed, so I'm switching my automation to use that for flashing & resetting instead.

Thanks for the quick feedback though!

dragonmux commented 3 months ago

👋🏼 Checking back in with this issue, after #1802 and #1826 were merged to main the ST-Link error you were seeing should have been resolved. Could you please test and let us know so we can close this issue if it is fixed, and otherwise make a note to dive this further.

DavidZemon commented 3 months ago

I'd be happy to, yes.

I'm getting a segfault now:

david@balrog:~/reusable/Code/Work/Token/halo$ blackmagic --verbose 1 --freq 1000000 --write ./mfg.bin 0x08000000
Black Magic Debug App v1.10.0-1010-ga8a5a02e
 for Black Magic Probe, ST-Link v2 and v3, CMSIS-DAP, J-Link and FTDI (MPSSE)
Using 1d50:6018 97B68D10 Black Magic Debug
 Black Magic Probe v1.9.0-1023-gf3ca744a
Target voltage: 1.8V
Speed set to 1.384MHz for SWD
Switching out of dormant state into SWD
Handling SWD multi-drop, TARGETID 0x04950041
DP DPIDR 0x6ba02477 (v2 rev6) designer 0x43b partno 0xba
TARGETID 0x04950041 designer 0x20 partno 0x4950
AP   0: IDR=24770011 CFG=00000000 BASE=e00ff000 CSW=e3000040 (AHB3-AP var1 rev2)
Halt via DHCSR(00030003): success after 33ms
ROM: Table BASE=0xe00ff000 SYSMEM=1, Manufacturer 020 Partno 495 (PIDR = 0x00000000000a0495)
0 0xe000e000: Generic IP component - Cortex-M4 SCS (System Control Space) (PIDR = 0x00000004000bb00c DEVTYPE = 0x00 ARCHID = 0x0000)
-> cortexm_probe
CPUID 0x410fc241 (M4 var 0 rev 1)
STM32W security enabled
1 0xe0001000: Generic IP component - Cortex-M3 DWT (Data Watchpoint and Trace) (PIDR = 0x00000004003bb002 DEVTYPE = 0x00 ARCHID = 0x0000)
2 0xe0002000: Generic IP component - Cortex-M3 FBP (Flash Patch and Breakpoint) (PIDR = 0x00000004002bb003 DEVTYPE = 0x00 ARCHID = 0x0000)
3 0xe0000000: Generic IP component - Cortex-M3 ITM (Instrumentation Trace Module) (PIDR = 0x00000004003bb001 DEVTYPE = 0x00 ARCHID = 0x0000)
4 0xe0040000: Debug component - Cortex-M4 TPIU (Trace Port Interface Unit) (PIDR = 0x00000004000bb9a1 DEVTYPE = 0x11 ARCHID = 0x0000)
5 0xe0041000: Debug component - Cortex-M4 ETM (Embedded Trace) (PIDR = 0x00000004000bb925 DEVTYPE = 0x13 ARCHID = 0x0000)
6 0xe0043000: Debug component - CoreSight CTI (Cross Trigger) (PIDR = 0x00000004005bb906 DEVTYPE = 0x14 ARCHID = 0x0000)
ROM: Table END
AP   1: IDR=84770001 -> Not Present
SWD access resulted in no response
SWD access resulted in no response
SWD access resulted in no response
SWD access resulted in no response
SWD access resulted in no response
SWD access resulted in no response
SWD access resulted in no response
SWD access resulted in no response
SWD access resulted in no response
SWD access resulted in no response
SWD access resulted in no response
SWD access resulted in no response
SWD access resulted in no response
SWD access resulted in no response
SWD access resulted in no response
***  1   STM32WBxx (secure) M4
Segmentation fault (core dumped)

Not sure if this is a build mixup on my end. It's been months since I had to build blackmagic. I produced this build with the following commands, starting from our local fork:

git remote add upstream https://github.com/blackmagic-debug/blackmagic.git
git fetch -u upstream
git checkout upstream/main
git clean -fdX
meson setup build
meson compile -C build

And then I copied build/blackmagic into a directory that is on $PATH and ran the above-mentioned command.

dragonmux commented 3 months ago

Doesn't look like a build issue 🤔. Could you please do the following from inside your build directory to get a trace of why the core dump (otherwise, that trace is looking so much better!):

meson configure --buildtype=debugoptimized -Db_sanitize=address,undefined
ninja
gdb --args ./blackmagic -tv 5`

Then on the GDB prompt type r, then when it crashes bt and share the results here.

DavidZemon commented 3 months ago 
david@balrog:~/reusable/Code/Work/Token/blackmagic/build$ gdb --args ./blackmagic -tv 5
GNU gdb (Ubuntu 14.0.50.20230907-0ubuntu1) 14.0.50.20230907-git
Copyright (C) 2023 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:
<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"...
Really redefine built-in command "remote"? (y or n) [answered Y; input not from terminal]
Reading symbols from ./blackmagic...
(gdb) r
Starting program: /home/david/reusable/Code/Work/Token/blackmagic/build/blackmagic -tv 5

This GDB supports auto-downloading debuginfo from the following URLs:
  <https://debuginfod.ubuntu.com>
Enable debuginfod for this session? (y or [n]) y
Debuginfod has been enabled.
To make this setting permanent, add 'set debuginfod enabled on' to .gdbinit.
[Thread debugging using libthread_db enabled]                                                                                                                    
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ffff39ff6c0 (LWP 557607)]                                                                                                                         
Black Magic Debug App v1.10.0-1010-ga8a5a02e
 for Black Magic Probe, ST-Link v2 and v3, CMSIS-DAP, J-Link and FTDI (MPSSE)
Using 0483:3754 002000273033511835393935 STMicroelectronics
 STLINK-V3 ---
ST-Link firmware version: V3J13M4B0S0
Leaving MASS Mode
Running in Test Mode
Target voltage: 0.00V
Available speed settings: 24000/8000/3300 kHz for SWD
Speed set to 3.300MHz for SWD
Leaving MASS Mode
Failure reading IDCODE
No target found
[Thread 0x7ffff39ff6c0 (LWP 557607) exited]
==557599==LeakSanitizer has encountered a fatal error.
==557599==HINT: For debugging, try setting environment variable LSAN_OPTIONS=verbosity=1:log_threads=1
==557599==HINT: LeakSanitizer does not work under ptrace (strace, gdb, etc)
[Inferior 1 (process 557599) exited with code 01]
(gdb) bt
No stack.
(gdb) quit

Across multiple runs, I was not able to get it to crash with -t

I reran it with the --write command and was able to reproduce the problem:

david@balrog:~/reusable/Code/Work/Token/blackmagic/build$ gdb --args ./blackmagic -v5 --freq 1000 --write ../../halo/mfg.bin 0x08000000
GNU gdb (Ubuntu 14.0.50.20230907-0ubuntu1) 14.0.50.20230907-git
Copyright (C) 2023 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:
<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"...
Really redefine built-in command "remote"? (y or n) [answered Y; input not from terminal]
Reading symbols from ./blackmagic...
(gdb) r
Starting program: /home/david/reusable/Code/Work/Token/blackmagic/build/blackmagic -v5 --freq 1000 --write ../../halo/mfg.bin 0x08000000

This GDB supports auto-downloading debuginfo from the following URLs:
  <https://debuginfod.ubuntu.com>
Enable debuginfod for this session? (y or [n]) y
Debuginfod has been enabled.
To make this setting permanent, add 'set debuginfod enabled on' to .gdbinit.
Downloading separate debug info for /lib/x86_64-linux-gnu/libusb-1.0.so.0                                                                                        
[Thread debugging using libthread_db enabled]                                                                                                                    
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Downloading separate debug info for /lib/x86_64-linux-gnu/libgcc_s.so.1
Downloading separate debug info for /lib/x86_64-linux-gnu/libstdc++.so.6                                                                                         
Downloading separate debug info for /lib/x86_64-linux-gnu/libcap.so.2                                                                                            
[New Thread 0x7ffff39ff6c0 (LWP 559668)]                                                                                                                         
Black Magic Debug App v1.10.0-1010-ga8a5a02e
 for Black Magic Probe, ST-Link v2 and v3, CMSIS-DAP, J-Link and FTDI (MPSSE)
Using 0483:3754 002000273033511835393935 STMicroelectronics
 STLINK-V3 ---
ST-Link firmware version: V3J13M4B0S0
Leaving MASS Mode
Target voltage: 1.79V
Available speed settings: 24000/8000/3300/1000/200/50/5 kHz for SWD
Speed set to 0.005MHz for SWD
Leaving MASS Mode
DP DPIDR 0x6ba02477 (v2 rev6) designer 0x43b partno 0xba
TARGETID 0x04950041 designer 0x20 partno 0x4950
AP   0: IDR=24770011 CFG=00000000 BASE=e00ff000 CSW=e3000040 (AHB3-AP var1 rev2)
Halt via DHCSR(00030003): success after 73ms
ROM: Table BASE=0xe00ff000 SYSMEM=1, Manufacturer 020 Partno 495 (PIDR = 0x00000000000a0495)
0 0xe000e000: Generic IP component - Cortex-M4 SCS (System Control Space) (PIDR = 0x00000004000bb00c DEVTYPE = 0x00 ARCHID = 0x0000)
-> cortexm_probe
CPUID 0x410fc241 (M4 var 0 rev 1)
cortexm_probe: Examining Part ID 0x4950, AP Part ID: 0x0495
Calling stm32f1_probe
Calling stm32f4_probe
Calling stm32h5_probe
Calling stm32h7_probe
Calling stm32mp15_cm4_probe
Calling stm32l0_probe
Calling stm32l1_probe
Calling stm32l4_probe
STM32W security enabled
1 0xe0001000: Generic IP component - Cortex-M3 DWT (Data Watchpoint and Trace) (PIDR = 0x00000004003bb002 DEVTYPE = 0x00 ARCHID = 0x0000)
2 0xe0002000: Generic IP component - Cortex-M3 FBP (Flash Patch and Breakpoint) (PIDR = 0x00000004002bb003 DEVTYPE = 0x00 ARCHID = 0x0000)
3 0xe0000000: Generic IP component - Cortex-M3 ITM (Instrumentation Trace Module) (PIDR = 0x00000004003bb001 DEVTYPE = 0x00 ARCHID = 0x0000)
4 0xe0040000: Debug component - Cortex-M4 TPIU (Trace Port Interface Unit) (PIDR = 0x00000004000bb9a1 DEVTYPE = 0x11 ARCHID = 0x0000)
5 0xe0041000: Debug component - Cortex-M4 ETM (Embedded Trace) (PIDR = 0x00000004000bb925 DEVTYPE = 0x13 ARCHID = 0x0000)
6 0xe0043000: Debug component - CoreSight CTI (Cross Trigger) (PIDR = 0x00000004005bb906 DEVTYPE = 0x14 ARCHID = 0x0000)
ROM: Table END
AP   1: IDR=84770001 -> Not Present
***  1   STM32WBxx (secure) M4
ST-Link v2/v3 adaptors cannot handle multi-drop correctly, pretending everything's fine
../src/target/stm32l4.c:606:12: runtime error: member access within null pointer of type 'const struct stm32l4_device_info_s'

Thread 1 "blackmagic" received signal SIGSEGV, Segmentation fault.
0x0000555555737b42 in stm32l4_configure_dbgmcu (target=target@entry=0x614000015640, device=device@entry=0x0) at ../src/target/stm32l4.c:606
606     if (device->family == STM32L4_FAMILY_L55x || device->family == STM32L4_FAMILY_U5xx) {
(gdb) bt
#0  0x0000555555737b42 in stm32l4_configure_dbgmcu (target=target@entry=0x614000015640, device=device@entry=0x0) at ../src/target/stm32l4.c:606
#1  0x00005555557389fa in stm32l4_attach (target=0x614000015640) at ../src/target/stm32l4.c:680
#2  0x00005555556bf6f4 in target_attach (target=0x614000015640, controller=controller@entry=0x5555558eecc0 <cl_controller>) at ../src/target/target.c:189
#3  0x00005555556bf909 in target_attach_n (n=n@entry=1, controller=controller@entry=0x5555558eecc0 <cl_controller>) at ../src/target/target.c:176
#4  0x000055555574893d in cl_execute (opt=opt@entry=0x555555937da0 <cl_opts>) at ../src/platforms/hosted/cli.c:495
#5  0x0000555555743b34 in platform_init (argc=argc@entry=7, argv=<optimized out>) at ../src/platforms/hosted/platform.c:183
#6  0x000055555568f9c5 in main (argc=7, argv=<optimized out>) at ../src/main.c:75
(gdb) quit
A debugging session is active.

    Inferior 1 [process 559660] will be killed.

Quit anyway? (y or n) y
dragonmux commented 3 months ago

Ahhh, we see what's happened here - that's our fault! Please could you try the patch below and let us know if that makes things any happier:

diff --git a/src/target/stm32l4.c b/src/target/stm32l4.c
index da028c0b3..325bbc8ad 100644
--- a/src/target/stm32l4.c
+++ b/src/target/stm32l4.c
@@ -575,7 +575,7 @@ static uint32_t stm32l4_main_sram_length(const target_s *const target)
    return (device->sram1 + device->sram2 + device->sram3) * 1024U;
 }

-static bool stm32l4_configure_dbgmcu(target_s *const target, const stm32l4_device_info_s *device)
+static bool stm32l4_configure_dbgmcu(target_s *const target, const stm32l4_device_info_s *const device)
 {
    /* If we're in the probe phase */
    if (target->target_storage == NULL) {
@@ -603,7 +603,7 @@ static bool stm32l4_configure_dbgmcu(target_s *const target, const stm32l4_devic
     * Now we have a stable debug environment, make sure the WDTs can't bonk the processor out from under us,
     * then Reconfigure the config register to prevent WFI/WFE from cutting debug access
     */
-   if (device->family == STM32L4_FAMILY_L55x || device->family == STM32L4_FAMILY_U5xx) {
+   if (priv->device->family == STM32L4_FAMILY_L55x || priv->device->family == STM32L4_FAMILY_U5xx) {
        target_mem32_write32(
            target, STM32L5_DBGMCU_APB1FREEZE1, STM32L4_DBGMCU_APB1FREEZE1_IWDG | STM32L4_DBGMCU_APB1FREEZE1_WWDG);
        target_mem32_write32(target, STM32L5_DBGMCU_CONFIG,

If this does work we'll get it PRed as a fixup to #1882 which is the PR that introduced stm32l4_configured_dbgmcu() and that logic mistake.

DavidZemon commented 3 months ago

That worked! Thanks.

dragonmux commented 3 months ago

We'll get it turned into a PR then and link it as fixing this issue - thank you for testing.

DavidZemon commented 3 months ago

No problem. Thanks for the hard work you all put into this project.

We're still using ST's native tools for a lot of what we're doing, but I'll switch back to blackmagic for everything that we can. The docker image we use for provisioning new boards actually has both the ST tools and the blackmagic executable simply because of your -l argument. It makes it so much easier to programmatically figure out what probes are plugged in than anything direct from ST.