Difference between revisions of "Hardware And Software Setup"
From EdWiki
m (→Hardware And Software Setup) |
m |
||
Line 63: | Line 63: | ||
<div class="tabs-content"> | <div class="tabs-content"> | ||
<div class="content active" id="VSCodeSetup"> | <div class="content active" id="VSCodeSetup"> | ||
− | + | {{EmSys:Developing Cortex M3 Applications Using Visual Studio Code}} | |
</div> | </div> | ||
<div class="content" id="VSCodeWorkspace"> | <div class="content" id="VSCodeWorkspace"> |
Revision as of 03:32, 30 March 2022
Hardware And Software Setup
What is Toolchain?
- A toolchain is a collection of programming tools.
- It consists of a compiler, linker, assembler, and a debugger.
- The GNU toolchain is a programming tools produced by the GNU Project.
The toolchain used for embedded development is a cross toolchain (cross compiler). In other words, when the host and target architectures are different, the toolchain is called a cross compiler (e.g. if we develop a code on a Linux machine based on the x64 architecture, but we're compiling for an ARM target, then we need Linux-based ARM-targeting cross compiler).
When talking about toolchains, one must distinguish three different machines:
- the build machine, on which the toolchain is built
- the host machine, on which the toolchain is executed
- the target machine, for which the toolchain generates code
Toolchain - Name convention
Toolchain name usually contains the so-called target triple, which is in the form of arch[-system][-abi] or in a longer form arch[-vendor][-system][-abi], e.g. arm-linux-gnueabihf. Typically, local toolchains have symbolic links that omit triple in binary name: we use gcc instead of the full name x86_64-linux-gnu-gcc.
- arch - architecture
- arm, mips, x86, i686, etc.
- vendor - tool chain supplier
- os - operating system
- linux, none (bare metal)
- abi - application binary interface
- eabi, gnueabi, gnueabihf
Examples
arm-none-eabi
This toolchain targets the ARM architecture, has no vendor, does not target an operating system (i.e. targets a "bare metal" system), and complies with the ARM eabi. (Note) arm-elf and arm-none-eabi just use two versions of the ARM abi. The eabi toolchain uses a newer revision, but could also be called arm-elf-eabi, as it generates elf too.
i686-apple-darwin10-gcc-4.2.1
This toolchain targets the Intel i686 architecture, the vendor is Apple, and the target OS is Darwin version 10.
arm-none-linux-gnueabi
The toolchain that can be installed in Debian-based systems using a package manager like apt (the package is called gcc-arm-linux-gnueabi). This toolchain targets the ARM architecture, has no vendor, creates binaries that run on the Linux operating system, and uses the GNU EABI. In other words, it is used to target ARM-based Linux systems.
arm-linux-gcc
This is actually binary for gcc which produces objects for ARM architecture to be run on Linux with default configuration (abi) provided by toolchain.
i686-unknown-linux-gnu
32-bit GNU/linux
arm-eabi
Android ARM compiler
x86_64-w64-mingw32
x86_64 architecture means AMD64, w64 is actually mingw-w64 used as a "vendor" here, mingw32 is the same as win32 API for gcc's perspective.
i686-pc-msys
32-bit, "pc" is a generic name, msys binary
Code Composer Studio
Code Composer Studio includes a Linaro distribution of the ARM GNU compiler, so programmers have the option of using this GCC Compiler instead of the TI compiler to build their projects.
Objective
The objective of this lab exercise is to download and install Code Composer Studio, as well as download the various other support documents and software to be used with this course. These development tools will be used throughout the remaining lab exercises in this course.
CCS v9 - Hardware Requirements
Memory | Recommended | |
---|---|---|
Memory | 2GB | 6GB |
Disk Space | 900MB | 2GB average (1 or 2 device families) 3.5GB all features |
Processor | 1.0GHz x86 compatible processor | Dual core x86 compatible processor |
- Disk space listed depends on features selected during installation. 900MB is for a bare minimal installation. Does not include temporary space required by the installer.
- Note that the most important requirement is memory. At least 4GB of memory or more is highly recommended.
CCS v9 - Operating System Requirements
- Windows
- Windows 7 (SP1 or later), Windows 8.x and Windows 10
- Ubuntu 18.04 LTS
- update system and Install dependent libraries
sudo apt-get update sudo apt-get install libc6-i386 libusb-0.1-4 libgconf-2-4 build-essential
Install
► Windows 7 (SP1 or later), Windows 8.x and Windows 10
There are two two editions for Windows, 32-bit and 64-bit installers:
► 32-bit Edition will allow you to install on the 32-bit edition of Windows. Obtain "EmSys Tools CD" from your instructor or Download it from here
► 64-bit Edition will allow you to install on the 64-bit edition of Windows. Obtain "EmSys Tools CD" from your instructor or Download it from here
► Unzip CCS8.3.0.00009_win32.zip (32-bit edition) or CCS10.2.0.00009_win64.zip (64-bit edition)
► Navigate to CCS8.3.0.00009_win32 or CCS10.2.0.00009_win64 folder
► Run ccs_setup_8.3.0.00009_win32.exe (32-bit edition) or ccs_setup_10.2.0.00009.exe (64-bit edition)
► This will start the CCS install wizard.
NOTE: you have to de-activate your antivirus temporary during the installation, as the installer ask you:
Just in case, in order to be secure, just avoid any web-surfing or torrent or any other internet communication in the meantime.
- Accept the Software License Agreement and click Next.
- Unless you have a specific reason to install CCS in another location, accept the default installation folder and click Next. If you have another version of CCS and you want to keep it, we recommend that you install this version into a different folder.
- In the next dialog, select the processors that your CCS installation will support. Place a checkmark under "TM4C12x ARM Cortex M4F core based MCUs"
- Click Next
- In the Select Debug Probes, leave everything as default and click Next
If everything looks good, click Finish to start your install!
Note: If you have an issue with the web installer not being able to connect to the internet then please try the off-line installer.
Please have patience as It takes some time to do all the work. When the installation is complete, uncheck the “Launch Code Composer Studio ” checkbox and then click Finish button.
Verify ICDI Device Drivers
► Assure that your LaunchPad is connected to your laptop.
► Click on the Windows Start button.
► Right-click on Computer and select Properties from the drop-down menu.
► Click on Device Manager on the left of the dialog.
The Device Manager window displays a list of hardware devices installed on your computer and allows you to set the properties for each device. If you see any of the following three devices listed in the Other category:
- Stellaris ICDI JTAG/SWD Interface
- Stellaris ICDI DFU Device
- Stellaris Virtual Serial Port
it means that the driver for those devices is not installed.
Run this step only if your device drivers did not install properly.
► Obtain the ICDI drivers from your instructor or download the zip file from
Stellaris ICDI Drivers for Windows.
► Unzip the file to a folder on your desktop.
► Back in the Device Manager, right-click on each of the Other devices (one at the time) and select Update Driver. In the following dialogs point the wizard to the folder on your desktop with the unzipped files. If the process seems to take longer than it should, the wizard is likely searching on-line. Turn off your wireless or disconnect your network cable to prevent this.
► Make sure all three devices listed above are properly installed.
Install Code Composer Studio - Ubuntu
Prerequisites
Resolve Dependencies, before proceeding to Installation Instructions.
Ubuntu 20.04 LTS
- update system
host@user$ sudo apt update
- install dependent libraries:
host@user$ sudo apt install libc6:i386 libusb-0.1-4 libgconf-2-4 libncurses5 libpython2.7 libtinfo5
Ubuntu 18.04 LTS
- update system:
host@user$ sudo apt-get update
- Install dependent libraries:
host@user$ ssudo apt install libc6:i386 libusb-0.1-4 libgconf-2-4 build-essential
Ubuntu 16.04 LTS
Starting with this version of new CCSv6.2.0, the application is natively 64-bit and only requires one 32-bit library installed.
From a terminal prompt, issue the following command to install it:
host@user$ sudo apt-get update host@user$ sudo apt-get install libc6:i386
This is due to the fact Linux 64-bit versions of the TI compilers were not yet ready.
Installation Instructions
► Obtain the CCS Installer CD from your instructor or Download it from here
► Simply save the file and untar.
► Open terminal either via Ctrl+Alt+T keyboard shortcut or by searching for “terminal” from software launcher
► Navigate to CCS10.2.0.00009_linux-x64 folder
► Run ccs_setup_10.2.0.00009.run as a normal user.
host@user:~/Downloads/CCS10.2.0.00009_linux-x64$ ./ccs_setup_10.2.0.00009.run
This will start the CCS install wizard.
- Accept the Software License Agreement and click Next.
- Unless you have a specific reason to install CCS in another location, accept the default installation folder and click Next. If you have another version of CCS and you want to keep it, we recommend that you install this version into a different folder.
- In the next dialog, select the processors that your CCS installation will support. Place a checkmark under "TM4C12x ARM Cortex M4F core based MCUs" → click Next
- Please Note the Unsupported boards, click Next
- In the Select Debug Probes, leave everything as default and click Next
If everything looks good, click Finish to start your install!
Note: If you have an issue with the web installer not being able to connect to the internet then please try the off-line installer.
Please have patience as It takes some time to do all the work. When the installation is complete, check the “Create Desktop shortcut” checkbox and then click Finish button.
Install Drivers
Once CCS installation has completed, navigate to directory <Install-Folder>/ccs1020/ccs/install_scripts.
host@user:~$ cd ~/ti/ccs1020/ccs/install_scripts/
As root, execute script "install_drivers.sh".
host@user:~/ti/ccs1020/ccs/install_scripts$ sudo ./install_drivers.sh
Ubuntu
Download TivaWare™ for C Series, and unzip into a folder, lets call TivaWare_C_Series-2.1.4.178 folder in your home directory:
host@user:~$ cd ti host@user:~$ mkdir TivaWare_C_Series-2.1.4.178 host@user:~$ sudo apt-get install -y unzip &>> /dev/null host@user:~$ unzip -u ~/Downloads/SW-TM4C-2.1.4.178.exe -d ~/ti/TivaWare_C_Series-2.1.4.178
Windows
► Download TivaWare™ for C Series.
► Run SW-TM4C-2.1.4.178.exe file (It's self-extracting)
► Please install TivaWare into the drive:\ti\TivaWare_C_Series-2.1.4.178 folder.
Tools included in the TivaWare for C Series suite
The TivaWare for C Series suite contains and integrates all user-required source-code functions and object libraries, which include:
- Peripheral Driver Library (DriverLib)
- Graphic Library
- USB Library
- Sensor Hub Library
- Open Source RTOS
- Open Source Stacks
- Utilities
- Boot Loader and In-System Programming Support
- Example Codes
- Third-Party Examples
GNU Arm Embedded Toolchain (Pre-built GNU toolchain for Arm Cortex-M and Cortex-R processors)
The GNU ARM Embedded toolchains are integrated and validated packages featuring the ARM Embedded GCC compiler, libraries and other GNU tools necessary for bare-metal software development on devices based on the ARM Cortex-M and Cortex-R processors. The toolchains are available for cross-compilation on Microsoft Windows, Linux and Mac OS X host operating systems.
These toolchains are based on Free Software Foundation's (FSF) GNU Open source tools and newlib.
These toolchains support ARM Cortex-M0, Cortex-M0+, Cortex-M3, Cortex-M4, Cortex-M7, Cortex-M23, Cortex-M33, Cortex-R4, Cortex-R5, Cortex-R7, Cortex-R8 and Cortex-R52 processors.
Download GNU Arm embedded toolchain
The GNU Embedded Toolchain for ARM is a ready-to-use, open source suite of tools for C, C++ and Assembly programming targeting Arm Cortex-M and Cortex-R family of processors. It includes the GNU Compiler (GCC) and is available free of charge directly from Arm for embedded software development on Windows, Linux and macOS operating systems.
- You can download Arm GNU Toolchain for your platform from here
Ubuntu (20.04)
- Please download the toolchain from this link and untar it.
- OR, we can install using apt
$ sudo apt update $ sudo apt install gcc-arm-none-eabi binutils-arm-none-eabi
Tiva C Series EK-TM4C123GXL LaunchPad Boad
Description
The TM4C123G LaunchPad Evaluation Kit is a low-cost evaluation platform for ARM Cortex-M4F based microcontrollers from Texas Instruments. The design of the TM4C123G LaunchPad highlights the TM4C123GH6PM microcontroller with a USB 2.0 device interface and hibernation module.
The EK-TM4C123GXL also features programmable user buttons and an RGB LED for custom applications. The stackable headers of the TM4C123G LaunchPad BoosterPack™ XL Interface make it easy and simple to expand the functionality of the TM4C123G LaunchPad when interfacing to other peripherals with Texas Instruments MCU BoosterPack.
Features
The ARM Cortex-M4F Based MCU TM4C123G LaunchPad Evaluation Kit (EK-TM4C123GXL) offers these features:
- High Performance TM4C123GH6PM MCU:
- 80MHz 32-bit ARM Cortex-M4F CPU
- 256KB Flash, 32KB SRAM, 2KB EEPROM
- Two Controller Area Network (CAN) modules
- Dual 12-bit 2MSPS ADCs, motion control PWMs
- 8 UART, 6 I2C, 4 SPI
- On-board In-Circuit Debug Interface (ICDI)
- USB Micro-B plug to USB-A plug cable
- Preloaded RGB quick-start application
- Tiva C Series TM4C123G LaunchPad -- Readme First
Tiva C Series TM4C123G LaunchPad Evaluation Board
Switch and LED interface
- PC0-PC3 is used for JTAG connections to the debugger on the LaunchPad.
- The LaunchPad connects PB6 to PD0, and PB7 to PD1.
- If you wish to use both PB6 and PD0 you will need to remove the R9 resistor.
- Similarly, to use both PB7 and PD1 remove the R10 resistor
GPIO Pin | Pin Function | USB Device |
---|---|---|
PF4 | GPIO | SW1 |
PF0 | GPIO | SW2 |
PF1 | GPIO | RGB LED (RED) |
PF2 | GPIO | RGB LED (BLUE) |
PF3 | GPIO | RGB LED (GREEN) |
PC0 | TCK/SWCLK | ICDI |
PC1 | TMS/SWDIO | ICDI |
PC2 | TDI | ICDI |
PC3 | TDO/SWO | ICDI |
PA0 | U0RX | Virtual COM P0rt (RxD) |
PA1 | U0TX | Virtual COM Port (TxD) |
Interface connectors
Pin | J1 | J3 | J4 | J2 | |
---|---|---|---|---|---|
1 | 3.3V | 5V | PF2 | GND | |
2 | PB5 | GND | PF3 | PB2 | |
3 | PB0 | PD0 | PB3 | PE0 | |
4 | PB1 | PD1 | PC4 | PF0 | |
5 | PE4 | PD2 | PC5 | RESET | |
6 | PE5 | PD3 | PC6 | PB7 | |
7 | PB4 | PE1 | PC7 | PB6 | |
8 | PA5 | PE2 | PD6 | PA4 | |
9 | PA6 | PE3 | PD7 | PA3 | |
10 | PA7 | PF1 | PF4 | PA2 |
References
Hardware Setup
Kit Contents
You should find the following in your box:
- The TM4C123GXL LaunchPad Board
- USB cable (A-male to micro-B-male)
- README First card
Connecting the board
The TM4C123GXL LaunchPad Board ICDI USB port (marked DEBUG and shown in the picture below) is a composite USB port and consists of three connections:
- Stellaris ICDI JTAG/SWD Interface - debugger connection
- Stellaris ICDI DFU Device - firmware update connection
- Stellaris Virtual Serial Port - a serial data connection
Using the included USB cable,
- connect the USB emulation connector on your evaluation board (marked DEBUG) to a free USB port on your PC.
- A PC’s USB port is capable of sourcing up to 500 mA for each attached device, which is sufficient for the evaluation board.
- If connecting the board through a USB hub, it must be a powered hub.
- The drivers should install automatically.
Make sure that the power switch in the upper left hand corner of your board is in the right-hand DEBUG position as shown:
Start
- Switch the POWER SELECT switch to the right for DEBUG mode.
- Connect the USB-A cable plug to an available port on the PC and the Micro-B plug to the Debug USB port on the Board.
- Verify that the POWER LED D4 on the board is lit.
Objective
In this lab, we’ll create a project that contains two source files, main.c and tm4c123gh6pm_startup_ccs_gcc.c, which contain the code to blink an LED on your LaunchPad board. The purpose of this lab is to practice creating projects and getting to know the look and feel of Code Composer Studio. In later labs we’ll examine the code in more detail. So far now, don’t worry about the C code we’ll be using in this lab.
► Create a New CCS Project
► Review the CCS GUI
► Add Path and Build Variables
► Add files to your project
► Add the INCLUDE search paths for the header files
► Examine Project Explorer
► Build your project and fix any errors
► Debug Configuration
► Load, Debug, Run
► Create a variable at workspace level in CCS 6.1.x and above
Developing Cortex M3/M4 Applications Using Visual Studio Code
Visual Studio Code (VSCode) can be used to edit the source code, build the application and finally debug it.
Required Software Components
In contrast to fully integrated IDEs, setting up Visual Studio Code requires us to setup a number of software packages, which finally work together to build the complete development environment. The software packages can be split into three groups:
- VSCode and plugins
- ARM Build Tools (compiler etc.)
- Debug tools
- The packages can be installed in any order
- VSCode must be installed before VSCode plugins can be installed.
1. Visual Studio Code and Plugins
Visual Studio Code
We can look at VSCode as an intelligent text editor which provides an extensive framework to add functionality through plugins. VSCode includes a project explorer, which can show the contents of one or multiple folders as a workspace. There is more information on required plugins further down in this list.
Required Plugins
C/C++
This plugin offers many features to simplify editing of C/C++ code, including Syntax highlighting, Intellisense (finding definitions of symbols), auto-completion of keywords and identifier names, and marking syntax errors while typing. For more details, please refer the following documents:
- C/C++ for Visual Studio Code
- Using C++ on Linux in VSCode
- Using GCC with MinGW
- Configure VSCode for Microsoft C++
Cortex-Debug
This plugin adds support for debugging ARM Cortex-M devices executable through a GDB Server.
- marus25.cortex-debug
- Cortex-Debug Overview
CMake
CMake Language Support for Visual Studio Code.
ARM
Syntax highlighting for ARM assembly code
Linker Script
Syntax highlighting for linker scripts
2. ARM Build Tools
GNU ARM Embedded Toolchain
GNU ARM Embedded Toolchain is the C/C++ compiler and linker along with additional tools. It is used to turn your source code into a binary executable.
CMake
CMake is a tool which turns compiler-independent project definitions into compiler-specific project definitions. CMake converts these into makefiles that can be processed by the GNU ARM Embedded Toolchain.
3. Debugger Tools
OpenOCD
OpenOCD is an open-source debugger, supporting a wide variety of JTAG hardware interfaces. For customers using a JTAG adapter other than the J-Link, this probably is the matching software. The package contains a GDB server, which connects to VSCode on one side, and to the J-Link JTAG/SWD hardware on the other side.
Chocolatey (The Package Manager For Windows)
The Windows versions of required software will be installed using Chocolately
- Launch Power shell as an administrator, then run the following command:
> Get-ExecutionPolicy
If it returns Restricted, then run the following command:
> Set-ExecutionPolicy Bypass -Scope Process -Force; [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor 3072; iex ((New-Object System.Net.WebClient).DownloadString('https://community.chocolatey.org/install.ps1'))
If you don't see any errors, you are ready to use Chocolatey! Type choco or choco -? now, or see following documents for more info:
- Install Chocolatey on windows 10
- Install package(s)
- upgrade package(s)
- Search for available packages
- Uninstall package(s)
Note: Always run Chocolatey (choco) under Windows Power Shell (as an administrator)
4. Install VSCode
Ubuntu
- Please follow this link to install Visual Studio Code Application.
- For more options, please refer to the Visual Studio Code setup page.
- You can also Download Visual Studio Code and install.
Windows
> choco install vscode
5. Installing Visual Studio Code Plugins
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
Or we can use in the IDE the menu View > Extensions.
- Open VSCode
- Select View → Extensions
- This will show the Extension sidebar
- In the search box above the Extension sidebar, type the Code name from the above table (without the angle brackets) or another reasonable search term
- Click on the little green Install button which appears next to the found plugin.
Below is our installed extensions (menu File > Preferences > Extensions):
6. Install Build Tools
Ubuntu
GNU Arm Embedded Toolchain
- Please follow this link to install GNU ARM Embedded Toolchain
- OR, we can install using apt
$ sudo apt update $ sudo apt install gcc-arm-none-eabi binutils-arm-none-eabi
Make and CMake
$ sudo apt update $ sudo apt install make cmake
Windows
GNU Arm Embedded Toolchain
> choco install gcc-arm-embedded
Make
> choco install make
CMake
> choco install cmake
7. Install Debugging Tools
OpenOCD
Ubuntu
$ sudo apt update $ sudo apt install openocd
Windows
> choco install openocd
Please refer following documents to know more about how to run OpenOCD:
- OpenOCD Ubuntu Package
- OpenOCD Config Files
- OpenOCD Config File Paths
- Running OpenOCD on Linux
- Running OpenOCD on Windows
- Accessing Devices without sudo
- Configuring Windows 7 for OpenOCD
Sample Project
You can download sample project from here
VSCode - Workspace and Project(s)
Similar to other IDEs, Visual Studio Code is using the concept of a ‘workspace’. In simple words, a workspace is a collection of Folders open in the IDE. See workspaces for more details. In the most simple case a workspace just contains a folder which is the folder for the project. So all what we need is to add a folder.
Use menu File > Add Folder to Workspace …
Browse to an existing new (empty) folder or simply create one from the dialog:
Add a new file: main.c
Implement the main function, then save it (CTRL+S)
Sample Project
You can download sample project from here
References
VSCode – Include Paths
This article will describe how to set up the Include Paths for C/C++ in Visual Studio Code to support ARM development. Visual Studio Code with the C/C++ plugin has many useful features while we are writing our code:
- syntax highlighting,
- error checking while we type, and
- automatic code completion, where it guesses while we type.
This can help us reduce errors and write faster. However, if the plugin is not correctly set up, these features will not work correctly or at all.
In order for Visual Studio Code and the C/C++ language plugin to understand our code, it needs to be able to find all of the header files referenced in our program. A header can further reference other headers, so they may be needed even if you didn’t explicitly call them yourself.
In main.c, VSCode is complaining that it cannot open tm4c123gh6pm.h' file'. The message is a little obscure, but it’s basically saying that it will interpret the file based on keywords and syntax, but can’t tell if things like function or variable names are correct.
So, how do we fix this? If the cursor is on the error, you will see the lightbulb to the left. Click that, and then Update “includePath” setting. VSCode will create and open a file called “c_cpp_properties.json”, in our project under a “.vscode” folder. By default this will contain configurations for Mac, Linux, and Win32. These include default includePaths suitable for desktop applications, but are not correct for ARM.
There are two sections with paths. The first, “includePath”, is where VSCode will look for headers for the purpose of checking our code. Unlike GCC, this is not recursive; we need to explicitly list each folder that contains headers that are referenced, directly or indirectly.
The second section with just “path” is used by IntelliSense to suggest things for us.
This is the initial c_cpp_properties.json file:
{ "configurations": [ { "name": "WIN32", "includePath": [ "${workspaceFolder}/**", "E:\\ti\\TivaWare_C_Series-2.2.0.295" ], "defines": [ "_DEBUG", "PART_TM4C123GH6PM" ], "compilerPath": "C:\\ProgramData\\chocolatey\\bin\\arm-none-eabi-gcc", "cStandard": "c99", "cppStandard": "gnu++17", "intelliSenseMode": "gcc-arm", "configurationProvider": "ms-vscode.cmake-tools" }, { "name": "LINUX", "includePath": [ "${workspaceFolder}/**", "/home/jshankar/ti/TivaWare_C_Series-2.2.0.295" ], "defines": [ "_DEBUG", "PART_TM4C123GH6PM" ], "compilerPath": "/opt/toolchains/gcc-arm-none-eabi-10.3-2021.10/bin/arm-none-eabi-gcc", "cStandard": "c99", "cppStandard": "gnu++17", "intelliSenseMode": "gcc-arm", "configurationProvider": "ms-vscode.cmake-tools" } ], "version": 4 }
- name: arbitrary name for the configuration
- includePath: list here all locations where IntelliSense shall search for header files. It automatically will use the ones located in the toolchain (compiler) installation. The ‘**’ notation means it will search recursively that folder
- defines: list all the extra defines which shall be considered.
- forcedInclude: if using the -include compiler option, make sure you list that file here
- compilerPath: path to the compiler executable.
- cStandard and cppStandard: the C and C++ standard to be used
- intelliSenseMode: mode to be used. ‘gcc-arm’ is considered legacy, but not sure what to use otherwise for ARM?
But where is stdint.h? GCC has built-in include paths that are used even if compiler flags don’t specify them. GCC will list the defaults by running “arm-none-eabi-gcc -xc -E -v -“, and add those paths as well. Be sure to list all sub folders with headers for the includePath section.
References
VSCode – Defines
It is common to pass defines to the compiler using flags at compile time.
-D_DEBUG -DPART_TM4C123GH6PM
Setting these for VSCode is simple: just add them to the “defines” section of c_cpp_properties.json, without the -D flag prefix:
"defines": [ "_DEBUG", "PART_TM4C123GH6PM" ],
If the include paths and defines are properly set up in Visual Studio Code, the C/C++ plugin should be able to properly parse our code, identify syntax errors, and will provide Intellisense code completion to improve the speed and accuracy of writing!
CMake: Configure
We are going to use CMake with Make to build the project. CMake needs some information where to find the tools. How does CMake know which compiler to use? It checks the CC and CXX environment variables. They define what is the default compiler in the system. If we manually set CC or CXX to different values, then CMake will use these new settings as default compilers. After successful detection, CMake stores info about the current toolchain in the following variables:
CMAKE_C_COMPILER, CMAKE_CXX_COMPILER
They contain paths to the C and C++ compilers respectively.
When we cross-compile to another platform, we have to specify completely different toolchain both in terms of name and location of the binaries. This can be done in two ways:
- pass values for the toolchain variables from the command line,
- specify toolchain file.
First option is very explicit thus easy to understand, but big number of arguments makes it harder to use CMake in terminal:
cmake .. -DCMAKE_C_COMPILER=<path_to_c_compiler> -DCMAKE_CXX_COMPILER=<path_to_cxx_compiler> -DCMAKE_AR=<path_to_ar> -DCMAKE_LINKER=<path_to_linker> etc...
Second option is more elegant and is the preferred way of choosing the toolchain. All we need to do is to put toolchain variables into a separate file (e.g. <toolchain_name>.cmake) and set CMAKE_TOOLCHAIN_FILE variable to the path of that file. This can be done both in the command line or in CMakeLists.txt before project() command:
cmake .. -DCMAKE_TOOLCHAIN_FILE=<path_to_toolchain_file>
OR
cmake_minimum_required(VERSION 3.15) set(CMAKE_TOOLCHAIN_FILE <path_to_toolchain_file>) project(<project_name> LANGUAGES C CXX)
Note: It is crucial to set the value of CMAKE_TOOLCHAIN_FILE before project() is invoked, because project() triggers toolchain detection and verification.
A simple and easy way is to to add the following file to the project. I have named it arm-toolchain.cmake and placed it in the project root folder.
CMake: Toolchain File
# File: arm-toolchain.cmake
# Toolchain file for arm-none-eabi-gcc
set(CMAKE_SYSTEM_NAME Generic)
set(CMAKE_SYSTEM_PROCESSOR ARM)
set(CMAKE_CROSSCOMPILING "TRUE")
# Set system depended extensions
if(WIN32)
set(ARM_TOOLCHAIN_EXT ".exe" )
else()
set(ARM_TOOLCHAIN_EXT "" )
endif()
if(WIN32)
set(ARM_TOOLCHAIN_DIR "C:/ProgramData/chocolatey/bin")
else()
set(ARM_TOOLCHAIN_DIR "/opt/toolchains/gcc-arm-none-eabi-10.3-2021.10/bin")
endif()
set(BINUTILS_PATH ${ARM_TOOLCHAIN_DIR})
set(TOOLCHAIN_PREFIX ${ARM_TOOLCHAIN_DIR}/arm-none-eabi-)
set(CMAKE_TRY_COMPILE_TARGET_TYPE STATIC_LIBRARY)
set(CMAKE_C_COMPILER "${TOOLCHAIN_PREFIX}gcc${ARM_TOOLCHAIN_EXT}")
set(CMAKE_ASM_COMPILER ${CMAKE_C_COMPILER})
set(CMAKE_CXX_COMPILER "${TOOLCHAIN_PREFIX}g++${ARM_TOOLCHAIN_EXT}")
set(CMAKE_OBJCOPY ${TOOLCHAIN_PREFIX}objcopy CACHE INTERNAL "objcopy tool")
set(CMAKE_SIZE_UTIL ${TOOLCHAIN_PREFIX}size CACHE INTERNAL "size tool")
set(CMAKE_FIND_ROOT_PATH ${BINUTILS_PATH})
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
ARM_TOOLCHAIN_DIR specifies the compiler to be used. Additionally it defines extra tools as size and objcopy.
CMake: CMakeLists.txt
To tell CMake what to do, create a file named CMakeList.txt in the project root.
# File: CMakeList.txt
# CMake file for tm4c123gxl
cmake_minimum_required(VERSION 3.15.3)
# Optional: print out extra messages to see what is going on.
# Comment it to have less verbose messages
set(CMAKE_VERBOSE_MAKEFILE ON)
# Path to toolchain file. This one has to be before 'project()'
set(CMAKE_TOOLCHAIN_FILE ${CMAKE_SOURCE_DIR}/arm-toolchain.cmake)
# Setup project, output and linker file
project(blinky VERSION 0.1)
set(EXECUTABLE ${PROJECT_NAME}.elf)
set(LINKER_FILE ${CMAKE_SOURCE_DIR}/ld/tm4c123gh6pm.ld)
enable_language(C ASM)
set(CMAKE_C_STANDARD 99)
set(CMAKE_C_STANDARD_REQUIRED ON)
set(CMAKE_C_EXTENSIONS OFF)
# Optional: issue a message to be sure it uses the correct toolchain file.
message(STATUS "CMAKE_TOOLCHAIN_FILE is: ${CMAKE_TOOLCHAIN_FILE}")
# List of source files
set(SRC_FILES
src/main.c
src/tm4c_startup.c
inc/tm4c_startup.h
)
# Build the executable based on the source files
add_executable(${EXECUTABLE} ${SRC_FILES})
# List of compiler defines, prefix with -D compiler option
target_compile_definitions(${EXECUTABLE} PRIVATE -DPART_TM4C123GH6PM)
# List of include directories
target_include_directories(${EXECUTABLE} PRIVATE
src
inc
if(WIN32)
"E:/ti/TivaWare_C_Series-2.2.0.295"
else()
"/home/jshankar/ti/TivaWare_C_Series-2.2.0.295"
endif()
)
# Compiler options
target_compile_options(${EXECUTABLE} PRIVATE
-mcpu=cortex-m4
-mthumb
-mfpu=fpv4-sp-d16
-mfloat-abi=hard
-fdata-sections
-ffunction-sections
-Wall
-O0
-g3
)
# Linker options
target_link_options(${EXECUTABLE} PRIVATE
-T${LINKER_FILE}
-mcpu=cortex-m4
-mthumb
-mfpu=fpv4-sp-d16
-mfloat-abi=hard
-specs=nano.specs
-specs=nosys.specs
-lc
-lm
-Wl,-Map=${PROJECT_NAME}.map,--cref
-Wl,--gc-sections
-Xlinker -print-memory-usage -Xlinker
)
# Optional: Print executable size as part of the post build process
add_custom_command(TARGET ${EXECUTABLE}
POST_BUILD
COMMAND ${CMAKE_SIZE_UTIL} ${EXECUTABLE})
# Optional: Create hex, bin and S-Record files after the build
add_custom_command(TARGET ${EXECUTABLE}
POST_BUILD
COMMAND ${CMAKE_OBJCOPY} -O srec --srec-len=64 ${EXECUTABLE} ${PROJECT_NAME}.s19
COMMAND ${CMAKE_OBJCOPY} -O ihex ${EXECUTABLE} ${PROJECT_NAME}.hex
COMMAND ${CMAKE_OBJCOPY} -O binary ${EXECUTABLE} ${PROJECT_NAME}.bin)
The most important sections/entries are:
- project(<your project name here>): Give your project a name
- set(LINKER_FILE <your linker file here>): specify the linker file name
- set(SRC_FILES <your source files here>): list of source files to compile
- target_compile_definitions(${EXECUTABLE} PRIVATE <compiler defines here>): list of compiler #defines
- target_include_directories(${EXECUTABLE} PRIVATE <list of include dir>): list of include directories
- target_compile_options(${EXECUTABLE} PRIVATE <compiler options>): list of compiler options
- target_link_options(${EXECUTABLE} PRIVATE <linker options>): list of linker options
This completes setting up the configuration for the build.
Configure
Next we are going to build it. Actually we need to ‘configure’ it first. With CMake it is a two stage process: running CMake to create (or configure) the make files and then we use ‘make’ to build it.
- Close VSCode and Restart again
- Open Command Palette ... (CTL+SHIFT+P)
- Select CMake:Delete cache and Reconfigure
CMake: Config Output
[variant] Loaded new set of variants [kit] Successfully loaded 3 kits from /home/jshankar/.local/share/CMakeTools/cmake-tools-kits.json [proc] Executing command: /opt/toolchains/gcc-arm-none-eabi-10.3-2021.10/bin/arm-none-eabi-gcc -v [cmakefileapi-driver] This version of CMake does not support the "toolchains" object kind. Compiler paths will be determined by reading CMakeCache.txt. [main] Configuring folder: blinky [proc] Executing command: /usr/bin/cmake --no-warn-unused-cli -DCMAKE_EXPORT_COMPILE_COMMANDS:BOOL=TRUE -DCMAKE_BUILD_TYPE:STRING=Debug -DCMAKE_C_COMPILER:FILEPATH=/opt/toolchains/gcc-arm-none-eabi-10.3-2021.10/bin/arm-none-eabi-gcc -DCMAKE_CXX_COMPILER:FILEPATH=/opt/toolchains/gcc-arm-none-eabi-10.3-2021.10/bin/arm-none-eabi-g++ -S/home/jshankar/codeprojects/tm4c123gxl/blinky -B/home/jshankar/codeprojects/tm4c123gxl/blinky/build -G "Unix Makefiles" [cmake] Not searching for unused variables given on the command line. [cmake] -- CMAKE_TOOLCHAIN_FILE is: /home/jshankar/codeprojects/tm4c123gxl/blinky/arm-toolchain.cmake [cmake] -- Configuring done [cmake] -- Generating done [cmake] -- Build files have been written to: /home/jshankar/codeprojects/tm4c123gxl/blinky/build
Build it with make
Open a terminal in the build output folder:
View-->Terminal
cd build make
Instead of calling ‘make’ inside the build folder, following can be used which does the one or the other:
cmake --build .
- The advantage of doing it this way is that if there has been a change in the CMakeList.txt it will run a configuration step first too.
- If doing changes in the structure: make sure you do a configure to make sure things are correctly set up.
Cleaning
A ‘clean’ is to delete all the files inside the build folder. But CMake has a ‘clean’ command too:
cd build cmake --build . --target clean make
To do a ‘clean followed by a build’ use the following:
cd build
cmake --build . --clean-first
Make: Build Output
/usr/bin/cmake -S/home/jshankar/codeprojects/tm4c123gxl/blinky -B/home/jshankar/codeprojects/tm4c123gxl/blinky/build --check-build-system CMakeFiles/Makefile.cmake 0 /usr/bin/cmake -E cmake_progress_start /home/jshankar/codeprojects/tm4c123gxl/blinky/build/CMakeFiles /home/jshankar/codeprojects/tm4c123gxl/blinky/build/CMakeFiles/progress.marks make -f CMakeFiles/Makefile2 all make[1]: Entering directory '/home/jshankar/codeprojects/tm4c123gxl/blinky/build' make -f CMakeFiles/blinky.elf.dir/build.make CMakeFiles/blinky.elf.dir/depend make[2]: Entering directory '/home/jshankar/codeprojects/tm4c123gxl/blinky/build' cd /home/jshankar/codeprojects/tm4c123gxl/blinky/build && /usr/bin/cmake -E cmake_depends "Unix Makefiles" /home/jshankar/codeprojects/tm4c123gxl/blinky /home/jshankar/codeprojects/tm4c123gxl/blinky /home/jshankar/codeprojects/tm4c123gxl/blinky/build /home/jshankar/codeprojects/tm4c123gxl/blinky/build /home/jshankar/codeprojects/tm4c123gxl/blinky/build/CMakeFiles/blinky.elf.dir/DependInfo.cmake --color= make[2]: Leaving directory '/home/jshankar/codeprojects/tm4c123gxl/blinky/build' make -f CMakeFiles/blinky.elf.dir/build.make CMakeFiles/blinky.elf.dir/build make[2]: Entering directory '/home/jshankar/codeprojects/tm4c123gxl/blinky/build' [ 33%] Building C object CMakeFiles/blinky.elf.dir/src/main.c.obj /opt/toolchains/gcc-arm-none-eabi-10.3-2021.10/bin/arm-none-eabi-gcc -DPART_TM4C123GH6PM -I/home/jshankar/codeprojects/tm4c123gxl/blinky/src -I/home/jshankar/codeprojects/tm4c123gxl/blinky/inc -I/home/jshankar/codeprojects/tm4c123gxl/blinky/if -I"/home/jshankar/codeprojects/tm4c123gxl/blinky/(" -I/home/jshankar/codeprojects/tm4c123gxl/blinky/WIN32 -I"/home/jshankar/codeprojects/tm4c123gxl/blinky/)" -I/home/jshankar/codeprojects/tm4c123gxl/blinky/E:/ti/TivaWare_C_Series-2.2.0.295 -I/home/jshankar/codeprojects/tm4c123gxl/blinky/else -I/home/jshankar/ti/TivaWare_C_Series-2.1.4.178 -I/home/jshankar/codeprojects/tm4c123gxl/blinky/endif -g -mcpu=cortex-m4 -mthumb -mfpu=fpv4-sp-d16 -mfloat-abi=hard -fdata-sections -ffunction-sections -Wall -O0 -g3 -std=c99 -o CMakeFiles/blinky.elf.dir/src/main.c.obj -c /home/jshankar/codeprojects/tm4c123gxl/blinky/src/main.c [ 66%] Building C object CMakeFiles/blinky.elf.dir/src/tm4c_startup.c.obj /opt/toolchains/gcc-arm-none-eabi-10.3-2021.10/bin/arm-none-eabi-gcc -DPART_TM4C123GH6PM -I/home/jshankar/codeprojects/tm4c123gxl/blinky/src -I/home/jshankar/codeprojects/tm4c123gxl/blinky/inc -I/home/jshankar/codeprojects/tm4c123gxl/blinky/if -I"/home/jshankar/codeprojects/tm4c123gxl/blinky/(" -I/home/jshankar/codeprojects/tm4c123gxl/blinky/WIN32 -I"/home/jshankar/codeprojects/tm4c123gxl/blinky/)" -I/home/jshankar/codeprojects/tm4c123gxl/blinky/E:/ti/TivaWare_C_Series-2.2.0.295 -I/home/jshankar/codeprojects/tm4c123gxl/blinky/else -I/home/jshankar/ti/TivaWare_C_Series-2.1.4.178 -I/home/jshankar/codeprojects/tm4c123gxl/blinky/endif -g -mcpu=cortex-m4 -mthumb -mfpu=fpv4-sp-d16 -mfloat-abi=hard -fdata-sections -ffunction-sections -Wall -O0 -g3 -std=c99 -o CMakeFiles/blinky.elf.dir/src/tm4c_startup.c.obj -c /home/jshankar/codeprojects/tm4c123gxl/blinky/src/tm4c_startup.c [100%] Linking C executable blinky.elf /usr/bin/cmake -E cmake_link_script CMakeFiles/blinky.elf.dir/link.txt --verbose=1 /opt/toolchains/gcc-arm-none-eabi-10.3-2021.10/bin/arm-none-eabi-gcc -g -T/home/jshankar/codeprojects/tm4c123gxl/blinky/ld/tm4c123gh6pm.ld -mcpu=cortex-m4 -mthumb -mfpu=fpv4-sp-d16 -mfloat-abi=hard -specs=nano.specs -specs=nosys.specs -lc -lm -Wl,-Map=blinky.map,--cref -Wl,--gc-sections -Xlinker -print-memory-usage CMakeFiles/blinky.elf.dir/src/main.c.obj CMakeFiles/blinky.elf.dir/src/tm4c_startup.c.obj -o blinky.elf Memory region Used Size Region Size %age Used FLASH: 980 B 256 KB 0.37% SRAM: 540 B 32 KB 1.65% /opt/toolchains/gcc-arm-none-eabi-10.3-2021.10/bin/arm-none-eabi-size blinky.elf text data bss dec hex filename 980 0 540 1520 5f0 blinky.elf /opt/toolchains/gcc-arm-none-eabi-10.3-2021.10/bin/arm-none-eabi-objcopy -O srec --srec-len=64 blinky.elf blinky.s19 /opt/toolchains/gcc-arm-none-eabi-10.3-2021.10/bin/arm-none-eabi-objcopy -O ihex blinky.elf blinky.hex /opt/toolchains/gcc-arm-none-eabi-10.3-2021.10/bin/arm-none-eabi-objcopy -O binary blinky.elf blinky.bin make[2]: Leaving directory '/home/jshankar/codeprojects/tm4c123gxl/blinky/build' [100%] Built target blinky.elf make[1]: Leaving directory '/home/jshankar/codeprojects/tm4c123gxl/blinky/build' /usr/bin/cmake -E cmake_progress_start /home/jshankar/codeprojects/tm4c123gxl/blinky/build/CMakeFiles 0
Sample Project
You can download sample project from here
References
VSCode Cortex-Debug Launch Configurations
Cortex-Debug is an extension for Visual Studio Code to streamline the debug process when working with ARM Cortex-M microcontrollers. This document covers writing launch configurations (launch.json).
- Open the VSCode user settings file settings.json: File → Preferences → Settings
- Select User settings:
- Enter "json" in the search bar (with or without double quotes). Locate a link "Edit in settings.json" and click on it. This will open the file ~/.config/Code/User/settings.json
- Add the following lines to the settings.json file, between the curly braces {}:
"cortex-debug.openocdPath": "/usr/bin/openocd", "cortex-debug.armToolchainPath.linux": "/opt/toolchains/gcc-arm- none-eabi-10.3-2021.10/bin", "cortex-debug.armToolchainPath.windows": "C:\\ProgramData\\chocolatey\\bin", "cortex-debug.gdbPath.linux": "/opt/toolchains/gcc-arm-none-eabi-10.3-2021.10/bin//arm-none-eabi-gdb", "cortex-debug.gdbPath.windows": "C:\\ProgramData\\chocolatey\\bin\\arm-none-eabi-gdb.exe"
Please note: The paths on your system might be different. Make sure the path matches your actual file locations.
- Save the file settings.json
Launch configurations
To run or debug a simple app in VS Code, we can select Run and Debug on the Debug start view or we can press F5 and VS Code will try to run the currently active file.
Creating a launch configuration file is beneficial because it allows us to configure and save debugging setup details. VSCode keeps debugging configuration information in a launch.json file located in a .vscode folder in the workspace (project root folder).
The launch.json file is used to configure the debugger in Visual Studio Code.
Parameters
Here is a list of parameters in launch.json. Configure them for your specific device and environment.
- cwd: Path of project
- configFiles: OpenOCD configuration file(s) to load
- device: Target Device Identifier
- interface: Debug Interface type to use for connections (defaults to SWD) - Used for J-Link and BMP probes.
- name: Name of configuration; appears in the launch configuration dropdown menu.
- preLaunchTask: Task to run before debug session starts. Specify a task defined in tasks.json.
- request: Request type of configuration. Can be “launch” or “attach”.
- runToEntryPoint: If enabled the debugger will run until start of the main function.
- serialNumber: J-Link specific parameter. J-Link Serial Number - only needed if multiple J-Links are connected to the computer
- servertype: GDB Server type - supported types are jlink, openocd, pyocd, pe and stutil
- svdFile: Path to an SVD file describing the peripherals of the microcontroller; if not supplied then one may be selected based upon the ‘device’ entered. This may be automatically loaded depending on the "device".
- swoConfig: SWO/ITM configuration.
- enabled: Enable SWO decoding.
- cpuFrequency: Target CPU frequency in Hz.
- swoFrequency: SWO frequency in Hz.
- source: Source for SWO data. Can either be “probe” to get directly from debug probe, or a serial port device to use a serial port external to the debug probe.
- decoders: SWO Decoder Configuration
- label: A label for the output window.
- port: ITM Port Number
OpenOCD Specific Configuration
- configFiles
- OpenOCD configuration files to use when debugging. Exactly equivalent to the OpenOCD command line argument -f.
- searchDir
- Directories to search for configuration files in. Exactly equivalent to the OpenOCD command line argument -s. If no search directories are specified, it defaults to the configured cwd.
- openOCDPreConfigLaunchCommands
- OpenOCD commands to run prior to loading configuration files.
- openOCDLaunchCommands
- OpenOCD commands to run in order to launch target.
OpenOCD GDB Server
We modify launch.json to configure debug features.
Below is an example of a basic launch configuration using the OpenOCD GDB server.
In this configuration the device parameter is not required - but can be supplied to allow auto-selecting an appropriate SVD file if possible.
There is one OpenOCD specific parameter that must be supplied. The configFiles property takes an arrays of strings that are used to load openocd configuration files. These can either be a files in the openocd search path (like in this example), or a full path to your own configuration file. If you are using OpenOCD supplied files you typically will have either one file from the board section, or a file from the interface section and a file from the target section.
- Open the VSCode launch configuration file launch.json: Run → Add Configuration...
- Copy the following code
{ "version": "0.2.0", "configurations": [ { "name": "Debug (OpenOCD)", "cwd": "${workspaceRoot}", "executable": "${workspaceRoot}/build/blinky.elf", "request": "launch", "type": "cortex-debug", "servertype": "openocd", "interface": "swd", "device": "TM4C123GH6PM", "runToEntryPoint": "main", "svdFile": "${workspaceRoot}/svd/TM4C123GH6PM.svd", "configFiles": [ "board/ek-tm4c123gxl.cfg" ], "preLaunchCommands": [ "set mem inaccessible-by-default off", "monitor reset" ], "postLaunchCommands": [ "monitor reset init", "monitor sleep 200" ] } ] }
- Change "executable", "svdFile", and "device" parameter as appropriate and save it
- SVD Files: The “svdFile” entry in the launch.json file is optional, but crucial to embedded system debugging because it describes the device peripheral registers.
References
Coretex-Debug
OpenOCD
VSCode Cortex Debugging
Use F5 or the menu Run > Start Debugging to start a debug session:
This starts debug session. In case of troubles, check the Debug Console:
Debug Console Output
Launching GDB: /opt/toolchains/gcc-arm-none-eabi-10.3-2021.10/bin//arm-none-eabi-gdb -q --interpreter=mi2 /home/jshankar/codeprojects/tm4c123gxl/blinky/build/blinky.elf Set "showDevDebugOutput": true in your "launch.json" to see verbose GDB transactions here. Helpful to debug issues or report problems Reading symbols from /home/jshankar/codeprojects/tm4c123gxl/blinky/build/blinky.elf... Launching gdb-server: /usr/bin/openocd -c "gdb_port 50000" -c "tcl_port 50001" -c "telnet_port 50002" -s /home/jshankar/codeprojects/tm4c123gxl/blinky -f /home/jshankar/.vscode/extensions/marus25.cortex-debug-1.2.0/support/openocd-helpers.tcl -f board/ek-tm4c123gxl.cfg Please check TERMINAL tab (gdb-server) for output from /usr/bin/openocd 0x00000000 in g_pfnVectors () Program stopped, probably due to a reset and/or halt issued by debugger 2 adapter speed: RCLK - adaptive target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000354 msp: 0x2000021c adapter speed: RCLK - adaptive target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000354 msp: 0x2000021c adapter speed: RCLK - adaptive target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000354 msp: 0x2000021c Note: automatically using hardware breakpoints for read-only addresses. Temporary breakpoint 1, main () at /home/jshankar/codeprojects/tm4c123gxl/blinky/src/main.c:16 16 SYSCTL_RCGC2_R |= 0x00000020;
By default there are several debug views available. With the .svd file, we have access to the peripheral register too:
Debug Commands
There are the usual debug commands (continue, stepping, restart) plus a run and debug toolbar
- Continue / Pause F5
- Step Over F10
- Step Into F11
- Step Out Shift+F11
- Restart Ctrl+Shift+F5
- Stop Shift+F5
Assembly Stepping
Press CTRL+SHIFT+P to invoke command palette. Then Select Cortex-Debug:View Disassembly(Functon), type the function name you want to disassemble.
0x000002ac: 80 b5 push {r7, lr}
0x000002ae: 00 af add r7, sp, #0
0x000002b0: 0e 4b ldr r3, [pc, #56] ; (0x2ec <main+64>)
0x000002b2: 1b 68 ldr r3, [r3, #0]
0x000002b4: 0d 4a ldr r2, [pc, #52] ; (0x2ec <main+64>)
0x000002b6: 43 f0 20 03 orr.w r3, r3, #32
0x000002ba: 13 60 str r3, [r2, #0]
0x000002bc: 0c 4b ldr r3, [pc, #48] ; (0x2f0 <main+68>)
0x000002be: 0e 22 movs r2, #14
0x000002c0: 1a 60 str r2, [r3, #0]
0x000002c2: 0c 4b ldr r3, [pc, #48] ; (0x2f4 <main+72>)
0x000002c4: 0e 22 movs r2, #14
0x000002c6: 1a 60 str r2, [r3, #0]
0x000002c8: 0b 4b ldr r3, [pc, #44] ; (0x2f8 <main+76>)
0x000002ca: 0e 22 movs r2, #14
0x000002cc: 1a 60 str r2, [r3, #0]
0x000002ce: 4f f4 fa 70 mov.w r0, #500 ; 0x1f4
0x000002d2: 00 f0 13 f8 bl 0x2fc <delayMs>
0x000002d6: 08 4b ldr r3, [pc, #32] ; (0x2f8 <main+76>)
0x000002d8: 1b 68 ldr r3, [r3, #0]
0x000002da: 07 4a ldr r2, [pc, #28] ; (0x2f8 <main+76>)
0x000002dc: 03 f0 f1 03 and.w r3, r3, #241 ; 0xf1
0x000002e0: 13 60 str r3, [r2, #0]
0x000002e2: 4f f4 fa 70 mov.w r0, #500 ; 0x1f4
0x000002e6: 00 f0 09 f8 bl 0x2fc <delayMs>
0x000002ea: ed e7 b.n 0x2c8 <main+28>
0x000002ec: 08 e1 b.n 0x500
0x000002ee: 0f 40 ands r7, r1
0x000002f0: 00 54 strb r0, [r0, r0]
0x000002f2: 02 40 ands r2, r0
0x000002f4: 1c 55 strb r4, [r3, r4]
0x000002f6: 02 40 ands r2, r0
0x000002f8: fc 53 strh r4, [r7, r7]
0x000002fa: 02 40 ands r2, r0
It is possible to set breakpoints in the assembly code, but one cannot see high level (C/C++) side-by-side with the assembly code. And the disassembly view does not show any more information or symbolic as the Eclipse CDT disassembly view does.
Memory
To view memory, use the Command Palette (CTRL+SHIFT+P) with Cortex-Debug:View Memory.
Then specify the expression for the memory location and a length.