search

stlink-org / stlink

Open source STM32 MCU programming toolset
BSD 3-Clause "New" or "Revised" License
4.45k stars 1.24k forks source link

NUCLEO-767ZI (STM32F767ZI) unsupported? #1008

Closed tdjastrzebski closed 3 years ago

tdjastrzebski commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

@tdjastrzebski: Please provide information on the used programmer.

blazczak commented 4 years ago

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 commented 3 years ago

@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 commented 3 years ago

@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 commented 3 years ago

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

Ant-ON commented 3 years ago

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

Nightwalker-87 commented 3 years ago

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

tdjastrzebski commented 3 years ago

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

Ant-ON commented 3 years ago

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

blazczak commented 3 years ago

@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 commented 3 years ago

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

Nightwalker-87 commented 3 years ago

@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 commented 3 years ago

@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 commented 3 years ago

Intermediate summary:

Nightwalker-87 commented 3 years ago

Please don't work with any older commits than 9c1315a73296841ed3c25b4ea9500c187ab8236d 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 commented 3 years ago

@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 commented 3 years ago

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.