Visual Studio Code for C/C++ with ARM Cortex-M: Part 1 – Installation

Posted on by

For a few months I’m learning and using Rust. I’m still learning, but I’m very impressed by the powerful and cool programming language, the vibrant ecosystem, the advanced concepts behind it and by the tools. With learning Rust I have been using the Visual Studio Code IDE and it works great for Rust. But I was wondering: could I use it for my ‘usual’ C/C++ development on ARM Cortex-M devices too? The answer is a clear ‘yes’, and this mini series of articles should get you up and running too.

Outline

Don’t get me wrong: Eclipse is a very mature and great IDE. But with its age and maturity it is not the most advanced IDE any more compared to technologies Microsoft provides with the Visual Studio (Enterprise or Community) edition which I’m mostly using for C# development. Don’t get confused with the Microsoft Visual Studio Code which is provided by Microsoft as freeware and Microsoft has published the source code under a MIT License, while it still contains some binaries built with a proprietary license.

In essence, Visual Studio Code is a very slick, fast and modern IDE with many cool plugins and helpers. It seems not so much used for embedded development, but this certainly might change over time. Getting started with Visual Studio Code and an embedded target can be difficult because there might be no dedicated support from the silicon vendors for it. But with a bit of learning and I hope with the help of this article series you should get up and running.

In this tutorial series I’m using the NXP K22FN512 (FRDM-K22 board), but you should be able to use any other NXP Kinetis or LPC device if supported by the NXP MCUXpresso SDK. I’m going to cover installation, first simple project, debugging it on the target, and finally extending it to a full SDK project and explore some of the advanced features.

So with this: If you don’t know Visual Studio Code, I invite you to a journey into a new world…

Setup

For this article I used the version 1.55.2 of Visual Studio Code. The installer is available from https://code.visualstudio.com/ and supports Windows, Mac and Linux:

Visual Studio Code Download
Visual Studio Code Download

After the installation, start the IDE:

Visual Studio Code

At anytime I can update the IDE if there are updates available (I will get notifications too):

Check for Updates

The IDE incorporates a terminal or console view, open a new one:

The Terminal and Console area is by default in the lower area but can be moved anywhere:

Installing Extensions

In comparison to other fully integrated IDEs, I have to install other packages in addition to the IDE: IDE extensions, the build tools (compiler, linker, libraries), Cmake and support for the debugger.

To install the IDE plugins, this can be done with the host shell command prompt or directly in the Terminal inside the IDE. To install extensions (aka Plugins in Eclipse) I use the following command format:

code --install-extension <code>

Or I can use in the IDE the menu View > Extensions.

Menu View > Extensions

To do embedded development for ARM Cortex-M, I recommend the following extensions:

  1. C/C++, ms-vscode.cpptools
  2. Cortex-Debug, marus25.cortex-debug
  3. CMake Tools, ms-vscode.cmake-tools
  4. CMake Syntax highlighting, twxs.cmake
  5. ARM Assembly highlighting, dan-c-underwood.arm
  6. Linker Script highlighting, zixuanwang.linkerscript

The first three are required, the other are optional but recommended.

The easiest way is to install them from the command prompt inside the IDE:

code --install-extension ms-vscode.cpptools
code --install-extension marus25.cortex-debug
code --install-extension twxs.cmake
code --install-extension dan-c-underwood.arm
code --install-extension zixuanwang.linkerscript
Installing Extension from the Terminal inside VSC
Installing Extension from the Terminal inside VSC

Below my installed extensions (menu File > Preferences > Extensions):

Installed C Cpp Extensions
Installed C Cpp Extensions

CMake

CMake can be downloaded and installed from https://cmake.org/download/

Install it with the defaults. I’m using v3.20.2.

CMake Installer
CMake Installer

 Make or Ninja

I’m using both Make and Ninja with CMake. Both shall be present in the PATH so check if you have one already installed:

The installer for Make is available from https://www.gnu.org/software/make/

Ninja is available from https://github.com/ninja-build/ninja/releases. Install it where it is found by the system, I usually place it inside C:\Program Files\CMake\bin

For legacy reasons I still use Make because this is what I grew up. But Ninja is the one I’m using more and more because it is so fast :-).

GNU Arm Embedded Toolchain

The GNU toolchain for ARM is available on https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm/downloads

I have installed the Version gcc-arm-none-eabi-10-2020-q4-major-win32 with the default settings.

GNU Arm Embedded Toolchain

Debugger

To connect the GDB (debugger) to a target board, I need a debug probe. I’m using the SEGGER J-Link for this. The MCUXpresso IDE already comes with a J-Link installation, so very likely this already exists on your machine. If not you can download the J-Link Software from https://www.segger.com/downloads/jlink#J-LinkSoftwareAndDocumentationPack

Install it with the defaults. I have V7.20 installed with the default settings:

Installing J-Link Software

It is be possible to use OpenOCD or PEMicro too. I focus first on the J-Link interface.

With this we should have now all the needed software installed.

In the next article I describe how to create the first project.

Happy Coding 🙂

Links

68 thoughts on “Visual Studio Code for C/C++ with ARM Cortex-M: Part 1 – Installation”

  1. We use VS Code for Arduino dev, it’s brilliant if you use the PlatformIO extension, a huge range of devices supported and multiple libraries, (mbed, Arduino etc) and supports RTOS’s’ve not used that element. Supports most debuggers as well, well worth a look.

    Like

    Reply ↓

    • Hi David,
      PlatformIO is probably a big discussion on its own :-).
      I looked at it, and while it looks appealing the Arduino thing plus their business model let me shy away. But agreed: if you are used to the ‘classic’ Arduino world then PlatformIO is definitely brilliant. And I feel that’s the main target of PlatformIO anyway.
      I like their claim to be ‘vendor independent’ (but they get funded by vendors?). Otherwise it looks like what ARM did with mbed: trying to create their own (kind of closed) ecosystem, add ‘IoT’ to the mix and finally fail (imho).
      There is always a dependency on vendors, and I like to be dependent only on things they are good at or where they excel. To me Microsoft is leading the technology in the area of IDEs, the GNU tools are the de-facto standard (with LLVM the technology leader) and the silicon vendors like STM, NXP or Espressif are the best source for providing the drivers and SDKs. Sure there are other pieces (git, CI/CD, debug probes, …) but I don’t need yet another thing in-between. Just my one cent.

      Erich

      Like

      Reply ↓

      • As far as I can see where possible Platformio uses manufacturer or open source tools, it allows mbed and other libraries as well as RTOS’s to be used, its only real purpose is making VS code work well with whatever tool chain and silicon you want.

        I have avoided any of the eclipse based tools because they are so badly ported to each manufacturer as well as frankly being stuck 20 years ago.

        It’s brilliant we now have tools that simple and in an open way allow us to bring in many other plugins and extensions without consent from a manufacturer or indeed a ransom!

        Liked by 1 person

        Reply ↓

        • Hi David,
          I tried PlatformIO, but apart of an installation issue (to be investigated) it did offer mbed or Zephyr projects, so this is not what the goal of this series is: it is about getting up a very simple project for ARM Cortex M and debug it, with the minimal set of extra extensions or configuration items. More helpers can be added later on after the basics are in place.

          Liked by 2 people

        • @Erich
          Actually, platformIO just provide flexible framework to build a software constructor it base on Scons.
          You can always build any firmware for any silicon from scratch just like CMake. Just need to read their docs to get on how it organize the build environment. I am managed to setup a build procedure (they called it platform) for a not yet supported sillicon with both external SDK and compiler and debugger also working well. We can even add more extra tasks with condition depend on building environment context, that lift up a lot of workload for the developer. But I have to admit sometime we still need to use that silicon official IDE (eclipse based) due to heavy debugging relate to hardfault condition, test out some MCU modules functionalities and RTOS maybe Ozone is another better choice but it depend on J-link. while for coding, source control VSCode+PlatformIO is really a breeze.

          I will say using Scons instead of CMake have both advantages and draw back(speed). I know Scons have an experimental feature to use ninja, but it is not enable in PlatformIO yet, I think. Hopping they will consider to switch to ninja soon.

          By the way, PlatformIO is really an interesting project that worth us to invest some time.

          Cheers

          Like

        • I’m still skeptical about PlatformIO, especially about their model. It is true that use it like you describe it, and that can make sense in several cases. But ultimately it is probably best to stick with the original Visual Studio Code as recently many vendors including Nordic, NXP and STM are providing extensions for VSC.
          And good point about the debugging challenge: providing a framework like PlatformIO or VSC is easy compared to the challenges to provide a good debugging experience, and this is where engineers have to spend a lot of time.

          Like

  2. Eric
    Have you used Visual Studio (community) for embedded development? Together with https://visualgdb.com/ so you can build and debug for many processors, including ESP32s?
    I have used VS for embedded development for the last 19 years and always wondered why it was not used more since in comparison I always found the IDEs (Keil, IAR and Eclipse based ones) less efficient.
    I tried VS code because some people rave about it but didn’t see the advantage over VS community (or is it that debugging can be done without needing visualGDB and so one can save $99?).
    Cheers
    Mark

    Liked by 1 person

    Reply ↓

    • Hi Mark,
      yes, I do use Visual Studio (both community and professional), and do use VisualGDB for different targets, including NXP and Raspberry Pi.
      The MS Visual Studio is a great IDE, but mostly desktop and non-Embedded related (I’m using it a lot with .Net Core which is fantastic if you have the needed computing power on the target).
      And yes, that $99 price point is probably the reason why 99% of the developers will shy away. I’m willing to pay for tools (and I do, for example I do have that $99 license), but very few people see it that way. Especially if you can get similar features otherwise: they are not ‘free’, you just have to ‘pay’ with learning time. To me it is a question like “do I want to spend $99 for a good start and still need to learn that thing” or “just invest the money/time in learning”? I feel the later thing costs more upfront, but pays off quickly.

      Like

      Reply ↓

    • I tried visualGDB a couple of years ago. At first I thought it was the answer to my prayers. I paid for it. $100??? Who cares! I would happily pay $1000 if it worked. But unfortunately the debugging experience was poor. I have a Segger J-Trace and running imxrt10xx based products, these are fast MCUs. I could barely use any of the Segger debuggers features. It was flaky… I had a really bad experience. I gave up and switched to Segger Embedded Studio… Long story…

      Having said all of that I agree that Visual Studio (or Visual Code) is the way to go, but we really need either silicon vendors or debugger vendors or even tool chain vendors to support it. One simply can’t develop and support commercial products and their firmware without stable tool chains, especially with regard to debugging.

      Liked by 1 person

      Reply ↓

      • Hi John,
        (interesting discussions 🙂 )
        I do use Visual Studio (community and professional) for .Net core (C#) development on Embedded Linux. Strictly speaking this is not ‘true’ embedded and more like ‘desktop’ style with running over a network connection, target debug deamon.
        I do use VisualGDB (have paid even the +$100 license) and feel like you: it kinda works. ‘Real embedded’ tools like SES or MCUXP are there for a reason: being able to debug the device. The other vendor provided aspect is that they provide specialized tools (pin configuration, clock configuration, …) plus examples and starting projects. The later (getting started quickly) is something what others like PlatformIO can provide too. The special tools like the config tools they do not provide because it is far too much effort for them. But where the vendors like Segger or NXP excel is the ability to debug the target and get real insights (trace, SWO, fast flash programming, flash breakpoints, disassembly, fault analysis, data views, FreeRTOS awareness, …). This is far beyond and more complex than just being able to step through the code and see the (high level) variables or doing some printf’s. There *is* a difference between ‘application level programming’ and things like JTAG/SWD debugging and implementing and a bootloader or an embedded application with realtime aspects.

        If silicon vendors will change their investments? We have to see. The industry seems to be still silicon focused (heck, that’s their core business) but they need to be more modern software oriented in the future to sell their silicon. Intel for example invested a lot into making compilers for Intel cores better, where ARM did a similar thing for all the ARM cores, and they still try to compete their licensees with their own tools. With Microsoft going more into embedded (.net core, through acquisitions (Express Logic)) and new players (like RISC-V) coming into the play, it is an interesting time.

        Erich

        Liked by 1 person

        Reply ↓

        • Very good post.

          The only comment I would make is be careful of what you wish for. Of the four companies I worked for, only one really had an understanding of the balance between investing in different technology areas. The other three bounced back and forth trying to maximize the effectiveness of software development, hardware design, product integration only to end up just having marketing slides saying they’re the best at what they do…

          Liked by 1 person

        • Yes, finding the right balance is not easy, I have seen this too many times too.
          >>only to end up just having marketing slides saying they’re the best at what they do…
          Including web pages. I have seen several companies spending lots of money for their shiny web pages to attract investors than actually working on their technology and products.

          Liked by 1 person

      • Atmel did base their standard IDE on VS – don’t know the strategy though after the Microchip takeover.
        Debugging i.MX RT with IAR or MCUXpresso is also flaky – they are tricky things.
        At the end of the day it is indeed probably the “debugging experience” that makes or breaks it

        Liked by 2 people

        Reply ↓

        • >>At the end of the day it is indeed probably the “debugging experience” that makes or breaks it
          I 100% agree with that. For everything else usually there are other ways or alternatives. But if debugging is a poor experience, that’s the deal breaker.

          Like

    • Hi Eli,
      I’m using ninja for all my ESP32 development, but mostly because it is well managed and hidden inside the Espressif SDK.
      I have projects with up to 600 files or more and normal ‘make’ files are still working fine for me. Maybe because I spend more time with coding than building. For build servers this is a different thing. Anyway I wanted to learn more about using ninja, it is just a matter of priorities.
      Thanks for the extra pointers and suggestions!

      Like

      Reply ↓

    • Well, this frustrating – I tried to put in the first question and it won’t show up.

      Let’s try the second out of curiosity:

      2. Why are you using ms-vscode.cpptools/ms-vscode.cmake-tools for build with marus25.cortex-debug instead of CPP with GDB, respectively? I *think* I know the answer to this one but I’m interested in your reply.

      Like

      Reply ↓

      • Hi myke,
        not sure what you expect as an answer ;-). The reason is that when I was searching for a solution to do debugging for my boards using Visual Studio Code I came across the plugin from marus25. Not only it has been downloaded >150k times, but it seems to offer features like SWO (did not try that one yet) including RTOS support with the debug probes I’m using. If there is something better, I’m open to hear this of course.

        Liked by 1 person

        Reply ↓

        • Hi Erich,

          I’m wondering if you (or somebody else here) has seen this problem before – I find that when I reply, once every four times or so it gets accepted but never displays.

          I save what I post before I click on “Post Comment” but it’s annoying.

          Liked by 1 person

        • Hi myke,
          yes, I have seen that recently too with some of my comments on another blog. I believe WordPress has implemented some extra things to prevent spam or malicious comments. They seem to have changed the system about two weeks ago I think. And yes, it is *very* annoying for me too. WordPress is using Askimet (https://wordpress.org/plugins/akismet/) which seems to be pretty good, except that recently it the amount of spam increased a lot (it reports around 1k of spam comments every week, no way for me to go through each of them 😦 )

          Liked by 1 person

        • Cortex debug is a great plugin, I have tried the SWO for upto 6 channels and it works. I have not used the graphing/ploting features. It’s one of the best plugins for debug. I also use LSP and compile_commands.json as MS CPP plugin does not do a good job for large projects when it comes to auto complete.

          Liked by 1 person

    • Now the third:

      3. What do you do about wizards? For MCUXpresso, there are the Pin and Clock Wizards – the Pin Wizard I could live without (although it would add to my workload). But not having the Clock Wizard is a dealbreaker as I depend on it to ensure that I’ve set up my clocks correctly (especially with applications that use advanced communications interfaces or really anything more complex than flashing an LED).

      Liked by 2 people

      Reply ↓

      • I don’t see MCUXpresso IDE going away or the configuration tools (standalone or integrated). I doubt that there will be an integration of such tools into VSC until it would truly dominate the embedded market. So I feel that tools like MCUXpresso IDE or STM32CubeIDE will co-exist with VSC, used as ‘external’ tools for this specialized tasks. I mean it would be nice to have everything integrated, but the reality will be that there will be dedicated tools for dedicated tasks.

        Liked by 1 person

        Reply ↓

    • 4. Are there any RTOS TAD (Task Aware Debugging) tools available for VS? I’ve done a search and can’t find any other than a FreeRTOS simulator plugin for VS. I’m actually surprised at that as I thought there were some plugins for multi-taskers and/or multi-threaded application development.

      Liked by 1 person

      Reply ↓

    • There’s something about the first question.

      Rewritten it is: What are the features about VS that you consider more advanced than Eclipse? I haven’t seen anything in VS that makes me hunger to use it.

      Sorry about the multiple replies – I don’t know what’s wrong with my original post.

      Liked by 1 person

      Reply ↓

      • Hi myke,
        it is not really a particular feature or a set of features. Eclipse or probably any other IDE gives you what you expect from it: that you can edit, build, debug and manage your projects. They all do pretty well. So this is not about which one is better or not.

        But there are a few things which stand out with VSC: one is its modern look and feel. Compared to other IDEs it as a really fast UI. Outstanding is the Microsoft Intellisense (this is probably the reason why Microsoft as not open sourced it?). I really like their small helpers and small assistants which offer their help (which I can take or not). I appreciate that I can use different tool chains (I have about a dozen different compilers), different languages (C, C++, Rust, Go, C#) and environments (git, gitlab, github, Atlassian, make, cmake, ninja), all in the same environment, but I don’t feel locked in.

        What I like too is that unlike other IDEs (including Eclipse) do not try to ‘integrate everything’: instead it is open with JSON files to configure things the way I want: adding toolchains, adding tasks, setting up my build and then rely on the tools I want to use (compiler, libraries, debug hardware, VCS) instead forcing me to use that the IDE has decided to provide. The other thought I have is that Microsoft might not ‘know embedded’ (they try, but fail), but they truly ‘know programmers’. As such VSC feels like ‘from programmers for programmers’, so I immediately feel home. Whereas the Arduino IDE feels like ‘from non-programmers for non-technical people’, and Eclipse feels like ‘from all developer of the world for every developer’ making it a “Eierlegende Wollmilchsau” :-).

        At the end VCS (or any other IDE) is primarily an editor, so a commodity. Which ‘editor’ to use (vi, vim, emacs, notepad, Arduno IDE, MS VS, MSC, IAR, Keil, …) is a matter of personal taste too. What I want is something which takes me seriously as a programmer, engineer and developer. Not something which just wants my money, wants to drag me into ‘yet another mbed’, environments or cloud based stuff or other lock-ins. What I care the most is my firmware code, and I want something to work with my code, not something which wants me to use ‘their’ code.
        To the point: If Microsoft and Visual Studio Code goes away the next minute: I will not have a problem with this because everything else (compiler, linker, debugger, etc) is not depending on it.

        I hope this helps, even if it probably does not answer your question directly?

        Liked by 2 people

        Reply ↓

        • HI Erich,

          Thank you for taking the time to reply. It took me a bit of time to figure out what is meant by “Eierlegende Wollmilchsau” – the literal translation of “egg-laying wool-milk-sow” just doesn’t make any sense in English (the more apt English idiom is “Jack of all trades”).

          I have been very aware of Visual Studio as an IDE for different MCU devices (I used VS6 about 12 years ago with the PICmicro) as well as different programming languages. I’m not convinced a user defined custom setup will be significantly better than a vendor supported application development tool (ie MCUXpresso) when there are custom Wizards created for the devices (the clock and pin wizards noted elsewhere). I’m also wary of Intellisense; I wouldn’t call it “outstanding” and when I have used it, I’ve noted that it misses about one in ten times for me which means the chance of an error goes way up if the programmer isn’t paying very close attention.

          Regardless, I think you’re doing a great service by showing how VCS can be used to provide a custom IDE for different development situations.

          I do have one question on a point that you and another respondent made and that was the “really fast UI”. What do you mean by that? When I’ve used VCS it has never struck me as operating significantly differently from other IDEs I’ve used over the years – the most significant delays in any IDE come in project build and programming. Just curious.

          Thanx,

          myke

          Liked by 1 person

        • Hi myke,
          what I meant with the speed are things like how long it takes to start the IDE (say 15 sec vs. 2 sec) or things like the UI/Window refresh/update time. Eclipse using Java has a disadvantage here compared to code running natively on the host. I did not make any measurement, but I would guess the UI responsiveness of VSC is at least twice as the one in Eclipse. So this is what I came from. I agree that this does not affect compile time, and one could use cmake/ninja on Eclipse too. And the project build is happening outside of the IDE.

          There are for sure several aspects to this, and I’m not going into a ‘holy war’ about IDEs (there is no reason for this, because everything has its purpose and many things might depend on personal taste). One thing I noticed is that VSC (ok, probably not using all extensions possible) uses much less RAM (500 MB vs 1600 MB) or that it is using the GPU on my Windows machine where Eclipse does not (that alone can make a speed difference). Or that VSC takes advantage of Multi-threading. Not that this per se would make a huge difference, but I thought is interesting.

          Erich

          Liked by 1 person

  6. The best statement that describes the case for VS or VSC is Erich’s wonderful analogy of each:

    “The other thought I have is that Microsoft… truly ‘know programmers’. As such VSC feels like ‘from programmers for programmers’, so I immediately feel home. Whereas the Arduino IDE feels like ‘from non-programmers for non-technical people’, and Eclipse feels like ‘from all developer of the world for every developer’ making it a “Eierlegende Wollmilchsau” ”

    That statement is spot on.

    I used to use VI, before that I used ED… Does anyone remember ed? On CPM… Ooh that’s old! And after that I used an editor called ‘brief’ during the 90s together with my IAR 6800/68332 compilerd, green screen heaven! My point is I always used the best that was available. But now things are not so clear. IAR and Keil IDEs are antiquated in terms of editing, only debugging remains good though products like SES and MCUXpresso are changing that.

    Anyways, in terms of IDE, Microsoft do it right. No ifs or buts. One needs to experience them all to truly understand. And yes! Intellisende is outstanding! They are written by programmers for programmers. Integration is paramount. These new MCUs are far too complex for companies to waste valuable embedded firmware resources on fiddling with their toolsets. I’m not talking Hobbyist.

    And then there are all the other integrations such as git, ci, unit testing etc… that desktop programmers take for granted.

    So my wish list is always to get my embedded IDE editing and debugging experience as close to VS as I can. Hopefully this article will show the way with VSC and extensions.

    Liked by 1 person

    Reply ↓

  7. The thing that is the most “shocking” of all about this article is that multiple people are actually talking about a Microsoft product – typically articles will be about how much better anything to do with Linux or open source is than the useless trash that comes from Bill gate’s imperium. And how those who actually use them are committing a deadly sin.
    How things may have changed???

    Liked by 2 people

    Reply ↓

    • Hi Mark,
      imho talking about a ‘Microsoft product’ and development tools is not a bad thing. And I don’t think that things have changed. And Visual Studio Code is as open source as Eclipse is from STM, NXP, TI and all the other providers? As for myself I believe that choices are always good, especially if everyone can make an informed decision: what one wants to use, provided by whom, at which costs or investment.

      Like

      Reply ↓

    • Hi Mark,

      Love your statement “deadly sin”!!

      I don’t know when the divide between Linux and windows, open source and closed source began, but it is not good.

      Real engineering requires real engineers look at the problem objectively and with merit in mind. Following narratives serves no purpose.

      People who spend their time online trashing Linux or windows make no sense and my guess is they’re not very good engineers!

      Fortunately they don’t follow this blog! 😁

      Liked by 1 person

      Reply ↓

      • Since I am generally lazy I started with Windows and the programs that came with it like Office and then VS. I never managed to get into Linux – although I had a short fling, but was put off when I tried to obtain a tip about how to get a game working for my little daughter that didn’t want to run properly. The community at that time basically told me that I should go away and learn Python and a number of other such programming and Linux related skills before asking further questions so I didn’t bother anymore.

        But I have used VS for 20 years and have done all embedded work with it too during the last 19 and never understood the resistance, whereby mostly it was because it cost money. Although in the meantime the community edition even removes that but some reluctance still remains.

        After working 25 years as a consultant it is interesting that the most successful companies I have been involved with will not even think about which tools to use. They just use whatever is recommended and will happily purchase half a dozen IAR licenses for the people working on the project and get the job done.

        But the open-source hacking mentality which is great for pass-times is found in many engineering offices where it can be almost impossible to convince some programmers to invest a few hundred Dollars in a proven supported solution since the general idea is that anyone selling such must be evil since everything is available for download somewhere anyway. The thing is that after a few months of working overtime they also prove that they were right in getting what they found to work – plus the”experience was valuable learning”. And they saved the company a couple of hundred Dollars in the process (without considering the own salary and potential project delays).

        Here I am diverging for the IDE into firmware libraries but there is some crossover and engineering has certainly changed during this time. My point was that it is nice to find someone actually suggesting that VS (or VSC) could actually be of use “on an Eclipse blog”!

        Liked by 2 people

        Reply ↓

        • Hi Mark,
          thanks for clarifying your point: I kind of understood your point first pretty much the other way around, now I feel relieved :-). For that “on an Eclipse blog” I always had more to cover than just that one thing. Beside that the word ‘Eclipse’ is not reserved for an IDE alone, and I’m always open for suggestions :-).

          To your point about the open-source hacking mentality: I agree and I find it amazing that companies with million $ budgets and producing expensive products believe that $99 or $199 is too much money for a professional grade debug probe and go for a bad $3 clone board instead, because they want to run some open source debug firmware on it. The same time that company complained about their products being cloned in Asia? Does not make any sense to me.

          Liked by 1 person

        • Hi Mark,
          I agree. Thanks for clarifying. I get you now.

          I used mainframe OSs in the late 70s and early 80s, PDP 11/73 was my CPU of choice as well digital equipments Mac assembler. Then moved to Unix on VME. So I think I’ve done more than a little hacking in my time.

          I don’t want to do it again! I even avoid the command line. Companies like Microsoft have made my development life easier. I blame educational institutions for the divide.

          In the company I work for now, they had that open source mentality when I first started… Im slowly reeducating them. Windows servers, mssql and other windows tools. We still use Linux and python and git and a number of good open source tools where appropriate, I endorse them. I’m here cause I like MCUXpresso!🤪

          I just don’t look at a tool and reject it based on the platform. Bit like judging it by the content of its code! 😁

          As a past time or just plain learning the nuts and bolts of computing, open source is great. I learnt key USB and encryption techniques through studying open source code. Understanding it and then building on it. In the bad ole days I would have had to reverse engineer!!

          This is a great discussion. I love this stuff!

          Liked by 1 person

        • Hey Mark,

          You wrote “in many engineering offices where it can be almost impossible to convince some programmers to invest a few hundred Dollars in a proven supported solution” and I’m reminded of the saying “it’s a poor craftsman that blames his tools”.

          I find that people who can effectively “debug” code are very rare and the ones that are good follow a structured process in which they understand exactly what is the problem, think about what is the best solution and then validate the selected solution. The most important thing I’ve found is, don’t call it “debug” that gives the impression of a quick fix – instead, in my last three jobs I insisted that my employees call it “failure analysis” which immediately changes the mindset as well as follow this process:

          1. Create a workflow in which the problem occurs reliably
          2. Characterize the problem with all available data. Understand what is going in, what is coming out and what is the operating environment
          3. Hypothesize as to what the problem is
          4. Create a process in which you can observe the hypothesized problem. If you can’t observe the problem, go back to 3.
          5. List multiple solutions to the fix the hypothesized problem
          6. Test the most likely solution using the process developed in 4. to see if the problem is addressed, if not, try the next most likely solution. If none of the proposed solutions work, go back to 3.
          7. Validate the fix in the system to ensure that it doesn’t affect any other functionality of the system
          8. Document and release the changes
          9. If necessary, change coding processes and guidelines

          The interesting thing about this process is that when you apply it religiously to all bugs, you find that you will resolve them faster because you are taking the time to understand them and validating their efficacy as well as minimizing the impact on other parts of the system.

          When you use a process like this, the importance of a debugger and its features is minimized. You may want to use it for step 2, as a way to look at variables and memory to help characterize the problem (useful in an embedded system where you can’t write a core dump to a file). Being able to set a breakpoint and single step is useful in steps 4. and 6. I should point out there’s a lot of wisdom in step 5. as the first solution that comes to mind is not often the best.

          Going back to my Kinetis problem (“PRINTF” SRAM Overhead/Stack Overflow) two weeks ago where I stupidly changed semihost_hardfault.c without really understanding what it was doing and then didn’t properly check to validate the change. When I was working to resolve the problem I was stuck on step 3. (and you can see that if you read through my comments). Once I had the comment from jingpan I was able to break out of the step 3. loop and hypothesize the problem and validate it and the fix (which was to restore the code to its original).

          If I were to say where I would like to see technology investment in is step 7 as it probably has the most impact in a project. When I worked at RIM, we brought in a guy who had worked on AWS for Bezos – Despite not being a programmer Bezos insisted on continually validating the AWS components (which were only to be used internally although his plan was to offer them as a product) using an automated testing process. We added automated testing (using SmartBear) and it completely changed the way we worked (further enforcing the process above), our quality metrics went through the roof and the development process was streamlined with very few distractions by difficult to resolve bugs. Automated testing is a big part of the Jade Robot software development process (we wrote our own tool) and it gives a nice feeling of confidence that we’re not introducing any bugs with fixes that affect other areas of the system.

          Sorry for the long post, but that’s my two cents on the issue.

          myke

          Liked by 2 people

  8. Hello Erich,

    As in the embedded platforms where we are not having any filesystem, to get the code coverage we need to break the gcov_do_dump() function from libgcov-driver.c, in order to get the code coverage data from gcov_close() function from gcov-io.c before it releases buffer from debugger console.

    dump binary memory start_address end_address

    This method will dump the code coverage data on the host side instead of embedded devices side. With toolchains having GCC versions before 5.4, those we are getting the code coverage data but with newer toolchains consisting of the latest GCC version doesn’t get the code coverage structures get populated.

    Same problem reference link is given here.

    https://bugs.launchpad.net/gcc-arm-embedded/+bug/1694644

    Please provide any feedback on the same.

    Regards

    Like

    Reply ↓

  9. Pingback: Visual Studio Code for C/C++ with ARM Cortex-M: Part 2 | MCU on Eclipse

  10. Pingback: Visual Studio Code for C/C++ with ARM Cortex-M: Part 3 | MCU on Eclipse

  11. Pingback: Visual Studio Code for C/C++ with ARM Cortex-M: Part 4 | MCU on Eclipse

  12. Pingback: Visual Studio Code for C/C++ with ARM Cortex-M: Part 5 | MCU on Eclipse

    • Hi Jonathan,
      It looks shiny, but I don’t think I would fit my needs. Unless you develop for a complete new CPU architecture you simply can use an existing design. Or develop your application logic fully on the host. And for the topic of this article: I don’t see it supporting Visual Studio Code?

      Like

      Reply ↓

  14. Pingback: Visual Studio Code for C/C++ with ARM Cortex-M: Part 6 | MCU on Eclipse

  15. Pingback: Visual Studio Code for C/C++ with ARM Cortex-M: Part 7 – FreeRTOS | MCU on Eclipse

    • Hi Thomas,
      yes, thankfully SEGGER has implemented their J-Link firmware for many other on-board debug circuits, including:
      – BBC micro_bit
      – NXP LPC-Link2
      – NXP LPCXpresso boards
      – NXP OpenSDA boards (FRDM, TWR)
      – ST-Link onboard

      >>You can even change jumpers and use the Nucleo-64 Link part as a debug probe for any ARM hardware.
      This is not really true. You have to read carefully the licensing terms, e.g. see https://www.segger.com/products/debug-probes/j-link/models/other-j-links/st-link-on-board/
      Basically you can use it only with STM devices, and only for STM evaluation boards (not any other boards or custom boards), and no other devices from other vendors. Plus you are not allowed to use it for any kind of production too.

      Again: this is a generous offer from SEGGER, but for everything: I always highly recommend to read and respect the licensing terms.

      Erich

      Liked by 1 person

      Reply ↓

  17. Pingback: MCUXpresso IDE 11.4.0 | MCU on Eclipse

  18. Pingback: Visual Studio Code for C/C++ with ARM Cortex-M: Part 8 – xPack C/C++ Managed Build Tools | MCU on Eclipse

  19. Pingback: Visual Studio Code for C/C++ with ARM Cortex-M: Part 9 – RTT | MCU on Eclipse

  20. Pingback: Visual Studio Code for C/C++ with ARM Cortex-M: Part 10 – Assembly Stepping | MCU on Eclipse

  21. I’m working with the LPC55S69JBD100 MCU. I can already build a project in vscode using cmake but now I need to debug it. It is possible to use cmsis-dap with openocd? I can’t seem to figure out how to make it work.

    Liked by 1 person

    Reply ↓

    • I had very little success with OpenOCD and NXP devices: I recommend that you use a J-Link: it costs only $20 with the mini EDU version, and the license allows you to use it for non-profit/hobby/educational usage.

      Like

      Reply ↓

  22. I’m working with the STM32MP157c-dk2. I am trying to build and Debug the project in VS code u but I am not able to import the project. I can’t seem to figure out how to make it work.
    Please suggest!!

    Liked by 1 person

    Reply ↓

  23. Pingback: The Matthew Test: 2022 Survey Results - Cove Mountain Software

  24. Pingback: Open source ARM based toolchain development and debug on Windows with no emulation – ALEA

What do you think?

This site uses Akismet to reduce spam. Learn how your comment data is processed.