1 ACCEPTED SOLUTION
Accepted Solutions
@horizon105457 it's not a regression it's a choice as part of new experience we want to propose.
As always pro & cons. We are happy to get your comments here. We aim to be driven by end users feedbacks. Feel free to share !
You're right <=2.2.1 extension was promoting at STM32CubeMX project import couple of launch.json and tasks.json files. One way was convenient, the other was hard coding too much settings to project structure & co promoted by us. We have ambition to relax end user creativity and support more custom (and possibly more complex, wide, ...) way of working.
So starting 3.4.11 extension versions (currently all pre-release to collect feedbacks) the experience has been updated a bit:
+ Already no need any more to import a project what is not so VSCode way of working. You just have now to add a project your VSCode workspace and like CMake tools extension is doing we are discovering live if added material may be a STM32Cube candidate. As end user you have to confirm it or not.
Part of new experience .. we are forcing nobody: end user has to get the control.
+ Once your project is a STM32Cube one, launch.json (and device flashing coming with) is generated either live under the hood pushing "Run & Debug" button
or if more control required, you can ask for "create a launch.json file" or add an extra configuration if exists already.
Based on launch.json we are fully supporting rich editor experience ... please rely on code completion to access the power of rich debug session we are supporting.
Such said you are in control to create by yourself all tasks you want adapting to your way of working. Brand new STM32Cube bundles based architecture is promoting you all STM32Cube available as a CLI. For example from VSCode integrated terminal STM32CUbe programmer is ready for you. Have a try about:
cube programmer --helpyou can flash erase:
cube programmer -c port=SWD -e allor program:
cube programmer -c port=SWD -d <binary file> or ...
The very same you cam build:
cube cmake ....
@horizon105457 it's not a regression it's a choice as part of new experience we want to propose.
As always pro & cons. We are happy to get your comments here. We aim to be driven by end users feedbacks. Feel free to share !
You're right <=2.2.1 extension was promoting at STM32CubeMX project import couple of launch.json and tasks.json files. One way was convenient, the other was hard coding too much settings to project structure & co promoted by us. We have ambition to relax end user creativity and support more custom (and possibly more complex, wide, ...) way of working.
So starting 3.4.11 extension versions (currently all pre-release to collect feedbacks) the experience has been updated a bit:
+ Already no need any more to import a project what is not so VSCode way of working. You just have now to add a project your VSCode workspace and like CMake tools extension is doing we are discovering live if added material may be a STM32Cube candidate. As end user you have to confirm it or not.
Part of new experience .. we are forcing nobody: end user has to get the control.
+ Once your project is a STM32Cube one, launch.json (and device flashing coming with) is generated either live under the hood pushing "Run & Debug" button
or if more control required, you can ask for "create a launch.json file" or add an extra configuration if exists already.
Based on launch.json we are fully supporting rich editor experience ... please rely on code completion to access the power of rich debug session we are supporting.
Such said you are in control to create by yourself all tasks you want adapting to your way of working. Brand new STM32Cube bundles based architecture is promoting you all STM32Cube available as a CLI. For example from VSCode integrated terminal STM32CUbe programmer is ready for you. Have a try about:
cube programmer --helpyou can flash erase:
cube programmer -c port=SWD -e allor program:
cube programmer -c port=SWD -d <binary file> or ...
The very same you cam build:
cube cmake ....
Hi Zeno,
For your dual core H755, you need to create 2 debug configurations
In the launch.json file, I start with my CM7 first in this example:
"configurations": [
{
"type": "stlinkgdbtarget",
"request": "launch",
"name": "CM7",
"origin": "snippet",
"cwd": "${workspaceFolder}",
"preBuild": "${command:st-stm32-ide-debug-launch.build}",
"runEntry": "main",
"serverShared": true,
"serverHaltAllCores": true,
"imagesAndSymbols": [
{
"imageFileName": "${command:st-stm32-ide-debug-launch.get-projects-binary-from-context2}"
},
{
"imageFileName": "${command:st-stm32-ide-debug-launch.get-projects-binary-from-context1}"
}
]
},
{
"type": "stlinkgdbtarget",
"request": "launch",
"name": "CM4",
"origin": "snippet",
"cwd": "${workspaceFolder}",
"preBuild": "${command:st-stm32-ide-debug-launch.build}",
"runEntry": "main",
"serverShared": true,
"serverReset": "None",
"serverPort": "61239",
"imagesAndSymbols": [
{
"symbolFileName": "${command:st-stm32-ide-debug-launch.get-projects-binary-from-context1}"
}
]
}
]
Important points regarding the attributes:
For the CM7 debug configuration:
- imagesAndSymbols:
You must load both binaries, either by specifying the paths directly or by using VSCode commands. The VSCode command will let you choose thanks to a quick pick the binary for each context (if both are built).
Be careful, the order matters. Since this is my debug configuration for the CM7, it will be last in my list (i.e., the one for "context1" according to my VSCode command). - serverShared: necessary for multicore debugging.
- serverHaltAllCores: to stop all cores when debugging starts after flashing.
For the CM4 debug configuration:
- imagesAndSymbols:
Here, you should use the symbolFileName attribute to load only the symbols without flashing. We only need to specify the CM4. - serverShared: necessary for multicore debugging
- serverReset: set to "none" to avoid resetting. We do hot attach.
- serverPort: because otherwise it will use the same default port (61234) as the CM7 configuration.
Kind Regards,
Florent
