STM32F103C8Tx: Sudden unknown chip id

[tcurdt]

• Programmer/board type: Stlink/v2
• Programmer firmware version: e.g STSW-LINK007 2.27.15
• Operating system: macOS 10.12.3
• Stlink tools version: v1.3.1
• Stlink commandline tool name: st-flash and st-util
• Target chip: generic STM32F103C8

I was flashing without problems, suddenly I am getting "unknown chip id".

Output:

$ st-flash write main.bin 0x8000000
st-flash 1.3.1
2017-03-13T01:22:48 INFO src/common.c: Loading device parameters....
2017-03-13T01:22:48 WARN src/common.c: unknown chip id! 0xe0042000

Did I somehow fry my board? Or what does that mean?

[tcurdt]

This happens on an erase:

$ st-flash erase
st-flash 1.3.1
2017-03-13T01:49:32 INFO src/common.c: Loading device parameters....
2017-03-13T01:49:32 WARN src/common.c: unknown chip id! 0xe0042000

When I hold the reset button while calling the erase I get:

$ st-flash erase
st-flash 1.3.1
2017-03-13T01:49:40 INFO src/common.c: Loading device parameters....
2017-03-13T01:49:40 INFO src/common.c: Device connected is: F1 Medium-density device, id 0x20036410
2017-03-13T01:49:40 INFO src/common.c: SRAM size: 0x5000 bytes (20 KiB), Flash: 0 bytes (0 KiB) in pages of 1024 bytes
Mass erasing

0 bytes?

[tcurdt]

Setting boot0 to 1, then st-flash erase, then setting it back to 0 and all was working again.
I am fine to close the issue - but still would love to hear how/why that happened.

[iglooom]

@tcurdt are you using SWDIO/SDCLK as GPIO in your firmware? It may be like #577

[tcurdt]

@iglooom not by choice at least. I would need to check if any of the GPIO pins I am using are somehow connected to the SWDIO/SDCLK but according to this http://wiki.stm32duino.com/index.php?title=Blue_Pill they are not.

[Nightwalker-87]

Well, a test with v1.6.1 would be indeed be useful before adding this ticket to the v1.6.2 milestone.

[tcurdt]

Ah, missed that the other report was with 1.6.0.

[JihedChaibi]

Same problem here.. with STM32F401RE Nucleo board on Ubuntu 18.04,
It was working perfectly but suddenly I started to get this error :

$ st-flash write output/$(PROJ_NAME).bin 0x08000000
st-flash 1.6.1-69-gbe0157f
2020-07-16T02:48:35 WARN common.c: unknown chip id! 0x374b

[Nightwalker-87]

@JihedChaibi: Note the different error code 0x374b in your warning.
I would need to investigate what exact cause is linked to this ID.

[SJChannel]

I'm having a similar problem on Mac OS Catalina using st-flash 1.6.1 from Homebrew on a new fresh-out-of-the-box Nucleo-F746ZG. Here is the output from "st-flash reset":

st-flash 1.6.1
2020-09-24T13:59:47 WARN common.c: unknown chip id! 0x5fa0004
Failed to connect to target

An old st-flash 1.3.0 executable on the same Mac works OK:

2020-09-24T13:58:40 INFO /Users/jerry/Downloads/stlink-master/src/common.c: Loading device parameters....
2020-09-24T13:58:40 INFO /Users/jerry/Downloads/stlink-master/src/common.c: Device connected is: F7 device, id 0x10016449
2020-09-24T13:58:40 INFO /Users/jerry/Downloads/stlink-master/src/common.c: SRAM size: 0x50000 bytes (320 KiB), Flash: 0x100000 bytes (1024 KiB) in pages of 2048 bytes
st-flash 1.3.0

And st-flash 1.5.1 on a Raspberry Pi 4 running Raspian also works OK:

2020-09-24T13:53:02 INFO common.c: Loading device parameters....
2020-09-24T13:53:02 INFO common.c: Device connected is: F7 device, id 0x10016449
2020-09-24T13:53:02 INFO common.c: SRAM size: 0x50000 bytes (320 KiB), Flash: 0x100000 bytes (1024 KiB) in pages of 2048 bytes
st-flash 1.5.1

[Nightwalker-87]

Time for a short summary:

We were originally talking about the following error: WARN src/common.c: unknown chip id! 0xe0042000 which as we know by now definitely still appeared in v1.4.0 (see issue #669).

@dkorkmazturk @SJChannel WARN common.c: unknown chip id! 0x5fa0004 is a different error, namely: Failed to connect to target --> See issues #715, #791 and #1040 instead.
@JihedChaibi WARN common.c: unknown chip id! 0x374b is not related to this issue either --> this ID is not listed in chipid.h and thus unknown - it should be 0x433. Please check your hardware & board firmware and refer to:
https://community.st.com/s/question/0D50X00009XkXex/no-stlink-detected-when-connecting-with-stm32f401re-board

In order to get ahead with this, I'll try to reproduce this issue for v1.4.0 using my Bluepill board and hope some people are still following this ticket and are able to give some useful feedback.

[Nightwalker-87]

Setup:

• Programmer STLink/V2-clone / Firmware V2.J37.S7
• Board: STM32F103C8T6 ("Bluepill")
• OS: Debian (Bullseye [Testing])

Due to an existing compilation error I could not use v1.4.0, but v1.3.1 (with a patch regarding version numbering, to be able to compile) instead. I did a read-write cycle with and without board resets in-between and could not reproduce the described behaviour:

$ st-info --probe
Found 1 stlink programmers
 serial: 3f70050132124647524b4e00
openocd: "\x3f\x70\x05\x01\x32\x12\x46\x47\x52\x4b\x4e\x00"
  flash: 65536 (pagesize: 1024)
   sram: 20480
 chipid: 0x0410
  descr: F1 Medium-density device

$ st-flash write /[...]/Blinker.bin 0x8000000
st-flash 1.3.1-1-gbea4915-dirty
2021-03-12T14:33:15 INFO src/common.c: Loading device parameters....
2021-03-12T14:33:15 INFO src/common.c: Device connected is: F1 Medium-density device, id 0x20036410
2021-03-12T14:33:15 INFO src/common.c: SRAM size: 0x5000 bytes (20 KiB), Flash: 0x10000 bytes (64 KiB) in pages of 1024 bytes
2021-03-12T14:33:15 INFO src/common.c: Attempting to write 3520 (0xdc0) bytes to stm32 address: 134217728 (0x8000000)
Flash page at addr: 0x08000c00 erased
2021-03-12T14:33:15 INFO src/common.c: Finished erasing 4 pages of 1024 (0x400) bytes
2021-03-12T14:33:15 INFO src/common.c: Starting Flash write for VL/F0/F3 core id
2021-03-12T14:33:15 INFO src/flash_loader.c: Successfully loaded flash loader in sram
  3/3 pages written
2021-03-12T14:33:15 INFO src/common.c: Starting verification of write complete
2021-03-12T14:33:15 INFO src/common.c: Flash written and verified! jolly good!

$ st-flash erase
st-flash 1.3.1-1-gbea4915-dirty
2021-03-12T14:33:45 INFO src/common.c: Loading device parameters....
2021-03-12T14:33:45 INFO src/common.c: Device connected is: F1 Medium-density device, id 0x20036410
2021-03-12T14:33:45 INFO src/common.c: SRAM size: 0x5000 bytes (20 KiB), Flash: 0x10000 bytes (64 KiB) in pages of 1024 bytes
Mass erasing

[ Cycle repeated several times (with and without manual board resets in-between)... ]

$ st-flash write /[...]/Blinker.bin 0x8000000
st-flash 1.3.1-1-gbea4915-dirty
2021-03-12T14:33:56 INFO src/common.c: Loading device parameters....
2021-03-12T14:33:56 INFO src/common.c: Device connected is: F1 Medium-density device, id 0x20036410
2021-03-12T14:33:56 INFO src/common.c: SRAM size: 0x5000 bytes (20 KiB), Flash: 0x10000 bytes (64 KiB) in pages of 1024 bytes
2021-03-12T14:33:56 INFO src/common.c: Attempting to write 3520 (0xdc0) bytes to stm32 address: 134217728 (0x8000000)
Flash page at addr: 0x08000c00 erased
2021-03-12T14:33:56 INFO src/common.c: Finished erasing 4 pages of 1024 (0x400) bytes
2021-03-12T14:33:56 INFO src/common.c: Starting Flash write for VL/F0/F3 core id
2021-03-12T14:33:56 INFO src/flash_loader.c: Successfully loaded flash loader in sram
  3/3 pages written
2021-03-12T14:33:56 INFO src/common.c: Starting verification of write complete
2021-03-12T14:33:56 INFO src/common.c: Flash written and verified! jolly good!

$ st-flash erase
st-flash 1.3.1-1-gbea4915-dirty
2021-03-12T14:34:01 INFO src/common.c: Loading device parameters....
2021-03-12T14:34:01 INFO src/common.c: Device connected is: F1 Medium-density device, id 0x20036410
2021-03-12T14:34:01 INFO src/common.c: SRAM size: 0x5000 bytes (20 KiB), Flash: 0x10000 bytes (64 KiB) in pages of 1024 bytes
Mass erasing

$ st-flash write /[...]/Blinker.bin 0x8000000
st-flash 1.3.1-1-gbea4915-dirty
2021-03-12T14:34:12 INFO src/common.c: Loading device parameters....
2021-03-12T14:34:12 INFO src/common.c: Device connected is: F1 Medium-density device, id 0x20036410
2021-03-12T14:34:12 INFO src/common.c: SRAM size: 0x5000 bytes (20 KiB), Flash: 0x10000 bytes (64 KiB) in pages of 1024 bytes
2021-03-12T14:34:12 INFO src/common.c: Attempting to write 3520 (0xdc0) bytes to stm32 address: 134217728 (0x8000000)
Flash page at addr: 0x08000c00 erased
2021-03-12T14:34:12 INFO src/common.c: Finished erasing 4 pages of 1024 (0x400) bytes
2021-03-12T14:34:12 INFO src/common.c: Starting Flash write for VL/F0/F3 core id
2021-03-12T14:34:12 INFO src/flash_loader.c: Successfully loaded flash loader in sram
  3/3 pages written
2021-03-12T14:34:12 INFO src/common.c: Starting verification of write complete
2021-03-12T14:34:12 INFO src/common.c: Flash written and verified! jolly good!

Looking at this, the observed behaviour does not seem to be related to a bug present in the toolset in that version.
The warning could possibly also have derived from a firmware bug in the used programmer.

[Nightwalker-87]

ToDo: #669 (comment)

[Nightwalker-87]

Related to #443.

[Nightwalker-87]

A solution to this can be found here: #107 (comment). I'll add these steps to our tutorial.

@Ant-ON I'm still trying to figure out the actual technical meaning of 0xe0042000.

This is what I found out so far:

• chip id: 0xE0042000 or 0x40015800, primary information to derive flash and SRAM architecture
• Chip IDs are explained in the appropriate programming manual for the DBGMCU_IDCODE register (0xE0042000)

So I assume this is simply the returned memory address where the chip ID would have been found, if a read-out was possible.
Does this imply that this address is always returned, if this register could not be read and thus it was not possible to display a valid chip ID like 0x430 (STLINK_CHIPID_STM32_F1_XL) etc. ?

For illustration:

• OK: st-info --probe --> Send request to read 0xE0042000 --> Try to read memory address 0xE0042000 --> Successfully read value in 0xE0042000 --> Send chip ID value back to console --> Display value
• FAIL: st-info --probe --> Send request to read 0xE0042000 --> Try to read memory address 0xE0042000 --> Failed to connect and thus access 0xE0042000 --> Return original address back to console --> Display memory address

[Ant-ON]

@Nightwalker-87 chip id can be found in the reference manual as the DBGMCU_IDCODE. It's a unique id of one or group of chips. st-link determines the support of MCU by chip id. st-info don't display information about a chip if read incorrect value from the DBGMCU_IDCODE register. Also possible st-info reads a value from incorrect register:

stlink/src/common.c

Lines 1221 to 1249 in 40e9aa2

	int stlink_chip_id(stlink_t *sl, uint32_t *chip_id) {
	int ret;
	uint32_t cpu_id;
	*chip_id = 0;
	ret = -1;
	// Read the CPU ID to determine where to read the core id from
	if (stlink_read_debug32(sl, STLINK_REG_CM3_CPUID, &cpu_id))
	cpu_id = 0;
	// If the chip is an H7, read the chipid from the new address
	if (sl->core_id == STM32H7_CORE_ID && cpu_id == STLINK_REG_CMx_CPUID_CM7) {
	// STM32H7 chipid in 0x5c001000 (RM0433 pg3189)
	ret = stlink_read_debug32(sl, 0x5c001000, chip_id);
	}
	if (*chip_id == 0) {
	// default chipid address
	ret = stlink_read_debug32(sl, 0xE0042000, chip_id);
	}
	if (*chip_id == 0) {
	// Try Corex M0 DBGMCU_IDCODE register address
	ret = stlink_read_debug32(sl, 0x40015800, chip_id);
	}
	return(ret);
	}

We first try read id from 0xE0042000. We may got garbage if chip id contains in the 0x40015800 register. A more precise definition can be obtained using a code like #1101 (comment)