STM32F103C8: Unknown ARM Cortex-M Designer 0x8000 Part ID 0x0 M3

[aguaviva]

Sounds like this is might be a known issue but couldn't find anything:

Chip: STM32F103C8T6 ARM STM32 Minimum System Development Board Module

GDB's output

(gdb) monitor sw
Target voltage: 3.03V
You are now detached from the previous target.
Please report unknown device with Designer 0x8000 Part ID 0x0
Available Targets:
No. Att Driver
*** 1   Unknown ARM Cortex-M Designer 0x8000 Part ID 0x0 M3

How could I help debug this?

[dragonmux]

That doesn't look like normal output from a legitimate STM32F1 or any of the known clones.. looks in fact like someone cloned it and then entirely borked the ROM tables.

What version of the firmware was this with? Can you get a ROM table dump with BMDA as in blackmagic -tv 5? That would be the most helpful for figuring out what is going on to result in an ASCII_CODE_FLAG designer code (bad!) w/ an invalid part ID.

Depending on what that reveals, the best path forward is some clone-specific handling added to

blackmagic/src/target/cortexm.c

Lines 671 to 681 in 1e1b1d9

	case ASCII_CODE_FLAG:
	/*
	* these devices enumerate an AP with an empty ascii code,
	* and have no available designer code elsewhere
	*/
	PROBE(sam3x_probe);
	PROBE(ke04_probe);
	PROBE(lpc17xx_probe);
	PROBE(lpc11xx_probe); /* LPC1343 */
	break;
	}

[aguaviva]

Here it is:

$ ./blackmagic -tv 5
Black Magic Debug App v1.10.0-635-gb386fae4-dirty
 for Black Magic Probe, ST-Link v2 and v3, CMSIS-DAP, J-Link and FTDI (MPSSE)
Using 1d50:6018 8FB7347E Black Magic Debug
 Black Magic Probe (ST-Link/v2) v1.10.0-635-gb386fae4-dirty
Running in Test Mode
Target voltage: 3.02V Volt
Speed set to 6.000MHz for SWD
Switching out of dormant state into SWD
SWD access resulted in no response
Deprecated JTAG to SWD sequence
DP DPIDR 0x2ba01477 (v1 rev0) designer 0x43b partno 0xba
AP   0: IDR=24770011 CFG=00000000 BASE=e00ff003 CSW=a3000040 (AHB3-AP var1 rev2)
Halt via DHCSR(00030003): success after 19ms
ROM: Table BASE=0xe00ff000 SYSMEM=0x00000001, Manufacturer 8000 Partno 000
0 0xe000e000: Generic IP component - Cortex-M3 SCS (System Control Space) (PIDR = 0x00000004002bb000 DEVTYPE = 0x00 ARCHID = 0x0000)
-> cortexm_probe
CPUID 0x412fc230 (M3 var 2 rev 0)
Calling sam3x_probe
Calling ke04_probe
Calling lpc17xx_probe
Calling lpc11xx_probe
Please report unknown device with Designer 0x8000 Part ID 0x0
1 0xe0001000: Generic IP component - Cortex-M3 DWT (Data Watchpoint and Trace) (PIDR = 0x00000004002bb002 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 = 0x00000004002bb001 DEVTYPE = 0x00 ARCHID = 0x0000)
4 0xe0040000: Debug component - Cortex-M3 TPIU (Trace Port Interface Unit) (PIDR = 0x00000004002bb923 DEVTYPE = 0x11 ARCHID = 0x0000)
5 0xe0041000: Debug component - Cortex-M3 ETM (Embedded Trace) (PIDR = 0x00000004002bb924 DEVTYPE = 0x13 ARCHID = 0x0000)
ROM: Table END
***  1   Unknown ARM Cortex-M Designer 8000 Part ID 0 M3

I am not sure how to proceed but hopefully with some guidance I could fix the issue myself and send a PR (if you want)
Cheers

[aguaviva]

I added PROBE(stm32f1_probe); to that section, and now I can flash these offending clones:

Black Magic Debug App v1.10.0-635-gb386fae4-dirty
 for Black Magic Probe, ST-Link v2 and v3, CMSIS-DAP, J-Link and FTDI (MPSSE)
Using 1d50:6018 8FB7347E Black Magic Debug
 Black Magic Probe (ST-Link/v2) v1.10.0-635-gb386fae4-dirty
Running in Test Mode
Target voltage: 3.02V Volt
Speed set to 6.000MHz for SWD
Switching out of dormant state into SWD
DP DPIDR 0x2ba01477 (v1 rev0) designer 0x43b partno 0xba
AP   0: IDR=24770011 CFG=00000000 BASE=e00ff003 CSW=a3000040 (AHB3-AP var1 rev2)
Halt via DHCSR(00030003): success after 15ms
ROM: Table BASE=0xe00ff000 SYSMEM=0x00000001, Manufacturer 8000 Partno 000
0 0xe000e000: Generic IP component - Cortex-M3 SCS (System Control Space) (PIDR = 0x00000004002bb000 DEVTYPE = 0x00 ARCHID = 0x0000)
-> cortexm_probe
CPUID 0x412fc230 (M3 var 2 rev 0)
Calling stm32f1_probe
Detected clone STM32F1
1 0xe0001000: Generic IP component - Cortex-M3 DWT (Data Watchpoint and Trace) (PIDR = 0x00000004002bb002 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 = 0x00000004002bb001 DEVTYPE = 0x00 ARCHID = 0x0000)
4 0xe0040000: Debug component - Cortex-M3 TPIU (Trace Port Interface Unit) (PIDR = 0x00000004002bb923 DEVTYPE = 0x11 ARCHID = 0x0000)
5 0xe0041000: Debug component - Cortex-M3 ETM (Embedded Trace) (PIDR = 0x00000004002bb924 DEVTYPE = 0x13 ARCHID = 0x0000)
ROM: Table END
***  1   STM32F1 (clone) medium density M3
RAM   Start: 0x20000000 length = 0x5000
Flash Start: 0x08000000 length = 0x20000 blocksize 0x400

I also added a 0x000U device ID just in case:

diff --git a/src/target/stm32f1.c b/src/target/stm32f1.c
index 5d543744..41c50b32 100644
--- a/src/target/stm32f1.c
+++ b/src/target/stm32f1.c
@@ -501,6 +501,7 @@ bool stm32f1_probe(target_s *target)
        size_t block_size = 0x400;
 
        switch (device_id) {
+       case 0x000U: /* CS clone */
        case 0x29bU: /* CS clone */
        case 0x410U: /* Medium density */
        case 0x412U: /* Low density */

[dragonmux]

We're definitely Surprised that worked, but happy to see that.

One question we have though is if there any way for this device_id == 0x000U device to get an identification on it, eg, by reading a different register? What we'd like to avoid is for the stm32f1_probe() routine change to result in failed reads of the DBGMCU_IDCODE register being considered these F1 clones too.

[aguaviva]

I am not sure how to create a nice fingerprint for these devices, if you have any idea I will be happy to give it a go.

[dragonmux]

Well, without knowing more about them it's hard to say.. we would determine who made these clones, and where the datasheet/TRM is for them so we can figure out how exactly they differ from genuine parts. This'll lead to what register(s) can be used to identify them more positively.