Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Setting up a vscode development environment for mbed 5 application using the gcc tool chain on windows

70 views

Published on

Manual on setting up VSCODE environments for MicroController Application Development

Published in: Software
  • Be the first to comment

  • Be the first to like this

Setting up a vscode development environment for mbed 5 application using the gcc tool chain on windows

  1. 1. Setting Up a VSCODE Development Environment for MBED 5 Application using the gcc tool chain on Windows Dr. Steve W. Mylroie Roietronics smylroie@ix.netcom.com Version 0.6.0
  2. 2. 2 Copyright 2018 Steve Mylroie (DBA Roietronics) Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.
  3. 3. 3 Contents Introduction ..................................................................................................................................................5 Installing the needed applications................................................................................................................5 Creating A Test Environment........................................................................................................................8 Configuring and Verifying the Build Environment......................................................................................11 Configuring the Build Environment.........................................................................................................11 Verifying the Build Environment.............................................................................................................15 Verifying the Debugging Environment........................................................................................................16 For Boards using the CMSIS_DAP Link Interface and pyocd-gdbserver .................................................17 For Boards using Serial JTAG Link Interfaces other than CMSIS_DAP ....................................................18 End to End Verification ...............................................................................................................................19 Working with Projects having support for export to vscode-gccc-arm......................................................22 Working with Projects which don’t support export to vscode-gcc-arm.....................................................22 Creating a new Project using VSCODE ........................................................................................................25 Troubleshooting..........................................................................................................................................25 Builds.......................................................................................................................................................25 Using Make .........................................................................................................................................25 Using mbed compile ...........................................................................................................................25 Debug Connections.................................................................................................................................25 Using PyOcd ........................................................................................................................................25 Using OpenOCD...................................................................................................................................25 Interfacing with Code Repositories.............................................................................................................25 GitHub and Git based Repositories.........................................................................................................25 Updating..............................................................................................................................................25 Reverting.............................................................................................................................................25 Publishing............................................................................................................................................25 MBED User and other Mercurial Based Repositories.............................................................................25 Updating..............................................................................................................................................26 Reverting.............................................................................................................................................26 Publishing............................................................................................................................................26 Appendix .....................................................................................................................................................26 Batch Scripts............................................................................................................................................26
  4. 4. 4 make.bat .................................................................................................................................................26 mbed.bat.................................................................................................................................................26 MyStart.bat.............................................................................................................................................26 Supported Boards ...................................................................................................................................26 pyocd-gdbserver .................................................................................................................................26 OpenOCD ............................................................................................................................................26 Converting Release Build Makefiles to Debug Build MakeFiles..............................................................26 Reinstalling the MBED Windows CMSIS_DAP Serial Link Port Driver.....................................................27 VSCODE –MBED System Architecture.........................................................................................................28
  5. 5. 5 Introduction The ARM MBED 5.0 IoT Device Platform provides the operating system, cloud services, tools and developer ecosystem to make the creation and deployment of commercial, standards-based IoT solutions possible at scale. The platform provide a single unified open source development environment and Real Time operating system covering hardware products from over 70 chip, microcontroller, board, sensor and module vendors. A key component of this platform is a powerful web based online IDE; however due to web latency issues this IDE is lacking support for one critical feature, interactive debugging. VSCODE on the other hand is a modern, platform independent, open source, highly extensible language agnostic local editor, with advanced features such as IntelliSense, Auto Completion, and integrated documentation similar to those found in modern IDEs such as Visual Studio, Eclipse and Atom. In addition it can link up with various open source and proprietary on chip debugging (OCD) servers via the GNU Tools ARM Embedded arm-none-eabi-gdb debugger to provide interactive debugging support for MBED created application which have been loaded onto and running on one of the many microcontrollers supported by the ARM MBED 5.0 platform. By Integrating a local VSCODE environment with the online MBED environment IOT and Microcontroller developers can have access to the best features of both worlds. The ARM MBED development teams have embarked on an effort to provide integration between the online MBED development environment and a local VSCODE development environment. This effort is currently in a very early stage and the setup process is much more involved and difficult that those associated with the kind of setup processes windows user have come to expect. In addition instruction of setting up and configuring the environment are scattered across a number of posts on the MBED forms In addition comments posted to MBED indicated that many MBED users on Windows have been unsuccessful in getting a working environment setup and have given up the effort. I am therefore creating this tutorial based my trail and errors experiences in the creation of integrated online MBED IDE and local VSCODE development environments on both Windows 7 and Windows 10 platforms. My hope being to allow others to avoid the pit falls and traps I stumbled through and enjoy the benefits of a working integrated online MBED – local VSCODE with interactive on chip debugging on a Windows platform. Installing the needed applications The integrated VSCODE/MBED environment requires components from number of open source projects in addition to VSCODE and as stated in the introduction there currently is no single unified setup application. User must visit multiple web sites and perform multiple installations.
  6. 6. 6 Needed components include: 1. VSCODE 2. Microsoft C/C++ Extensions for VSCODE 3. MBED command line interface package (CLI) 4. Python 2.7 5. The GNU TOOLS ARM Embedded package 6. Git client 7. Mercurial client 8. A Windows compatible version of the UNIX/LINIX make utility 9. If the serial JTAG interface to the target microcontroller board uses the CMSIS_DAP protocol a PyOCD-gdbserver package 10. If the serial JTAG interface to the target microcontroller uses a protocol other than CMSIS_DAP e.g. STLink SeggerLink, JLink, etc; an OpenOCD package. User will need to consult the microcontroller and/or board vendors documentation in order determine the protocol used with a specific board/Microcontroller combination. For example boards with STM microcontrollers use STLink, and the Nordic NRF development boards use SeggerLink The specific link protocol supported by the packages can be found on the package project’s web sites While between the two packages support large number of board/Microcontrollers can be found, not every existing Microcontroller/Board combination is supported. The existence of support for a particular Microcontroller/Board combination can be determined from the project’s web sites or after a package is installed via techniques described in the Troubleshooting Debug Connections section of this document. Adding support additional board/Microcontroller combinations to one of these interface server packages is a rather involved project. Detailed procedures and requirements can be found on the project’s web sites. If a board/Microcontroller combination is not support one would probably want to discontinue this effort unless they can convince one of the contributors to one of these projects to add the combination to the supported the set. VSCODE can be down loaded from this URL and comes with a standard Windows installer. VSCODE Download Once VSCODE is installed install the Microsoft C/C++ extension for VSCODE package using its extension management interface
  7. 7. 7 1. Select the extension management view by clicking on its icon in the right hand side tool bar Click here 2. Select the Microsoft C/C++ extensions from the list of installable extensions and click on its install button. If the extension does appear in the list enter C/C++ in the search text box to search the market place for it. Note: The VSCODE-MBED extension version 0.2.0 in the market place on works on MAC OS. 3. Click the extensions reload button to activate the extension Click Her e
  8. 8. 8 Click Here The Windows installer for the MBED CLI will also install Python2.7, The GNU TOOLS ARM Embedded package Git client, Mercurial client and PyOCD package. Download the Windows MBED CLI installer from here Install requires admin privilege Depending on other installed USB driver, the Serial Post driver may fail to install, failure to install driver has not created problems unless one will be using the pyOCD-gdbserver for to provide debugging access to their selected board. A Windows compatible version of the Unix/Linux make utility can be found here make One just needs the ninaries Zip file. Download and unzip into a convenient directory. PyOCD-g is installed by the MBED installer and the project Web site is here The OpenOCD web sitesite does not provide any precompiled binaries or install packages A compiled binary package for Windows with an installer is available for download here Creating A Test Environment To create a stable test environment to use while setting up your local VSCODE-MBED download the mbed-os-example-blinky sample application from the MBED development web site. This action requires a three step process. If one already has registered for a MBED developer account (FREE) one can step to step 2. If one has and MBED developer account and has already loader the mbed-os-example-blinky project in to their MBED web workspace they should skip to step 3. 1. Create a MBED user account Go to the MBED developer web site click the login/signup item on the menu bar and
  9. 9. 9 follow the displayed instruction for creation an new user account. 2. Load the mbed-os-example-blinky project into your MBED web workspace Select the documentation item from MBED developer web site’s menu bar and then tutorials from the next page. Expand the right hand side menu tree until your reach the Blinky page and click on the Import into Mbed IDE button. 3. Export the project to your local system Click the compiler item on the MBED developer’s web site’s home page to switch to your workspace page. Locate entry for the mbed-os-example-blinky in the project list and right click on it and then select the export Program from the Popup Menu.
  10. 10. 10
  11. 11. 11 In the popup dialog box select your board as the Export Target and Vscode_gcc_arm as the export tool chain and click the export button. A custom make file will be created and bundled into a zip file along with the source files and the need template and control files. The zip will then be passed to your browser’s file download subsystem. Using your browser’s file download controls save the zip file to a directory on your local system. Terminate the browser session, switch to your local system and expand the zip file using your favorite tool. Once you have complete the setup process and verified the functionality of the local integrated VScode MBED system you will be using the same process to import other projects in to your local system. Configuring and Verifying the Build Environment Configuring the Build Environment In order debug a MBED application using the Vscode-mbed CLI on a local system, one must first build the application locally. In this section you will configure and verify the functionality of the build environment using the mbed-os-example-blinky application you downloaded in the previous section.
  12. 12. 12 You will need to have a working build environment before you can setup the debugging environment. If your encounter problems in this section the Trouble Shooting Builds section has a number of hints for solving the problems. When one exports a MBED project from the MBED web environment create a custom UNIX/LINUX style makefile for the Target Board and adds it to the downloaded zip file. The tools directory from mbed=os library are not included in the downloaded file. One therefore needs to use a UNIX style make utility and the gcc tools to build the executable to load unto the target board. This task could be accomplish by specifying make.exe in the VSCODE TASK configuration JSON file if the correct paths to the make utility and the gcc tools have been configured in the users Global Windows environmental PATH variable. I however would recommend that instead of trying to use the correctly modify your user global PATH variable to invoking a batch file which set up a local version of the PATH variable which references on the directories with the make utility and the gcc build tools and then invokes the make utility executable. A sample make file (make.bat) can be found in the appendices of this document. There are three Jason files which configure VSCODE’s action for your project (launch.json, task.json and setting.json) these file should be in a .vscode subdirectory in the VSCODE project. The mbed export sometimes put them in the project top level directory. You will need to fix this issue before proceeding. To fix create a .vscode directory subdirectory and move the three files into it. (Note: When using the window’s File Explorer’s Make New Directory or Rename Directory commands to create a directory whose name start with a . one must append a . character to the end of the name e.g. to create a .vscode directory enter .vscode. as the directory name.) The following steps configure your VSCODE environment to permit the building of MBED applications in locally using the gcc tool chain. 1. Start a VSCODE session 2. Select open folder from the drop down menu opened by clicking on the menu bar file tab
  13. 13. 13 3. In the File Open dialog box which appears select the top level directory into which you unpacked the downloaded zip file and click the select Folder Button
  14. 14. 14 Editing make.bat 4. Select new file from the File tabs drop down menu and copy the text of the sample make.bat file from this appendix of this document into the file editor window. Replace the angle bracket set with the full path to the bin directory with the make utility executable and second angle bracket set with the full path to the bin directory with the arm-none-c++ executable. On my system <GnuWin32 Make install directory path> => C:Program Files (x86)GnuWin32 <GNU Tools ARM Embedded install path> => C:Program Files (x86)GNU Tools ARM Embedded6 2017-q2-update Click the dot above the file editor window to close and save the file as make.bat
  15. 15. 15 Click the dot close and saved the file Editing .vscodetasks Click on the triangle next .vscode in the file list panel to expose the directories file list and then click on the tasks.json file to open it in the editor view Scroll down to the line starting with “windows”: and change make.exe to make.bat Then click on the x next to the file name at the of the editor panel to close and save the file changes. Verifying the Build Environment Select Run Build Task from the menu bars task tab A console log window will open in a panel at the bottom of the window and messages from make will start scrolling through it.
  16. 16. 16 If when the display stops scrolling the display looks like this you have working build environment If the display ends with lines like this don’t panic make.exe[1]: Nothing to be done for `all'. make is just say it can’t find anything which require rebuilding in the application However if the message is ending lines contain a line make.exe[2] you have build errors you need to fix before proceeding. Verifying the Debugging Environment The VSCODE-MBED debugging system uses a three process chain. 1. VSCODE communicates with a GNU gdb debugging server via a pipe. 2. The gdb server connects to a On Chip Debugging (OCD) server via TCP/IP 3. The OCD server in turn interacts with the code running on the chip via a serial JTAG link An overview of the system can be found here VSCODE –MBED System Architecture Two different OCD servers (a PyOCD-gdbserver or an OpenOCD server) depending on the board/processor combination and JTAG link being used. The PyOCD-gdbserver can auto detect the attached board/microcontroller and auto configure itself; however it only supports the MBED cmsis-DAP protocol and a limited set of board/microcontroller families. See the appendix for a list of support microcontroller families and pyocd-gdbserver supported boards. A MBED export to VSCODE configures the environment for use with Pyocd-gdbserver by default.
  17. 17. 17 The OpenOCD server is more flexible supporting more board/microcontroller combinations and multiple JTag link protocols including many vendor specific implementations. For example one must use OpenOCD to debug a STM microcontroller since there controller only work with the STM SLINK protocol. OpenOCD does not support auto detection and a user must select and provide a link to a proper configuration files as command line arguments to the server. The Launch.json file in the project’s .vscode directory sets up the debugging environment For Boards using the CMSIS_DAP Link Interface and pyocd-gdbserver A MBED export provides an launched.jason file preconfigured to use the pyocd-gdbserver; however two modification to it are required. Open the launch.jason file in the VSCODE editor and scroll down to the Windows section 1. Check that the highlighted subdirectory field in the path for the gdbserver matches the path for the gdbserver installed on your system. This field is linked to the GNU package‘s version and the one in the preconfigured down loaded launch.jason file is for a very old version. 2. Replace make.exe with make.bat pre line i.e. the same make.bat file you used verify the build environment. The pyocd-gdbserver only works with boards using the CMSIS_DAP serial jtag and boot protocols. To determine if your board is using the CMSIS_DAP protocols connect your board’s USB programing link to one of your computer’s USB port and observe the name assigned to the board mount point in File Explorer. If the name is DAPLINK you can used pyocd-gdbserver to debug code running on your board otherwise you will need to use the OpenOCD sever to debug code running on your board.
  18. 18. 18 If you are using one of the NXP FRDM boards and it mounts with a name other than DAPLINK your board either has outdated or alternate vendor boot loader firmware. See the following link for information for instruction on how to install the proper boot loader firmware on to the board. https://os.mbed.com/blog/entry/DAPLink-bootloader-update/ For other boards you will need to consult the MBED forums or the board vendors Web sites. The pyocd-gdbserver also requires a working copy of the MBED serial link driver software be installed on your computer. If the MBED serial link driver software failed to install when you did the mbed-cli install, you found your board was not mounting as DAPLINK, you have updated your bootloader firmware and you board now mount as DAPLINK. Used the procedure outlined in Appendix to install the missing MBED serial link driver. If the driver still does not install you will need to use the OpenOCD server instead of the pyocd=gdbserver. The next section deals with verifying configuration required in order to use the OpenOCD server so skip to the End to End verification section if using the pyocd=gdbserver For Boards using Serial JTAG Link Interfaces other than CMSIS_DAP If the board you are using doesn’t use the MBED cmsis-dap JTAG link or is not on the list of boards supported by PyOCD=gdbserver you will need to use the OpenOCD server. Four changes to the MBED supplied launch.jason file in the .vscode directory will be required. Since the OpenOCD does auto-detect boards types, you will need to locate a proper configuration file before editing launch.jason. A large number of these files with .cfg extension can be found in the .scriptsboard subdirectory of your OpenOCD installation. i.e. C:Program FilesOpenOCDscriptsboard on my system Many of the configuration files cover several boards in the same family for example st_nucleo_f4.cfg covers a st_nucleo_F411RE, a st_nucleo_F446RE and other boards in the st_nucleo_F4XXXX family. Open the MBED supplied launch.jason file in the VSCODE editor and 1. Find the line "serverStarted": "GDB server started", and replace it with "serverStarted": "target halted due to debug-request, current mode: Thread", (Exact text required since line is used to detect suggest full server start up) 2. Scroll down to the windows section and make following changes a. Change PreLanuchTask to make.bat b. Verify highlighted subdirectory in the gdb server path matches the install path on your system c. Change the debugServerPath to the full path to the OpenOCD executable d. Add a debugServerArgs line with the following text
  19. 19. 19 e. Replace the st_nucelo_f4.cfg with the name of the cfg file for your board (note: the and “ characters need to be escaped with a character and paths with spaces need to be enclosed in escaped “) 3. Save and close the file End to End Verification You now ready for a debugging session ================================================================================== Note: On some recent downloads from MBED, I have found that the MBED exporter was creating a custom Makefile for a release build instead of a debug build. A release build does not create a symbol table file. If a symbol table file is not available VSCODE cannot highlight current source line when single stepping or display the content of variables. The following procedure can be used to determine is the Makefile will generate a release or a debug build. Open the Makefile in VSCODE and search for the term –DTARGE_RELEASE (Crtl+f –DTARGE_RELEASE) if the term is found the file is a Makefile for a release build. If a search for the term –DTARGET_DEBUG finds a match you have a Makefile for a debug build. See Appendix for a hack which can be used to turn a release Makefile into a debug Makefile ===================================================================================== Open main.cpp in the VSCODE editor windows and right click to the left of line 8 and set a break point. A red do will appear to the right of the line Switch to debug mode by clicking on the debug icon on the right hand toolbar
  20. 20. 20 Then click then click green arrow to right of the word DEBUG on the top menu If a line like this appears at the top of your screen you have a problem with lanch.jason file If the Debug Console window is not open click select it as the output window to show more details and then consult the trouble shooting sections of this document If the debug session successfully stated and you using pyocd-gdbserver you should see the following display in the debug console window Click Here Click Here
  21. 21. 21 If the debug session successfully stated and you using OpenOCD you should see the following display in the debug console window The red dot will change to an orange arrow you are halted at the break point. Click the green arrow on the popup tool bar the program will cycle back to the break point and led will be on Click the green arrow again and the led will turn off Click the red square on the toolbar to exit
  22. 22. 22 Congratulation you have configured a working VSCODE-MBED environment see the follow section for instruction on how to bring in your programs. Working with Projects having support for export to vscode-gcc-arm When using the MBED export option MBED makes a snapshot of your on line environment, adds a custom make file and three VSCODE control files, bundles everything up in a zip file which it downloads to your machine. The process then is 1. Open the project in the online environment 2. Select Export 3. Specify the target board and vscode_gcc_arm as the tool chain from the popup dialog box’s drop down menus. 4. Unpack the zip file 5. The need make.bat and vscode json control files will be the same as the one used with the mbed-os-example-blinky project so just copy those four files from that project to your new project replacing the ones generated by MBED 6. Determine whether MBED created a release or debug build Makefile and convert a release build Makefile to debug build Makefile 7. Open the top level project folder in VCODE and start debugging The MBED export process does not include in repository information or the mbed-os tools subdirectory in the download package; therefore if you want to change the board or a library revision you must make the changes in the online environment and do a new export. Also you will not be able to commit or publish any changes you make to the code to the online repositories. To save any code changes you will need to copy them back to the online environment using the online editor and then commit and publish them from the online environment. If you want the ability to switch boards and revisions or commit changes from the local environment you will need to use the import based procedures described in the next session instead of the export based procedure. Working with Projects which don’t support export to vscode-gcc-arm For some boards the MBED export options tool chain list does not include vscode_gcc_arm or in other cases for example the MULTI_TECH mDot and xDot boards the export process just crashes. In these cases one must use the more complex import process instead of the MBED export process.
  23. 23. 23 One also needs use the import process instead of the export process if one wants to interact with the MBED repositories (github for mbed-os and /or Mercurial based user repositories and/or changes boards without doing a new export. The following procedure is used to import a project on to the local system from MBED 1. Open the project in online MBED 2. Copy the projects repository URL from the online window 3. Open a command window on the local machine 4. Change directory to the location where you want to place the project folder 5. Enter the command mbed import <copied URL> in the command window note: right clicking in a command window will bring up a dialog allow pasting from the clipboard This process will take a while since both the github mbed-os repository and the users Mercurial repository are being cloned to the local machine 6. Change directory to the project root directory 7. Enter the following command mbed config ARM_GCC_PATH “<full path to gcc compilers>”. replace <…> with path to gcc compilers on your system. Quotes required if path contains space characters 8. Enter the command mbed config TARGET <mbed board name> where <…> is the MBED name for the board. For example MTS_MDOT_F411RE for the MULTI TECH mDOT
  24. 24. 24 9. Create .vcode subdirectory in your project directory 10. Copy the 3 json vscode control files from the .vscode subdirectory of blinky project your used to verify your setup 11. Create a mbed.bat file in the top level project directory 12. Copy content of the mbed.bat script section of this document 13. Replace the < path> item in the scrip with the paths for python 2.7 and the gcc arm embed tools on your system 14. Edit the tasks.jason and launch.jason file in the project’s .vscode subdirectory replacing make.bat with mbed.bat 15. Open the project folder in VSCODE and proceed as you would for an exported project Your project tree will contain local clones of both the mbed-os github repository and the user Mercurial repository and a full set of the MBED python scripts. The arguments in the mbed.bat file insure you always create debug builds and never create a release build. Since one ends up with a full clone for the mbed-os library project from gethub, One can switch boards by opening the .mbed file in the projects root folder and editing the TARGET=XXXX line and recompiling.
  25. 25. 25 Creating a new Project using VSCODE Troubleshooting Builds Using Make Using mbed compile Debug Connections Using PyOcd Using OpenOCD Open console window and run the MyStart.bat script from that windows OpenOCD will display lots of diagnostic info Interfacing with Code Repositories GitHub and Git based Repositories VSCODE has a building git client by default. Committing Updating Reverting Publishing MBED User and other Mercurial Based Repositories To work with Mercurial repositories you will need to add a VSCODE Mercurial Client (HG) Extention.
  26. 26. 26 Committing Updating Reverting Publishing Appendix Batch Scripts make.bat set PATH=<GnuWin32 Make install directory path>bin;<GNU Tools ARM Embedded install path>bin make.exe mbed.bat set PATH=<Python27 install directory path>scripts;<GNU Tools ARM Embedded install path>bin mbed.exe compile -t gcc_arm --build .BUILD --profile .mbed-ostoolsprofilesdebug.json MyStart.bat pushd "C:Program FilesOpenOCD0.10.0-5-20171110-1117" dir .binopenocd.exe –d -s .scripts -f boardst_nucleo_f4.cfg -c init -c "reset init" popd Supported Boards pyocd-gdbserver kl25z, kl26z, lpc824, k82f25615, lpc11xx_32, kinetis, lpc800, lpc4088qsb, maxwsnenv, kl05z, k64f, lpc1768, lpc4088, lpc4330, max32600mb, k66f18, w7500, ke18f16, k22f, lpc4088dm, ke15z7, kv11z7, nrf51, nrf52, kv10z7, k20d50m, kl46z, stm32f103r, kl27z4, kw40z4, cortex_m, lpc11u24, stm32f051, kl02z, ncs36510, kl28z, kl43z4, kw01z4 OpenOCD Converting Release Build Makefiles to Debug Build MakeFiles 1. Open the Makefile in VSCODE 2. Search for the term –DTARGET_RELEASE and replace with –DTARGET_DEBUG (you should find two occurrences – one in C_FLAGS and one in CXX_FLAGS 3. Search for the term eabi-gcc you should find three occurrences
  27. 27. 27 4. In the line that start with AS search for the term ‘–Os’ and replace with the following text '-O0' '-g3' '-DMBED_DEBUG' '-DMBED_TRAP_ERRORS_ENABLED=1' 5. Make the same change to the line that starts with CC 6. Search for the term eabi-g++ and then for the term ‘–Os’ on that line and replace that term with '-O0' '-g3' '-DMBED_DEBUG' '-DMBED_TRAP_ERRORS_ENABLED=1' 7. Save and close the Makefile Reinstalling the MBED Windows CMSIS_DAP Serial Link Port Driver
  28. 28. VSCODE –MBED System Architecture Debug Edit Build PyOCD-gnu-server VSCODEGdb-debug Board Type 1 OpenOCD server TargetPyOCD-gnu- server Target Board Type 2 mbed GNU Build Tools Make mbed Tools Python Scrips_ GNU Build Tools

×