Ditch ms visual studio for gcc2/21/2024 Info : Listening on port 3333 for gdb connectionsĪnd I still got the same popup error. Info : starting gdb server for stm32f1x.cpu on 3333 Info : stm32f1x.cpu: hardware has 6 breakpoints, 4 watchpoints Info : Listening on port 4444 for telnet connections Info : Listening on port 6666 for tcl connections Info : DEPRECATED target event trace-config The results might differ compared to plain JTAG/SWD Info : The selected transport took over low-level target control. Info : auto-selecting first available session transport "hla_swd". I am using "Cortex-Debug" plugin for VS Code and OpenOCD.Ĭode: Select all Licensed under GNU GPL v2 For some reason path is being messed up by removing slash characters.Īm I missing some component? Do I need to do something before hitting F5? I am getting weird error (screenshot attached). I am not familiar with your configuration for Debug ("launch.json"). "configurationProvider": "ms-vscode.cmake-tools" "intelliSenseMode": "gcc-arm", //"linux-gcc-arm" is not acceptable value on Windows, hopefully this will work on Linux as well "compilerPath": "$/arm-none-eabi-gcc", //"/usr/lib64/ccache/arm-none-eabi-gcc" use env variable to specify compiler path, hopefully this will work on Linux as well "name": "Linux", //no big deal but shouldn't this reflect project name? Like "STM32-VCU" Param "intelliSenseMode": "linux-gcc-arm" did not work for me, will "gcc-arm" work on Linux? Please see my comments in modified file below. In "c_cpp_properties.json" currently hardcoded "compilerPath" will not work on all systems specially Windows, I propose to use Environment Variable for the Toolchain bin folder (in my case "C:/Program Files (x86)/gcc-arm-none-eabi-10-2020-q4-major/bin"). Unfortunately I do not have have Linux machine and I am not able to test my updates on Linux. I tried it on Windows and run into few small issues, let's try to address them so we can come up with cross-platform solution. Let us work out some kinks and once we have solid solution you will be able to incorporate it in your projects.ĭave, I an glad you were able to get it to work on Linux, I found your VS Code configuration in "ACDC_LIM" branch, I wish I knew about it earlier Johannes, there is not to many file at all. Then there is more freedom of choice in dev tools. I could add the necessary project file to github, provided it's not tons of files. If you or others are interested I can put together guide explaining how to set it up. It took some effort to figure out all the puzzles but in the end it is not very difficult. Debugger allows you to setup breakpoints anywhere in the code, step through and view all register values and periferals for any SMT32 chip thanks to SVD files. In order to allow debugging very small update is needed in the Makefile. Projects can be open without modifications and build using Make for Windows. I have successfully setup and tested environment with Visual Studio Code as editor with intellisensing capability and debugger using appropriate plugins additional components like OpenOCD. I have taken slightly different approach and decided to setup Windows based development environment which would allow to build projects like ZombieVerter and debug them as they are. Being able to debug code is one the key features for me. I am also running Windows and I like to get involved STM32 development. I am not expert in STM32 development but I spent some time reviewing templates used for OpenInverter development including ZombieVerter and I think it would be very difficult at best to port them into STM32CubeIDE. As much as I would love to see it for exiting projects I suspect it will probably not happen. This extension brings in configuration and usage of the MSYS2, Cygwin, MinGW and Clang toolchains to the Visual Studio Code and its OSS builds like VSCodium.EV_Builder I think this is great idea. MSYS2/Cygwin/MinGW/Clang support extension for Visual Studio Code
0 Comments
Leave a Reply.AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |