Support for dual core H7?

[bkinman]

Hi, I see that extension version 2.1.0 claims support for dual-core H7 devices, but I'm not seeing stm32h745 listed -- is this particular device not supported for some reason, or am I missing something?

[HughDavenport111]

The STM32H745 does belong to the H7 series, but certain extensions may not cover all H7 series devices, which is quite common among different models. 

[Sarra.S]

Hello @bkinman, Welcome to ST Community, 

Thank you for reporting this, this is under investigation (Internal ticket: 195842) 

But I would like to clarify for @HughDavenport111 that the STM32H745 does belong to the H7 series, it's a dual-core microcontroller with both CM4 and CM7 cores. 

[mattias norlander · Accepted solution]

Hi @bkinman,

Are you trying to use the "Create empty project" or are you trying to import a "STM32CubeMX project"?

• The "Create empty project" is not yet implemented for dual-core and TrustZone devices.
• STM32CubeMX can create projects for dual-core/TrustZone devices as well providing you a CMake structure and launch.json + tasks.json to help you create valid debug configurations.

"Empty project" for more complex devices will be supported a bit later on the roadmap as part of a planned major overhaul. 

For now I would recommend that you let CubeMX generated the H7 dual-core project. Then get rid of whatever code you don't want, get rid of mx-generated.cmake, get rid of the ioc-file, and clean the 

include("mx-generated.cmake")

From the CMakeLists.txt

That would give you an "empty CMake project template" to use as well as launch.json.

It is admittedly only a work-around, but I think you can make that work (have not tried myself).

[bkinman]

I had tried to "create an empty project", yes. I was also trying to import an example chosen from the "example selector".

While neither of those seemed to work. I've found that "Start My project from ST Board" in STM32CubeMX seemed to produce a project which could be imported via the STM32 VSCode extension.

The project did not compile immediately, due to some errors associated differences in between filename casing used by CMake and that of the actual filenames in the filesystem (I imagine that this is a Linux-only issue, as windows filesystems are not case-sensitive)

Thanks for the pointer!

[mattias norlander]

Would you mind sharing which probe gave you issues on Linux? Would be interesting to reproduce and check if it is more widely spread than just one single example…