search

blackmagic-debug / blackmagic

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

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

Open DavidZemon opened 3 months ago

DavidZemon commented 3 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 3 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 3 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 3 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 3 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 3 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!