NUCLEO-F767ZI: unknown chip id! 0x5fa0004 + FIX

[gvdhoven]

Thank you for giving feedback to the stlink project.

• I made serious effort to avoid creating duplicate or nearly similar issue. I have read all other issues describing this error code but no fixes helped in my case.

In order to allow developers and other contributors to isolate and target your respective issue, please take some time to fill out each of the following items appropriate to your specific problem:

• Programmer/board type: NUCLEO-F767ZI
• Operating system and version:Mac OS X
• Stlink tools version: 1.6.1
• Stlink commandline tool name: st-flash
• Target chip (and board if applicable): NUCLEO-F767ZI

Futher we kindly ask you to describe the detected problem as detailed as possible and to add debug output if available, by using the following template:

Commandline-Output:

2020-09-25T11:16:11 WARN common.c: unknown chip id! 0x5fa0004
Failed to connect to target

Expected/description:

Connection successful, be able to flash using st-flash. The tool does send a reset command over USB but nothing more happens.

lsusb output:

Bus 020 Device 019: ID 0483:374b STMicroelectronics STM32 STLink Serial: 066FFF353138524E43101811

ST-util output:

2020-09-25T11:21:16 DEBUG common.c: *** looking up stlink version
2020-09-25T11:21:16 DEBUG common.c: st vid         = 0x0483 (expect 0x0483)
2020-09-25T11:21:16 DEBUG common.c: stlink pid     = 0x374b
2020-09-25T11:21:16 DEBUG common.c: stlink version = 0x2
2020-09-25T11:21:16 DEBUG common.c: jtag version   = 0x1d
2020-09-25T11:21:16 DEBUG common.c: swim version   = 0x12
2020-09-25T11:21:16 DEBUG common.c: *** looking up stlink version
2020-09-25T11:21:16 DEBUG common.c: st vid         = 0x0483 (expect 0x0483)
2020-09-25T11:21:16 DEBUG common.c: stlink pid     = 0x374b
2020-09-25T11:21:16 DEBUG common.c: stlink version = 0x2
2020-09-25T11:21:16 DEBUG common.c: jtag version   = 0x1d
2020-09-25T11:21:16 DEBUG common.c: swim version   = 0x12
2020-09-25T11:21:16 DEBUG common.c: stlink current mode: mass
2020-09-25T11:21:16 DEBUG usb.c: JTAG/SWD freq set to 0
2020-09-25T11:21:16 DEBUG common.c: *** set_swdclk ***
2020-09-25T11:21:16 DEBUG common.c: stlink current mode: mass
2020-09-25T11:21:16 DEBUG common.c: *** stlink_enter_swd_mode ***
2020-09-25T11:21:16 DEBUG common.c: *** stlink_jtag_reset ***
2020-09-25T11:21:16 DEBUG common.c: *** stlink_reset ***
2020-09-25T11:21:16 DEBUG common.c: *** stlink_write_debug32 5fa0004 to 0xe000ed0c
2020-09-25T11:21:16 DEBUG common.c: Loading device parameters....
2020-09-25T11:21:16 DEBUG common.c: *** stlink_core_id ***
2020-09-25T11:21:16 DEBUG common.c: core_id = 0x5ba02477
2020-09-25T11:21:16 DEBUG common.c: *** stlink_read_debug32 5fa0004 is 0xe0042000
2020-09-25T11:21:16 WARN common.c: unknown chip id! 0x5fa0004
2020-09-25T11:21:16 DEBUG common.c: *** stlink_reset ***
2020-09-25T11:21:16 DEBUG common.c: *** stlink_write_debug32 5fa0004 to 0xe000ed0c
2020-09-25T11:21:16 DEBUG gdb-server.c: Chip ID is 0x00000004, Core ID is 0x5ba02477.
2020-09-25T11:21:16 DEBUG common.c: *** stlink_read_debug32 5fa0004 is 0xe000ed78
2020-09-25T11:21:16 DEBUG common.c: *** stlink_read_debug32 5fa0004 is 0xe000ed14
2020-09-25T11:21:16 DEBUG common.c: *** stlink_read_debug32 5fa0004 is 0xe000ed7c
2020-09-25T11:21:16 INFO gdb-server.c: Chip clidr: 05fa0004, I-Cache: on, D-Cache: off
2020-09-25T11:21:16 INFO gdb-server.c:  cache: LoUU: 0, LoC: 5, LoUIS: 7
2020-09-25T11:21:16 INFO gdb-server.c:  cache: ctr: 05fa0004, DminLine: 4096 bytes, IminLine: 64 bytes
2020-09-25T11:21:16 DEBUG common.c: *** stlink_write_debug32 0 to 0xe000ed84
2020-09-25T11:21:16 INFO gdb-server.c: D-Cache L0: 2020-09-25T11:21:16 DEBUG common.c: *** stlink_read_debug32 0 is 0xe000ed80
2020-09-25T11:21:16 INFO gdb-server.c: 00000000 LineSize: 4, ways: 1, sets: 1 (width: 4)
2020-09-25T11:21:16 DEBUG common.c: *** stlink_write_debug32 a to 0xe000ed84
2020-09-25T11:21:16 INFO gdb-server.c: D-Cache L5: 2020-09-25T11:21:16 DEBUG common.c: *** stlink_read_debug32 f00fe019 is 0xe000ed80
2020-09-25T11:21:16 INFO gdb-server.c: f00fe019 LineSize: 8, ways: 4, sets: 128 (width: 12)
2020-09-25T11:21:16 INFO gdb-server.c: Listening at *:4242...

Updating the board to the latest firmware (https://www.st.com/content/st_com/en/products/development-tools/software-development-tools/stm32-software-development-tools/stm32-programmers/stsw-link007.html#tools-software) solved the problem.

[gvdhoven]

please stop assigning me :)

[stappersg]

@gvdhoven do know that the first assigning was done after the issue was closed.

In #1007 and #1049 was a simular assign after close done.

@Nightwalker-87 I think it is good thing to add a note to #1000 that assignment after close is done for statistic reasons to easy count whom has closing an issue.

If there are other reasons for assignment please also add it to #1000

@all_of_us
Libre software is about which common interests we have.

That implies among other things accepting assignment of close issues.
As in Be happy that it is done and also Do not whine about assignment on done tasks.

[Nightwalker-87]

@gvdhoven: This does not prevent you from unsubscribing from eventual further notifications.
As @stappersg mentioned correctly, this is solely to keep track on contributors to this FOSS software with respect to licensing terms.

[gvdhoven]

ah ok, good 👍 happy to help in that case :)