NUCLEO-767ZI (STM32F767ZI) unsupported?

[tdjastrzebski]

Trying to debug NUCLEO-767ZI (STM32F767ZI) board I get the following error:

2020-07-27T12:08:44 DEBUG common.c: Loading device parameters....
2020-07-27T12:08:44 DEBUG common.c: *** stlink_core_id ***
2020-07-27T12:08:44 DEBUG common.c: core_id = 0x5ba02477
2020-07-27T12:08:44 DEBUG common.c: *** stlink_read_debug32 1a is 0xe0042000
2020-07-27T12:08:44 WARN common.c: unknown chip id! 0x1a
2020-07-27T12:08:44 DEBUG gdb-server.c: Chip ID is 0x0000001a, Core ID is 0x5ba02477.

Does the above mean this board is unsupported?
Environment: Windows 10, VSCode, Corex-Debug, STLink 1.6.1, the latest board firmware V2.J37.M26
Interesting, STLink 6.1.0 was able to write flash while STLink 1.6.1 fails to connect (WARN common.c: unknown chip id! 0x1a)
According to this list Core-ID: 0x5ba02477 is supported. Is incorrect Chip ID what causes the problem? It looks like Chip ID should start with 0x4xx.
Similar issues with this MCU were reported in the past #509, #433 but were fixed. Is it some Chip ID parsing problem?
OpenOCD 0.10 is also having a similar problem with this board.

[tdjastrzebski]

UPDATE: I am unable to flash any Nucleo board using version 1.6.1 while version 1.6.0 works just fine.
Is it possible I screwed up the build? But build is so simple that it is nearly impossible to break anything.
The only thing I did differently: I used cmake which comes with VS Studio but I do not see how this could cause a problem.
This is probably related to issue #1009 I just reported.

UPDATE 2 2020-08-01
I use Nucleo built-in probe with cortex-debug under VS Code.
I tried STLINK V3 MINI with 1.6.1 but was unable to flash neither STM32F746 nor STM32F767. Error: unsupported flash type.
I had some limited luck debugging STMF746 but not STM32F767 and only with version 1.6.0.
The same time, with exactly the same settings debugging STM32F769 with 1.6.0 works fine.
Version 1.6.1 stops not where breakpoints are set and generally is not helpful so it may have a regression issue.
I will do more tests, probably on Mac.

I am unable to add another response here since:
An owner of this repository has limited the ability to comment to users that are collaborators on this repository.
Maybe it is just as well that I cannot add more comments or register new bugs. I start to pull may hair out not being able to continue my project. Perhaps it is time to consider investing in a commercial solution.

[Nightwalker-87]

@tdjastrzebski: Please provide information on the used programmer.

[blazczak]

I can confirm the same flashing issues as above (unknown chip id, LIBUSB_ERROR_BUSY) when using stlink 1.6.1 with STM32F767ZI . Downgrading to 1.6.0 allowed me to program the board w/o issues.

@Nightwalker-87 using the embedded ST-LINK/V2-1.

[Nightwalker-87]

@Ant-ON Would it be possible to include this in your current branch Core ID reading rework ?
What does WARN common.c: unknown chip id! 0x1a stand for?

[Ant-ON]

@Nightwalker-87 I can add an extra warning for the error reading the core_id. It must be readable for all Cortex-M targets. In the event of a read error, I add a warning that the target is not available for comunication (check the connection of the SWD pins; try connecting the NRST pin and add --connect-under-reset).

[Nightwalker-87]

@Ant-ON: Yeah, that sounds good to me. Do you have a reference for the warning above?

[Ant-ON]

@Nightwalker-87 See https://github.com/Ant-ON/stlink/tree/chipid_read_rework

[Nightwalker-87]

@tdjastrzebski @blazczak Have you experienced any change when testing with the current develop branch?

[tdjastrzebski]

@Nightwalker-87 My focus is currently on relatively new STM32H7A3 so I stopped using stlink months ago but I will check.

[Ant-ON]

@tdjastrzebski You can check STM32H7A3 too. This target must also be supported.

[blazczak]

@Nightwalker-87 the version in develop seems to fix the unknown chip id LIBUSB_ERROR_BUSY errors.

st-flash --version
v1.6.1-277-g6f793d6

However, I don't quite remember having to reset manually at the end of each write. Is that a regression (no autoreset)? F7 board.

[blazczak]

@Nightwalker-87 Auto-reset occurred after using v1.6.0 to write the same binary.

[Nightwalker-87]

@blazczak The relevant changes should have been introduced with or before the merge of #1120.
For sure @Ant-ON will be able to tell more precisely, as he has been very busy contributing recently related to this topic.

[Ant-ON]

@blazczak To reset the target after flashing, you need to use --reset parametr. By default, after the firmware flashed, the code continues to be executed. Judging by the documentation (https://github.com/stlink-org/stlink/blob/develop/doc/tutorial.md), this has always been the case, perhaps there were some flaws leading to reset after flashing.
When using --connect-under-reset, a new firmware will start after flashing, although there was no reset do.

[Nightwalker-87]

Intermediate summary:

• "Does the above mean this board is unsupported?"
  "According to this list Core-ID: 0x5ba02477 is supported."
  --> The NUCLEO-767ZI board and the STM32F767 MCU are both supported by this toolset.

• "Is incorrect Chip ID what causes the problem? It looks like Chip ID should start with 0x4xx."
  "Is it some Chip ID parsing problem?"
  --> Has been addressed in Improvements for Chip_ID read #1120.

• "I am unable to flash any Nucleo board using version 1.6.1 while version 1.6.0 works just fine. (Unable to flash any Nucleo board #1009)
  Is it possible I screwed up the build? But build is so simple that it is nearly impossible to break anything.
  The only thing I did differently: I used cmake which comes with VS Studio but I do not see how this could cause a problem."
  --> Yes, it is possible to screw up the build if the previous one has not been cleaned properly with leftovers remaining in place. Detailled instructions on how to proceed can be found in /doc/tutorial.md

• "Version 1.6.1 stops not where breakpoints are set and generally is not helpful so it may have a regression issue."
  --> Has been addressed in [feature] Extended support for STM32H7 & rework of software reset #1071.

• "The version in develop seems to fix the unknown chip id LIBUSB_ERROR_BUSY errors."
  --> Has been addressed in Flash loader rework #1113 already.

• "Auto-reset occurred after using v1.6.0 to write the same binary."
  --> Major refactoring related to the reset functionality has taken place in Improvements and fixes of the flash loaders, unification of the reset function #1124.

[Nightwalker-87]

Please don't work with any older commits than 9c1315a from this point.

@blazczak: Are there any further leftovers?

We need some testing to find out if this regression from v1.6.1 has been finally fixed.

[Nightwalker-87]

@slyshykO Your successful testing with STM32F746 and a STM32H743 in #1009 does help here as well.
@Ant-ON From my point of view we may even close this one based on the already achieved results.

[Nightwalker-87]

OpenOCD 0.10 is also having a similar problem with this board.

Together with the result of #1009 this indicates a local hardware or OS-specific problem, which appears not to be related to this toolset or even OpenOCD 0.10.

All other issues mentioned in the summary above should be fixed by #1124 at the latest.