Atollic TrueSTUDIO For STM32 User Guide PDF
Atollic TrueSTUDIO For STM32 User Guide PDF
User Guide
Quick Start Guide
Document Data
COPYRIGHT
© Copyright 2009-2018 STMicroelectronics. All rights reserved. No part of this document may be
reproduced or distributed without prior written consent of STMicroelectronics. The software
product described in this document is furnished under a license and may only be used, or copied,
according to the license terms.
TRADEMARKS
Atollic, Atollic TrueSTUDIO, Atollic TrueSTORE and the Atollic logotype are trademarks, or registered
trademarks, owned by STMicroelectronics. ARM, ARM7, ARM9 and Cortex are trademarks, or
registered trademarks, of ARM Limited. ECLIPSE is a registered trademark of the Eclipse foundation.
Microsoft, Windows, Word, Excel and PowerPoint are registered trademarks of Microsoft
Corporation. Adobe and Acrobat are registered trademarks of Adobe Systems Incorporated. All other
product names are trademarks, or registered trademarks, of their respective owners.
DISCLAIMER
The information in this document is subject to change without notice and does not represent a
commitment of STMicroelectronics. The information contained in this document is assumed to be
accurate, but STMicroelectronics assumes no responsibility for any errors or omissions. In no event
shall STMicroelectronics, its employees, its contractors, or the authors of this document be liable for
any type of damage, losses, costs, charges, claims, demands, claim for lost profits, fees, or expenses
of any nature or kind.
DOCUMENT IDENTIFICATION
TS-UG November 2012
REVISION HISTORY
20th January 2018 – Applies to Atollic TrueSTUDIO® for STM32 v9.0.0
21th August 2018 – Applies to Atollic TrueSTUDIO® for STM32 v9.1.0
Email: [email protected]
Web: www.atollic.com
ii | P a g e
Table of Contents
Contents
About this Document ............................................................. 29
Intended Readers ..................................................................................... 29
Document Conventions ........................................................................... 30
Getting Started .................................................... 31
Introduction .............................................................................................. 32
Preparing for Start .................................................................................... 33
Workspaces & Projects ................................................................................... 33
Perspectives & Views ...................................................................................... 34
Views ................................................................................................ 36
Starting the Program ................................................................................ 39
Starting With Different Language ................................................................... 41
Change What is Started................................................................................... 42
Creating a New Project ............................................................................. 43
One-Click Example Project Installation ........................................................... 54
Using an Existing Project ................................................................................. 55
Prevent “GCC not found in PATH” Error ......................................................... 56
Creating a Static Library .................................................................................. 56
Hide Information in a Static Library ................................................................ 57
Creating a Makefile Project From Existing Code ............................................. 58
Importing EWARM Projects ...................................................................... 61
Using the Project Import Converter ................................................................ 61
Import Projects from Folder or Archive .......................................................... 61
Before Building Imported Project ................................................................... 67
Step-by-step checklist ..................................................................................... 68
Common Build Errors ...................................................................................... 72
Configuring the Debugger ............................................................................... 72
Importing AC6 Projects............................................................................. 75
iii | P a g e
Table of Contents
iv | P a g e
Table of Contents
v|Page
Table of Contents
vi | P a g e
Table of Contents
Debugging ..........................................................215
Introduction to Debugging with TrueSTUDIO ........................................ 216
Starting the Debugger ............................................................................ 218
External GDB Server ...................................................................................... 224
JTAG Scan Chain ............................................................................................ 225
The Startup Script ................................................................................... 227
Start Debugging at the Very Beginning .......................................... 227
Load the Program Without Debugging .......................................... 227
Hardware Initialization Code ......................................................... 227
Managing the Debug Configurations ..................................................... 228
Generic Binary Path....................................................................................... 229
vii | P a g e
Table of Contents
viii | P a g e
Table of Contents
ix | P a g e
Table of Contents
Instruction Tracing..............................................313
Instruction Tracing.................................................................................. 314
Cortex-M7 and ETMv4 .................................................................................. 314
Enable Trace .................................................................................................. 315
Writing a Trace Port Configuration File ......................................... 316
Configuring the Tracing Session .................................................................... 318
ETM Trace Port Configuration File Reference ............................................... 319
Add Trace Trigger .......................................................................................... 319
Add Trace Trigger in the Editor ...................................................... 321
Managing Trace Triggers ............................................................................... 321
Start Trace Recording .................................................................................... 322
Analyzing the Trace ....................................................................................... 322
x|Page
Table of Contents
xi | P a g e
Table of Contents
xii | P a g e
Table of Contents
xiii | P a g e
Table of Contents
xiv | P a g e
List of Figures
Figures
Figure 1 - Workspaces and Projects ............................................................. 34
Figure 2 – Editing Perspective ...................................................................... 35
Figure 3 - Switch Perspective ....................................................................... 36
Figure 4 - Switch Perspective ....................................................................... 36
Figure 5 – Toolbar Buttons for Perspectives and Views .............................. 36
Figure 6 - View Menu toolbar button .......................................................... 37
Figure 7 - Show View Dialog Box .................................................................. 38
Figure 8 – Toolbar Buttons for Perspectives and Views .............................. 38
Figure 9 - Workspace Launcher .................................................................... 39
Figure 10 - Information Center .................................................................... 40
Figure 11 – Information Center Menu Command ....................................... 41
Figure 12 – Information Center Toolbar Button (A)..................................... 41
Figure 13 – Startup Preferences................................................................... 42
Figure 14 – Project Creation Buttons ........................................................... 43
Figure 15 - Starting the Project Wizard ........................................................ 43
Figure 16 - C Project Configuration .............................................................. 44
Figure 17 - C Project Configuration .............................................................. 45
Figure 18 - TrueSTUDIO Hardware Configuration ........................................ 46
Figure 19 - TrueSTUDIO Project Wizard Using Search Field......................... 47
Figure 20 – TrueSTUDIO Filter Board/Microcontroller ................................ 48
Figure 21 - TrueSTUDIO Hardware Configuration ........................................ 49
Figure 22 - TrueSTUDIO Software Configuration ......................................... 50
Figure 23 - TrueSTUDIO Debugger Configuration ........................................ 51
Figure 24 - Select Configurations ................................................................. 52
Figure 25 - Project Explorer View ................................................................. 53
Figure 26 – Editor View ................................................................................ 53
Figure 27 – Project Creation Buttons ........................................................... 54
igure 28 – Atollic TrueSTORE ........................................................................ 54
Figure 29 – Selection of Existing Project File ............................................... 55
Figure 30 – Selection of Static Library Project ............................................. 56
Figure 31 – Examples of options to be used with objcopy ...................... 58
Figure 32 – Create a Makefile Project from existing code ........................... 58
Figure 33 – Locate the code and select <none> .......................................... 59
Figure 34 – Edit the PATH variable ............................................................... 59
xv | P a g e
List of Figures
xvi | P a g e
List of Figures
xvii | P a g e
List of Figures
xviii | P a g e
List of Figures
xix | P a g e
List of Figures
xx | P a g e
List of Figures
xxi | P a g e
List of Figures
xxii | P a g e
List of Figures
xxiii | P a g e
List of Figures
xxiv | P a g e
List of Figures
xxv | P a g e
List of Tables
Tables
Table 1 – Typographic Conventions ............................................................. 30
Table 2 - EWARM vs TrueSTUDIO build options .......................................... 68
Table 3 – Memory Regions Usage Color .................................................... 266
Table 4 – Memory Details .......................................................................... 267
Table 5 – Static Stack Analyzer List tab ...................................................... 279
Table 6 – Static Stack Analyzer Call Graph tab ........................................... 280
Table 7 – Exception Data Columns ............................................................. 299
Table 8 – Exception Statistics Columns ...................................................... 301
Table 9 – MTB Trace Log View Columns .................................................... 310
Table 10 – embOS System Variables .......................................................... 330
Table 11 – embOS Task Parameters........................................................... 331
Table 12 – embOS Timer Parameters ........................................................ 332
Table 13 – embOS Resource Semaphore Parameters ............................... 333
Table 14 – embOS Mailbox Parameters ..................................................... 334
Table 15 – eTaskSync Task Parameters ...................................................... 336
Table 16 – FreeRTOS Task Parameters....................................................... 340
Table 17 – FreeRTOS Queue Parameters ................................................... 341
Table 18 – FreeRTOS Semaphore Parameters ........................................... 342
Table 19 – FreeRTOS Timer Parameters .................................................... 343
Table 20 – RTXC Kernel Information .......................................................... 345
Table 21 – RTXC Task List Parameters........................................................ 347
Table 22 – RTXC Stack Info ......................................................................... 347
Table 23 – RTXC Alarm Parameters ........................................................... 348
Table 24 – RTXC Counter Parameters ........................................................ 349
Table 25 – RTXC Event Source Parameters ................................................ 350
Table 26 – RTXC Exception Backtrace Parameters .................................... 351
Table 27 – RTXC Exception Parameters ..................................................... 352
Table 28 – RTXC Mailbox Parameters ........................................................ 352
Table 29 – RTXC Mutex Parameters ........................................................... 354
Table 30 – RTXC Partition Parameters ....................................................... 355
Table 31 – RTXC Pipe Parameters .............................................................. 356
Table 32 – RTXC Queue Parameters .......................................................... 357
Table 33 – RTXC Semaphore Parameters................................................... 358
Table 34 – ThreadX Thread Parameters..................................................... 361
xxvi | P a g e
Overview
xxvii | P a g e
Overview
Table 72 - Code Review Table View Toolbar Button Description .............. 411
Table 73 – The Code Review Editor View Toolbar Button Description...... 412
Table 74 – Revision History ........................................................................ 421
xxviii | P a g e
Introduction
INTENDED READERS
This document is primarily intended for users of Atollic TrueSTUDIO®.
Please note that this manual applies to users of STM32 target devices only.
29 | P a g e
Introduction
DOCUMENT CONVENTIONS
The text in this document is formatted to ease understanding and provide clear and
structured information on the topics covered. The following typographic conventions
apply:
Style Use
Identifies a Caution.
30 | P a g e
Introduction
GETTING STARTED
This section provides information on how to begin using Atollic TrueSTUDIO® for STM32.
Introduction
Debugging
31 | P a g e
Getting Started
INTRODUCTION
Welcome to Atollic® TrueSTUDIO® for STM32. The product is available for free. Advanced
functionality which earlier required a license is now fully enabled directly after installation.
Project Management
o Build/Memory Analyzer
o Stack Analyzer
o Bug Tracking
o Version Control
Debug
o Statistical Profiling
o RTOS-aware Debug
32 | P a g e
Getting Started
A single computer may hold several workspaces at various locations in the file
system. Each workspace may contain many projects.
The user may switch between workspaces, but only one workspace can be active
at any one time.
The user may access any project within the active workspace. Projects located in
another workspace cannot be accessed, unless the user switches to that
workspace.
Switching workspace is a quick way of shifting from one set of projects to another
set of projects. It will trigger a quick restart of the product.
33 | P a g e
Getting Started
Atollic TrueSTUDIO®
Debugging
Version Control
Code Review
As an example, the C/C++ Editing perspective displays views that relate to code editing,
such as Editor Outline and Class Browser. The Debug perspective displays views that relate
to Debugging, such as Breakpoints and CPU Registers.
34 | P a g e
Getting Started
Switching from one perspective to another is a quick way to hide some views and display
others.
As the figure below outlines, the idea is that one perspective shall be used for each work
task. It is however clear that one perspective, the C/C++ editing perspective is the
“master” perspective where developers spend most time. Therefor that perspective is the
center-point of Atollic TrueSTUDIO, and developers temporarily jump to other
perspectives to do other tasks, and when completed, jump back to the editing and building
perspective again.
The C/C++ Editing perspective is also the perspective that is opened when Atollic
TrueSTUDIO is started the first time.
Version
control
Editing
Debug
Building ...
We think it is valuable to use the editing and building perspective as the master
perspective, and all other perspectives used temporarily for other work tasks.
To switch perspective, select the Open Perspective toolbar button or use the menu
command View, Open Perspective:
35 | P a g e
Getting Started
Alternatively, click any of the perspective buttons in the top right corner of the main
window (only the last few ones active are displayed here):
One can always return to the default C/C++ Editing and Building perspective by clicking the
Return to editor and building perspective toolbar button (D). Editing and Building is the
main activity for most C/C++ developers, hence the dedicated button.
VIEWS
When Atollic TrueSTUDIO is started for the first time, the C/C++ Editing Perspective is
activated by default. This perspective does not show all available views by default, to
reduce information overload. The same principle applies to all perspectives.
36 | P a g e
Getting Started
To access additional features built into the product, open additional views. To do this,
select the View toolbar button (C) or use the menu command View:
The above list of views, while comprehensive, is still not complete. This list only contains
the most common views for the work task related to the currently selected Perspective. To
access even more views, select Other… from the list. This opens the Show View dialog box.
Double click on any view to open it and access the additional features:
37 | P a g e
Getting Started
Information Center (A) – Displays the initial welcome screen from the first time the
product was started, after being installed. More details will follow in “Starting the
Program” below.
38 | P a g e
Getting Started
6. Wait for the program to start, and the Workspace Launcher dialog to be
displayed.
This dialog enables the user to select the name and location of the Active
Workspace. The Active Workspace is a folder that will hold all projects
currently accessible by the user. The user may open any existing project in the
workspace. Any newly created projects will be stored in the workspace.
7. Enter the full name (with path) of the workspace folder to be used for the
current session. Alternatively, browse to an existing workspace folder, or use
the default workspace folder. This is located within the home directory of the
current user, e.g. C:\Users\User\Atollic\TrueSTUDIO
If the appointed workspace folder does not yet exist, it will be created.
39 | P a g e
Getting Started
The user must have write-access to the home directory to be able to start
Atollic TrueSTUDIO.
Atollic recommends that the Active Workspace folder is located not too
many levels below the file system root. This is to avoid exceeding the
Windows® path length character limitations. This can cause build errors if the
file paths become longer than Windows can handle.
40 | P a g e
Getting Started
Sometimes when opening an old workspace the Information Center does not
display valid information, e.g. “This page can’t be displayed” is shown or old
manuals are opened when accessing documents. In such case reload the
page by clicking the Home button, , at the top right corner of the
Information Center window.
This window enables the user to quickly reach information regarding the product, and how
to use it, by clicking on the corresponding hypertext links. It is not required to read all
material before using the product for the first time. Rather, it is recommended to consider
the Information Center as a collection of reference information to return to, whenever
required during development. When connected to internet also Atollic TruePERSPECTIVES
Blog articles can be reached.
The Information Center window may be reached at any time via the Help, Information
Center menu command or via the Information Center toolbar button.
9. Start using Atollic TrueSTUDIO by closing the Information Center page (click
the “X” in the Information Center page tab above its main window area). The
Information Center window is closed, but may be restored at any time, as
described above.
41 | P a g e
Getting Started
42 | P a g e
Getting Started
The toolbar has three buttons for quick creation of new projects.
43 | P a g e
Getting Started
Wait for the C Project configuration page to be displayed where different kind of
projects can be created. The Atollic TrueSTUDIO product contains two kind of
toolchains, an Atollic ARM Tools and a Atollic PC Tools. The Atollic ARM Tools
toolchain shall be used when building embedded projects. The Atollic PC Tools
toolchain is usable for testing code on the PC.
The project type CMSIS C/C++ Project requires some preparations before it
can be used. Please read the Using CMSIS-Pack in TrueSTUDIO section at
page 166 and Create CMSIS-Pack Based Projects at page 177.
44 | P a g e
Getting Started
45 | P a g e
Getting Started
46 | P a g e
Getting Started
To make the selection easier to find a specific board or microcontroller the Select
Hardware Settings dialog includes a Target Filter search field. When this field
contains some characters only Board/Microcontroller matching the text in the
filter field is selectable in the Board/Microcontroller fields. Enter some
characters in the Filter field to reduce the number of selectable
boards/microcontrollers.
For instance if you know the name of your Board/MCU contains “F446” then
enter F446 into the search field. This will limit the number of items which can be
selected and makes it much more easy to find the Board/MCU.
47 | P a g e
Getting Started
If the name of your board starts with “Disc” then just enter Disc into the search
field and only boards and devices containing Disc in the name will be listed.
The Info table in the Project Wizard displays Atollic TrueSTUDIO provided this
device. or CMSIS-Pack provided this device. The information depends on if the
project will be created based upon Atollic TrueSTUDIO Target Supported
Device information or if it will be based on installed CMSIS Pack files. See the
section Using CMSIS-Pack in TrueSTUDIO on page 166 for more information
about CMSIS-Pack.
48 | P a g e
Getting Started
The text field below the tree displays information about the used device when
a Board or MCU is selected in the tree.
49 | P a g e
Getting Started
The Mix HW/SW implementation is for those projects that have libraries that
aren’t compiled for hardware floating point. In this implementation the
function calls are not using the FPU-registers as in a pure Hardware
implementation. The FPU will however still be used inside the project
functions.
When finished, click the Next button.
Select the desired Runtime library to be used. For information about the
differences between Newlib–nano and the regular Newlib, please refer to
the Newlib-nano readme file, accessible from the Information Center (Figure
10).
If the target board has a limited amount of memory, the Use tiny
printf/sprinf/fprintf (small code size) setting is recommended.
When finished, click the Next button.
50 | P a g e
Getting Started
If Newlib-nano is used and float shall be used by scanf/printf add these options
to the “C Linker” options field
-u _scanf_float -u _printf_float
E.g. The option field line may now look like
-Wl,-cref,-u,Reset_Handler -u scanf_float -u_printf_float
Atollic TrueSTUDIO supports several different types of JTAG probes. Select the
probe to be used during debugging.
When finished, click the Next button.
51 | P a g e
Getting Started
52 | P a g e
Getting Started
6. Expand the project folder (“MyProject” in this example) and the src
subfolder in the Project Explorer view.
7. Double click on the main.c file in the Project Explorer tree to open the file
in the editor.
53 | P a g e
Getting Started
To find the examples relevant to a specific target board, select the Download button in the
toolbar (C in the image below).
54 | P a g e
Getting Started
Select the project(s) of interest and click Finish. The project is imported into the Active
Workspace and is immediately ready to be built and executed on the target board.
The whole process typically takes less than a minute.
Wait for Atollic TrueSTUDIO to start, as a result of double-clicking the .project file.
Please note that if the File Browser is configured not to display file extensions,
two nameless icons will appear in the file list, representing the .project and
the .cproject files. The use of files without a filename is an unfortunate
heritage from the ECLIPSE™ framework.
When clicking on the.project file the Project Import Converter will investigate the project
and if it is made for Atollic TrueSTUDIO it is directly imported. But if the project is made
from some other tool the Project Import Converter tries to identify if it is a known project
format and in such case will convert the project to an Atollic TrueSTUDIO project. There
are two sections which covers conversion of projects in this manual:
55 | P a g e
Getting Started
2. Open Project , Properties, C/C++ Build, Discovery Options and disable checkbox:
Automate discovery of paths and symbols.
Press Next and select the device to be used. This will make the project build settings
correct. The project will then be built as an archive file with the name lib{project-
name}.a, as for an instance libMyLibrary.a
56 | P a g e
Getting Started
If the library project should be recompiled at the same time as the project
that have included it, the library project should be added as a reference to
the other project. Select Project, Properties, C/C++ General, Paths and
Symbols and in References-tab select the library project.
For more information about Project referring, see Referring Project on page
119
The GNU Binary Utilities command line tools are needed to create an archive file from an
object file without first creating a library project.
For instance objcopy can be used if a library shall be exported and used by other people
and there is a need to hide information in the library such as function names or variables.
Below is an example on how to remove symbols and redefine some names in a library.
This will open library libTest, remove all symbols that are not needed for relocation
processing and will also redefine myfunc to aaaa, and create a new library libRenamed.
Option Information
57 | P a g e
Getting Started
--strip-unneeded Strip all symbols that are not needed for relocation processing.
--redefine-sym old=new Change the name of a symbol old, to new. This can be useful
when one is trying link two things together for which you
have no source, and there are name collisions.
The GNU Binary Utilities Manual contains complete information on how to use the
included Binary Utilities software.
Enter the name of the new project and the location of the existing code.
Make sure to select <none> as the Toolchain for the Indexer Settings.
58 | P a g e
Getting Started
Then add the path to the existing toolchain to the system PATH environment variable.
That can be done from within Atollic TrueSTUDIO by select Project, Properties and then
C/C++ Build, Environment.
Locate the PATH variable in the list, select it and click Edit. If PATH can’t be located, click
Add and write PATH in the Name textbox.
59 | P a g e
Getting Started
In the Value textbox, add the full path to the location of the toolchain, and also any other
location from where any executables in the makefile are located. Separate the paths with
a “;”.
60 | P a g e
Getting Started
The Project Import Converter will not modify any source or project files for your original
EWARM project. It is however recommended that you backup or make a copy of the
original EWARM project since you most likely need to modify some of the source code
after the project has been imported to Atollic TrueSTUDIO.
It is always recommended to make backups of the project files and source code
before converting projects.
A log file is created in the project folder during import. The name of this log file is
ProjectName_converter.log. This log file is placed into the same folder as the
.project file and can be investigated to find information about the conversion. The
ProjectName_converter.log. can for instance contain the following info.
Project: STM32F4-Discovery
Converter: IARProjectParser
Date: 20170421
Please note! The imported project will not be copied to the workspace. All
files in the project will be located at the original place and will be overwritten
when manual changes are made.
61 | P a g e
Getting Started
In the Import wizard select Projects from Folder or Archive and press Next.
62 | P a g e
Getting Started
63 | P a g e
Getting Started
To see the Installed project configurators in the product, press the installed project
configurators link in the Import Projects from File System or Archive dialog.
In the Import Projects from File System or Archive dialog browse to the folder containing
the project to be imported.
64 | P a g e
Getting Started
Eclipse cannot handle two projects with the same name in a workspace.
Therefore it may only be possible to import one project for a board into the
workspace. If an attempt is made to import a second project with the same
name, the import will be cancelled silently without any specific message.
Remove the first project from the workspace or create a new workspace if
another project shall be tested.
Select the project and make sure the checkbox Detect and configure project natures is
enabled otherwise the Project Import Converter will not be used. Press Finish to import
the project.
The project is now imported into the workspace. Please note that files included in the
project are not copied to the workspace, instead all files are linked to the workspace. This
means that the actual files will be updated in the original EWARM project. Press OK to use
the imported project.
If a folder which contains several projects are selected and Search for nested projects are
selected several projects will be seen in the dialog.
65 | P a g e
Getting Started
Many projects can then be imported in one step using this method. However, as
mentioned earlier, Eclipse requires different names to be used for each selected project. If
you run into this problem you can either rename the original EWARM project(s), or import
them into different Atollic TrueSTUDIO Workspaces.
66 | P a g e
Getting Started
Before we build we need to make some manual modifications to the source code and
make sure that the build options are set correctly. Below is a step-by-step list and we will
walk through this list and give examples on what typically needs to be done to get to a
project that builds in Atollic TrueSTUDIO.
For more detailed information on how to migrate EWARM code and build
options, please see the IAR to Atollic Migration Guide, sections 3 and 4.
You can access the IAR to Atollic Migration Guide from Atollic TrueSTUDIO
Information Center.
There are essentially four parts of the migration process that you need to manually
update. Review and modify build options, modify assembler source code, add a linker
script file and watch out for tool specific code. These steps are described below and will in
most cases lead to a project that builds and functions correctly.
Linker scripts, startup code and standard C/C++ libraries are tightly releated so
we must make sure to use either Atollic TrueSTUDIO or EWARM versions of
this code and scripts. It is strongly recommended to use Atollic TrueSTUDIO
versions since migrating all this from EWARM to Atollic TrueSTUDIO would be
very time consuming and prone to errors.
67 | P a g e
Getting Started
STEP-BY-STEP CHECKLIST
The following steps are necessary to double-check in order to obtain a successful build.
With one exception, all pre-defined symbols and search paths have already been
updated but you should make sure that options like FPU and C/C++ language
matches the original project. See table below for information on where to find
different build options.
The exception mentioned in the paragraph above is the CMSIS include path. In
EWARM you can specify to use CMSIS with the Use CMSIS option.
68 | P a g e
Getting Started
If Use CMSIS is checked then you will need to add a path to the CMSIS library to use in
your application. You can do this in the Directory part of the C Compiler settings. The path
to add is the absolute path the CMSIS/Include located in your EWARM installation,
typically something like this:
C:\Program Files (x86)\IAR Systems\Embedded Workbench x.x\arm\CMSIS\Include
In the Directory part of the C Compiler setting (see picture below), click the Add… icon ( )
to add your path.
69 | P a g e
Getting Started
A special case is the startup file that comes with most projects and usually are
written in assembler code. Atollic TrueSTUDIO can generate this startup file for
you so that you do not have to write this code yourself. A recommended way is
to add an. iar extension to the startup file that was added to your imported
EWARM project. After this you can add a Atollic TrueSTUDIO startup file based
on the same ARM device to your imported project. If you created a dummy
project as described in the tip above, then you can simply drag-and-drop the
startup file from your dummy project to your imported project.
Once we have our new startup file we can compare it against the original startup
file. We can ignore the C/C++ initialization code since we will be using Atollic
TrueSTUDIO standard libraries and we are using an Atollic TrueSTUDIO
generated startup file now. What we should pay attention to is for example the
content of vector table and exception/interrupt handlers. For example, interrupt
handlers that was implemented and used in the original project must also be
implemented in our new startup file.
If you have your dummy project as described above, then you can simply, in
Atollic TrueSTUDIO Project Explorer, drag-and-drop that linker script file into the
root of your imported project.
We need to let the linker know which linker script file to use and this is done in
the General Settings of the C++ Linker.
70 | P a g e
Getting Started
You can either Browse to the linker script file, or if it is located in the root of your
imported project, type in the path.
In our example, we use STM32F4 so that path would be then “../stm32f4_flash.ld”.
With the linker script file in place we need to make sure that the memory
configuration in the linker script matches the configuration in the IAR .icf-file. Usually
most memory segments do not have to be located at a specific address, as long as it is
in the correct memory region. There are however applications that require that some
memory regions and entry labels are located at an absolute address. In this case you
should make sure your new application locate these regions/labels at the same
memory location. See the IAR to Atollic Migration Guide for more details on how this
can be done in Atollic TrueSTUDIO.
4. The last step before we try our build is to see if there are tool specific code in our
project, other than the startup file mentioned above.
Applications and libraries that comes from silicon vendors or 3’rd party
companies can contain source code, or libraries, that are created just for a
specific development toolchain. If this is the case in your project, then you
should see if you can find that corresponding code for TrueSTUDIO or GCC and
replace source code, libraries and include paths with the versions created for
TrueSTUDIO or possible GCC.
Intrinsic functions are also part of code that can differ from tool vendor to tool
vendor. Luckily CMSIS defines a set of intrinsic functions used for Cortex-M and
both EWARM and Atollic TrueSTUDIO follow CMSIS. In order to make sure that
we include declarations of CMSIS we should include CMSIS cmsis_gcc.h
instead of EWARM intrinsics.h in our source code.
For information about none CMSIS intrinsic functions and other ARM language
extensions used by, see ARM® C Language Extensions and CMSIS Core
documentation.
71 | P a g e
Getting Started
You are now ready to build the newly imported project and correct any remaining error
and check warnings. Depending on your project there might be more things that you
manually would need to modify in order to get to a Atollic TrueSTUDIO project that
matches the original EWARM project. For this reason, and for those who would not use
the EWARM import wizard, there is an IAR to Atollic Migration Guide available from Atollic
TrueSTUDIO Information Center with detailed information on how migrate a project from
EWARM to Atollic TrueSTUDIO.
Here ‘xyz’ can be a variable or a function that used in your application but not defined.
One way to find where this missing variable/function should be defined is to find the
definition in the original EWARM project.
There is a chance that the missing function could be defined as an intrinsic function that is
not included in our core_cmFunc.h or cmsis_gcc.h header files.
Unresolved issues? If still not successful after reading the IAR to Atollic
Migration Guide, please contact your local distributor or Atollic support for
assistance.
72 | P a g e
Getting Started
same dialog will open if we attempt to start a debug session before we have created our
debug configuration.)
In the Main tab, we need to make sure that the Name of the ElfDwarf file is correct as well
as the Application and the Project selected.
After this is done we select the Debugger tab. Here we first of all select which Debug
probe we will be using. Once we have selected our debug probe we can modify our GDB
Connection, select debug interface, add trace (if we have that available) and more.
73 | P a g e
Getting Started
If you are uncertain on how to configure your debugger after selecting the
debug probe, then try the default vaules.
After you select a debug probe, Atollic TrueSTUDIO will default to a debug
configuration that works for most projects that use that particular debug
probe.
In case the default values does not work, check your debug settings in EWARM
and apply the same values to your debug configuration in Atollic TrueSTUDIO.
If you like to get more control over the download and debug session, then you can do this
in the Startup Scripts tab. Here you can add commands to for example load additional files
or debug information, chose to download without starting a debug session, stop at the
application entry point or run to main (or any global label in your application) and much
more. For more information see The Startup Script chapter at page 227.
Now we are ready to download and test our application and we can do this by clicking on
OK or Debug (depending on how you started the Debug Configuration dialog).
For more detailed information on migrating EWARM projects, see the IAR to Atollic
TrueSTUDIO migration guide.
74 | P a g e
Getting Started
The new Project Import Converter automatically updates System Workbench for STM32
(AC6, SW4STM32) projects to Atollic TrueSTUDIO format during import. After an import
the project shall build and it shall be possible to debug the project in Atollic TrueSTUDIO.
In some cases it may be needed to do some manual target or build setting changes.
The Project Import Converter makes it easy to import, build and debug ready-made
projects located in the STMicrolectronics STM32Cube Firmware Package projects even if
STMicrolelectronics only have prepared SW4STM32 projects in the examples package.
Example from STM32CubeF7:
G:ST\STM32Cube\en.stm32cubef7\STM32Cube_FW_F7_V1.5.0\Projects\STM32F
769I-
Discovery\Examples\DMA\DMA_FLASHToRAM\SW4STM32\STM32769I_DISCOVERY
The Project Import Converter will update the imported project but it will make backup
copies of the .project and .cproject files before these are changed. See the section
Restoring Converted Projects at page 82 for information on how to restore the project if it
shall be used with AC6 later.
During import a log file is created in the project folder. The name of this log file is
ProjectName_converter.log. This log file is placed into the same folder as the
.project file and can be investigated to find information about the conversion. The
ProjectName_converter.log. can for instance contain the following info. This is
normal behavior.
Project: STM32F4-Discovery
Converter: AC6 project converter
Date: 20170127
75 | P a g e
Getting Started
These two different ways of using the Project Import Converter is described in next
sections.
Please note! The imported project will not be copied to the workspace. All
files in the project will be located at the original place and will be overwritten
when changes are made.
76 | P a g e
Getting Started
In the Import wizard select Projects from Folder or Archive and press Next.
77 | P a g e
Getting Started
To see the Installed project configurators in the product press the installed project
configurators link in the Import Projects from File System or Archive dialog.
In the Import Projects from File System or Archive dialog browse to the folder containing
the project to be imported.
78 | P a g e
Getting Started
In the Import as column in the Import Projects from File System or Archive
dialog it displays TrueSTUDIO project or TrueSTUDIO project (Converted
from AC6) which informs how the project will be imported.
Do not try to import lines where no information is available in the Import as
column.
The Import as column may also display Folder already imported as project
and in such cases it will not be possible to import it again into current
workspace.
Some examples may use identical project names for projects aimed at
different boards. Eclipse cannot handle two ormore projects with the same
name in a workspace. Therefor, it may only be possible to import one project
for a board into the workspace. If an attempt to import a second project with
the same name is made, the import will be cancelled silently without any
specific message. To import a second project, remove the first project from
the workspace or create a new workspace.
Select the project and make sure the checkbox Detect and configure project natures is
enabled otherwise the Project Import Converter will not be used. Press Finish to import
the project.
The following dialog can be displayed if the Project Import Converter prepares to convert
the project.
The project is now imported into the workspace. Please note that files included in the
project are not copied to the workspace, instead all files are linked to the workspace. This
means that the actual files will be updated in the STM32Cube package in this case. Press
OK to use the imported project.
79 | P a g e
Getting Started
If a folder which contains several projects are selected and Search for nested projects are
selected several projects will be seen in the dialog.
Many projects can then be imported in one step using this method. However, as
mentioned earlier the STM32Cube examples uses the same project name for each board
and as Eclipse requires different names to be used only one of the selected project in such
case will be imported.
After double-click on .project file, Atollic TrueSTUDIO will be opened if it is not already
started, and the following dialog is displayed.
80 | P a g e
Getting Started
Press OK to convert the project and import it into the workspace and a new dialog is
opened after a successful conversion.
The project is now imported into the workspace. Press OK to use the imported project.
Please note that files included in the project are not copied to the workspace, instead all
files are linked to the workspace. This means that the actual files will be updated in the
STM32Cube package in this case.
Some examples may use identical project names for projects aimed at
different boards. Eclipse cannot handle two ormore projects with the same
name in a workspace. Therefor, it may only be possible to import one project
for a board into the workspace. If an attempt to import a second project with
the same name is made, the import will be cancelled silently without any
specific message. To import a second project, remove the first project from
the workspace or create a new workspace.
The first step to use the project in Atollic TrueSTUDIO could be to make a build and verify
that it builds without errors. After the project has been built a debug session can be
started.
First time a debug session is started the Debug Configurations dialog will be opened. Make
sure to configure to use correct Debug probe, e.g. ST-LINK or SEGGER J-LINK, and Interface
SWD or JTAG according to hardware requirements. If SWV shall be used then make sure to
set the Core Clock to the speed of the clock that will used by the target when debugging
the project.
81 | P a g e
Getting Started
When correct setting for debugging is set make sure the debugger probe and board is
connected and start a debug session by pressing the OK button.
One way to restore the project and use it with AC6 again is to replace these project files
with the original files. Open a command prompt and rename the files. (Note! The filename
can not be renamed using Windows File Explorer as this program does not allow to
rename a file to start with “.” .)
E.g. In a Command Prompt window use the move command to rename the files
1. Rename the converted projet files if you these files shall be kept.
move .project .project_ts
move.cproject .cproject_ts
2. Replace and use the original files
move .project_org .project
move.cproject_org .cproject
82 | P a g e
Getting Started
The project should now be ready to be opened with System Workbench for STM32 (AC6,
SW4STM32) again.
83 | P a g e
Getting Started
Managed Mode projects can be configured using dialog boxes. Unmanaged Mode projects
require a manually maintained makefile.
Atollic TrueSTUDIO provides extensive GUI controls for configuration of command line tool
options using a simple point-and-click mechanism.
4. Expand the C/C++ Build item in the tree in the left column. Then select the
Settings item to display the build Settings panel for the active Build
Configuration.
84 | P a g e
Getting Started
5. Select panels as desired and configure the command line tool options using
the GUI controls.
Advanced users may wish to enter command line options manually. This can be
done in the Miscellaneous panel for any tool.
85 | P a g e
Getting Started
6. Some project build settings are relevant for both Managed Mode projects
and Unmanaged Mode projects. For instance the selected microcontroller
or evaluation board may affect both the options to the compiler during a
Managed Mode build, and also how additional components in Atollic
TrueSTUDIO, for instance the SFR view, and debugger, will behave.
Project build settings relevant for both Managed Mode projects and
Unmanaged Mode projects are collected in the Target Settings panel.
86 | P a g e
Getting Started
Any changes made here will be reflected in ALL build configurations for this
project.
Changing to a different hardware target, will cause a new linker script file
(.ld) to be generated, with FLASH and RAM settings adjusted to the
memory size of the new target device. See Generate a New Linker Script,
page 131 for more information.
However, libraries, header files, etc. will not be generated automatically for
the new target! These must be added manually to the project.
87 | P a g e
Getting Started
7. Click the OK button to accept the new settings. This will change the
settings for the selected Build Configuration.
The Build Analyzer view can be used to analyse the size and location of a
program in detail. Please read more about the Build Analyzer at page 264
BUILD CONFIGURATIONS
A Build Configuration stores how a project is built. Each Build configuration has several
Build Settings. Each Build Setting can be individually set for each Build Configuration.
A Project can have an unlimited number of Build Configurations. This is a very powerful
tool to be able to quickly build a project in different ways, such as with different
optimization levels, tool chain versions and even different build behavior can be set. It is
even possible to have a project be built as both a library and an executable with two
different Build Configurations.
A project created in Atollic TrueSTUDIO contains by default two Build configurations, the
Debug and the Release configuration. In these configurations there are two build settings
that differentiate them. The Debug configuration is built with debugging information and
no optimization level. The Release configuration is optimized for small code size and with
no debugging information.
Settings done in the project will usually only affect the current configuration. However
what Build Configuration that is affected can be selected in the dropdown list located at
the top of the panel.
88 | P a g e
Getting Started
This does not change what Build Configuration is used when building. To change that the
Active Configuration needs to be changed, see Changing Active Build Configuration on
page 90.
When building is done, the build-result such as an .elf-file, is stored in a folder with the
same name as the Build Configuration. This makes it easy to locate. For this reason it is
also a good idea to not use white space in the name of a Build Configuration.
1. Select the project in the Project Explorer and right click Project, Manage Build
Configurations…
2. Optional - Delete the old Release configuration or the configuration that does not have
all the used settings
3. Click New…
4. Name the new configuration. E.g. NewRelease. It is recommended not to use any
whitespaces in the name of the Build Configuration.
6. Click OK.
7. Select the new NewRelease configuration and click Set Active. This determines what
Build Configuration is to be used when building the project.
Next, open up Project, Properties, and navigate to C/C++ Build, Settings, Tool Settings. In
the Debugging node, for the Assembler and C/C++ Compiler, set the debug level to none.
Then select an optimization level in the Optimization node for the C/C++ Compiler.
The build output folder will be named as the active build configuration. So when the
project is built, the .elf file will be located in the NewRelease folder for the new Release
configuration.
89 | P a g e
Getting Started
For another example see Create a New Build Configuration For an Old Toolchain Version on
page 101.
SOURCE FOLDERS
A folder within a project can be recognized as a source folder if it is annotated with a small
C-icon in the Project Explorer.
90 | P a g e
Getting Started
To make Atollic TrueSTUDIO handle an existing folder as a new source folder do the
following steps:
1. Select the project and in the top menu select Project, Properties.
2. In the Properties panel open C/C++ General, Paths and Symbols and then the Source
Location tab.
91 | P a g e
Getting Started
92 | P a g e
Getting Started
INCLUDE LIBRARIES
This guide is for including libraries into Atollic TrueSTUDIO projects. For information how
to refer to a library created in an existing project, see Referring Project on page 119. On
page 155 there is a guide for how to Update CMSIS Math library.
In order to include a library into a project right-click on the project where the library will
be included; select Properties, C/C++ Build and Settings. Then select the Tool Settings-tab,
select C Linker, Libraries.
93 | P a g e
Getting Started
3. In the Libraries list add the name of the library - not the path! The name is the
filename without “lib” prefix and without the file extension (.a). It is important
not to include those parts of the name. This is a GCC convention.
If by any chance the library’s name don’t confirm to the GCC convention, the full
name to the library can be entered, preceded by a colon “:”.
4. In the Library Paths list, set the path to where the library is located. Do not
include the name of the library in the path.
5. The source folder for the header files should also be added to the Include paths.
Do that by selecting Project, Properties, Tool Settings, C Compiler, Directories
and press the Add… button. Then add the path to the source folder for the
header files in the library.
94 | P a g e
Getting Started
Libraries added by include paths are considered static in that way that they
are provided by external parties. The .h files are not rescanned as the content
should not have changed for external header files.
If external libraries is to be treated as normal source folder, the folders must
also be added as source-folders to the project.
This is particularly important when using tools that generates external code,
such as STM32CubeMX
The included libraries can also be found by right-clicking the project and select C/C++
General and open the Libraries-tab and the Libraries Path-tab.
See Referring Project on page 119 for more information if a project is referring to another
project, a library or a normal project.
COMPILER SETTINGS
All the settings for the compiler can be found by open the Build Configuration with the
Build Settings Toolbar button.
Then select the Build Configuration that should be changed and the Tool Setting tab.
Select the C Compiler tool node.
The compilers command line command and options are then displayed.
95 | P a g e
Getting Started
The different nodes below the C Compiler can then be selected to configure how the
compiling is done. More about these options are found in the following pages in this
chapter.
The options can also be manually changed by editing the All options field.
More about all options are found in the Compiler manual found in the Information Center
as the C/C++ Compiler link.
See also section Add or Remove Folder to Include Path on page 153 for
information on an easy way to update the include path.
More information about compiler settings can be found in the Compiler manual. The
manual can be found from the Information Center view.
96 | P a g e
Getting Started
Read more about the status of the C99 implementation here http://gcc.gnu.org/gcc-
4.5/c99status.html.
Other C standards can also be set with the same drop down menu.
COMPILER OPTIMIZATION
The GNU C/C++ compiler (and hence Atollic TrueSTUDIO) have 6 levels of compiler
optimization; -O0 for no optimization up to -O3 for full optimization. There is one level for
size optimization (-Os) which is commonly required in embedded projects and another
level for speed optimization (-Ofast).
Also available is a level for turning on optimizations that won’t interfere with the debug
experience (-Og).
97 | P a g e
Getting Started
The optimization setting is per Build Configuration. Per default the Debug configuration is
optimized with –O0 and the Release configuration has -Os.
To define a specific optimization level on a block of code, use the optimize attribute on the
block:
However, because of the way this works also means that in order to use this feature fully it
is necessary to provide the linker tool with some extra information that usually has only
been supplied to the compiler tool. This extra information can be any optional extra flag
that you might have added to the compiler process.
98 | P a g e
Getting Started
In most cases however it will only be required to add the following flags to the Linker tool
Miscellaneous field
The optimization flag (-Os) should have the same value as the optimization flag for the
compiler, see page 93 for more information.
Please note! -g shall be used to get extra debug information needed when debugging the
program.
It is also required to change the Compiler tool settings and there add the –flto flag to the
miscellaneous field.
99 | P a g e
Getting Started
To change to an older version of the Atollic ARM Tools toolchain or the PC toolchain click
on the Build Settings toolbar button.
100 | P a g e
Getting Started
Default – This option will use the tool chain in the currently running installation of
TrueSTUDIO.
When working with a version control system in a team, the second option is
strongly recommended for a project. That way all developers will use the same
toolchain even if using different versions of Atollic TrueSTUDIO.
These setting are saved individually for each Project’s Build Configuration. That way it is
possible to have different Build Configurations using different toolchain versions. This way
a quick regression test can be created.
101 | P a g e
Getting Started
3. Enter a good name for the new Build Configuration. Use one word, such as
OldToolChain, without white space and press OK and OK again in the Manage
Configuration panel.
102 | P a g e
Getting Started
4. In the Toolchain Version tab it is now possible to set the Default version of the tool
chain for the normal Debug Build Configuration and a Fixed TrueSTUDIO version for
the OldToolChain Build Configuration.
Figure 78 – Old Tool Chain Version for the New Build Configuration
1. Open up Project, Properties, C/C++ Build, Settings, Tool Settings, Other, Output
format
2. Check the box Convert build output and choose a format in the dropdown menu.
103 | P a g e
Getting Started
The converted output will be located in the output directory associated with the currently
active Build Configuration, typically Debug/Release directory.
Other supported file formats are: Binary, Motorola S-record, Motorola S-record with
symbols, IAR Simple Code and Verilog Hex Dump.
To manually create .hex, .srec and .bin-files, add Post-build steps in the Build Step tab:
Conversion to the IAR Simple Code File Format can only be made using the
dropdown menu in Atollic TrueSTUDIO. The IAR Simple Code File Format can
not be generated with objcopy.
104 | P a g e
Getting Started
The assembler file will be located in the build output directory and will be called:
FILENAME.s
There will also be a FILENAME.i that is the preprocessed c-code. That is the code as it will
look after the preprocessor but before the code is compiled. If there might be a problem
with some #define then looking into this file is a good idea.
105 | P a g e
Getting Started
The Build result is displayed in the Console window. At the end are the code size figures.
For example:
The values are organized according to memory sections and areas. Per default, the linker
arranges the memory into the sections text, data, bss. More information is found
in the linker script file (.ld).
The dec and hex figures express the size of the .elf file. Below the filename header
is the name of the .elf file.
The Build Analyzer view can be used to analyse the size and location of a
program in detail. Please read more about the Build Analyzer at page 264
106 | P a g e
Getting Started
To enable Parallel Build select Project, Properties and in the Properties panel select C/C++
Build. Open the Behavior tab and Enable Parallel Build.
In the top menu select Project, Properties and in the Properties panel select C/C++ Build.
Open the Behavior tab and enable Build on resource save.
107 | P a g e
Getting Started
REBUILD PROJECT
To force a Rebuild of all files included in the project, click on the Rebuild toolbar button or
select the menu command Project, Rebuild Project.
108 | P a g e
Getting Started
109 | P a g e
Getting Started
HEADLESS BUILD
This is intended for Managed Mode projects that are to be integrated into script-
controlled builds, such as nightly builds on build servers for continuous integration process
methods, etc. It is possible to start a build process from the operating system command
line also for Managed Mode projects. The IDE GUI is never displayed in this case, and the
user does not have to interact manually with the IDE at all.
110 | P a g e
Getting Started
Option Description
-data {[uri:/]/path/to/workspace} This option is always required and selects which workspace to
use for the headless build. If the selected workspace folder
does not exist, it will be created automatically.
-import {[uri:/]/path/to/project} Optionally import a project into the workspace before the
headless build starts. Please note that importing into a
workspace is not the same as copying the files to the
workspace. It tells Atollic TrueSTUDIO that there exists new
files in a workspace.
-importAll {[uri:/]/path/to/projectTreeURI} Optionally import several projects into the workspace before
the headless build starts.
-build {projname_reg_exp} Build all build configurations (see page 88 for more
information) of the selected project. If the project name
contains wildcards (? and *), all matching projects will be
built.
-build {projname_reg_exp/configname} Build the selected project using only the selected build
configuration. If the project name contains wildcards (? and
*), all matching projects will be built.
This option can be used several times. That way libraries can
be built before the project depending on them.
-build all Build all configurations of all projects in the selected
workspace.
-cleanBuild {projname_reg_exp} Rebuild all build configurations of the selected project. If the
project name contains wildcards (? and *), all matching
projects will be rebuilt.
-cleanBuild Rebuild the selected build configuration of the selected
{projname_reg_exp/configname} project. If the project name contains wildcards (? and *), all
matching projects will be rebuilt.
-cleanBuild all Rebuild all build configurations of all projects in the selected
workspace.
-I {include_path} Additional include path to add to tools.
-Ep {var=value} Append value to environment variable when running all tools.
111 | P a g e
Getting Started
Option Description
-Er {var} Remove/unset the given environment variable.
Example:
This command will create a temporary workspace folder buildWS for this build. It will
import all projects from the folder checkOutDir (not copy, just import to the temporary
workspace) and build all build configurations defined in each project. The result will be
stored in the folder checkOutDir. A log file will be created in the folder headless.
LOGGING
To enable project build logging, right-click on the project and select Properties. Then
select C/C++ Build, Loggings.
WORKSPACE_PATH\.metadata\.plugins\org.eclipse.cdt.ui\MyProjec
t.build.log
A global build log for all projects in a workspace can be enabled by selecting Window,
Preferences and in the dialog open C/C++, Build, Logging and Enable global build logging.
112 | P a g e
Getting Started
To study the properties (such as code or data size) of an object file, open the Properties
view.
To open the Properties view, press the Show View toolbar button and select the
Properties view.
Then select the object file in the Project Explorer view. The Property view will display a
large number of properties, including code and data sizes of the object module.
To study the properties (such as code or data size) of a linked application binary file, open
the Properties view and select the ELF file in the Project Explorer view.
113 | P a g e
Getting Started
The Property view will display a large number of properties, including code and data sizes
of the complete application.
Data is normally stored in the “data" segment and code is normally stored in the "text"
segment.
The Build Analyzer view can be used to analyse the size and location of a
program in detail. Please read more about the Build Analyzer at page 264
114 | P a g e
Getting Started
In the C/C++ Build, Settings select the Tool Settings tab. Each one of the different tools in
the toolchain (Assembler, Compiler, Linker and Other) has its own patter that can be
modified.
White space and other characters are significant and are copied to the created command.
The environment variables can also be used. They are defined in Project, Properties,
C/C++ Build, and then Environment.
CREATE .LIST-FILES
To get list files with assembler information when the files in the projects are compiled the
build conigurations for the C/C++ compiler needs to be updated.
In the C/C++ Build, Settings select the Tool Settings tab and then C Compiler. In the Expert
settings for Command Line Pattern add -Wa,-aln=${OUTPUT}.list as shown below.
115 | P a g e
Getting Started
In the top menu select Window, Customize Perspective and in the dialog window open
the Menu Visibility tab.
Expand the Project node and enable the Build Automatically option.
116 | P a g e
Getting Started
Press OK, then go to the Project menu and make sure Build automatically is unchecked for
the project.
117 | P a g e
Getting Started
118 | P a g e
Getting Started
This chapter will explain some of the more common problems encountered during linking.
REFERRING PROJECT
Whenever one project is using code from another project, these should be referring to
each other.
If a project needs to refer to a specific build of another project, select instead Project,
Properties and then C/C++ General, Paths and Symbols and open the References tab and
select the Build Configuration that the current project is referring to.
119 | P a g e
Getting Started
With this way of referring between different Build Configurations. Note that the
references also can have priority among each other.
The Indexer will also be able to find functions from the library and open them. To
do that press the Ctrl key and in the editor, click the library-function where it is
used. The source file in the library will then be opened in an editor. For more
information about the Indexer, see page 148.
It is possible to create the Call hierarchy for the functions in the library. To find
the Call Hierarchy, mark the function name and press Ctrl+Alt+H. The Call
Hierarchy will then be displayed in the Call Hierarchy view.
If a library project is added as a reference, all the correct setting in Paths and Symbols
property page for the library will be entered. The tool settings that depends on this
Property page will also be adjusted.
This is the recommended method of adding libraries that is developed locally. For more
information about adding libraries see page 93.
There is another way to have projects referring to each other. In the top menu select
Project, Properties and select Project References. Then select and mark the referred
project.
However it is not possible to refer to different Build Configurations from this preference
and it will not automatically set up libraries.
120 | P a g e
Getting Started
To enable linker optimization, select the Remove unused code and/or the Remove unused
data checkboxes in the Project wizard as appropriate (at project creation time).
Dead code removal can be selected at any time by opening the Build Configuration in the
properties for the project. Right-click the project and select Properties and in the dialog
select C/C++ Build, Settings. In the panel select the Tool Settings-tab, C Linker, General.
Enable Dead code removal and rebuild the project.
121 | P a g e
Getting Started
122 | P a g e
Getting Started
Option1: Constructors for objects or constructor functions are placed in a list called
.init_array. These functions are then executed one by one by the libc_init_array.
Option2: Add code to an .init section. libc_init_array will run the _init function
which will execute all instructions added to the .init section. The crti and crtn contains
the start and end of the _init function.
123 | P a g e
Getting Started
To do that, open the Build Settings panel by pressing the Build Settings button.
Then navigate to the Tool Settings tab and select the C Linker, Miscellaneous node.
Additional object files can either be entered with the Add file path dialog or simply cut and
pasted into the panel.
124 | P a g e
Getting Started
If a project has many object files, either created during compilation or added as additional
object files, this method is no longer possible. Instead an external list of object files needs
to be referred to during linking.
In the Other Options field add -Wl,@FILENAME where FILENAME is a file containing a list
of object files to be included during linking.
125 | P a g e
Getting Started
One example on how the silent warnings appears is if the startup code containing the
normal Reset_Handler function is missing in the project. Then the GNU Linker will in
normal silent mode create an elf file and only report a warning output in the Console
window about the missing Reset_Handler. Example of warning message:
When the --fatal-warnings option is used the linker will not generate the .elf file but
display an error in the console log. Example of error message:
126 | P a g e
Getting Started
1. Open the Build Settings panel by pressing the Build Settings button.
2. Navigate to the Tool Settings tab and select the C Linker, Miscellaneous node.
LINKER SCRIPT
The linker (.ld) script file defines where things end up in memory. Some important parts
of the linker script file is described below.
The first instruction to execute in a program is called is defined with the ENTRY command.
Example:
/* Entry Point */
ENTRY(Reset_Handler)
The ENTRY information is used by GDB so the program counter (PC) is set to
the value of the ENTRY address when a program has been loaded. In the
described example the program will start to execute from Reset_Handler
when a step or continue command is given to GDB.
Note! The start of the program can be overridden if the GDB script contains a
monitor reset command after the load command. Then the code will
start to run from reset.
Example:
127 | P a g e
Getting Started
The location of stack is normally used by the startup file. The startup code
normally initialize the stack pointer with the address given in the linker script.
For Cortex-M based devices the stack address is also set at the first address in
the interrupt vector table.
It is common to define in the linker script the minimum size of Heap and Stack to be used
by the system. Example:
/* Generate a link error if heap and stack don't fit into RAM
*/
_Min_Heap_Size = 0; /* required amount of heap */
_Min_Stack_Size = 0x400; /* required amount of stack */
The values defined here are normally used later in the linker script to make it possible for
the linker to test if the Heap and Stack will fit into memory. The linker can then issue an
error if there is not enough memory available.
The memory regions are specified with name, ORIGIN and LENGTH. It is common also to
have an attribute list specifying the usage of a particular memory region, e.g. (rx) , ‘r’ (Read
Only section) and ‘x’ (Executable section), but there is no need to specify any attribute.
Example:
The output sections defines where in memory the sections such as ‘.text’, ‘.data’ etc. shall
be located. The following example tells the linker to put all .text, .rodata etc. sections in
the FLASH region. There are alos some glue sections mentioned here and these are used
by GCC if there are some mixed code in the program. The glue code is used if there are
some arm code which makes a call to thumb code or vice versa. Example:
128 | P a g e
Getting Started
.text :
{
. = ALIGN(4);
*(.text) /* .text sections (code) */
*(.text*) /* .text* sections (code) */
*(.rodata) /* .rodata sections (constants, etc.) */
*(.rodata*) /* .rodata* sections (constants, etc.) */
*(.glue_7) /* glue arm to thumb code */
*(.glue_7t) /* glue thumb to arm code */
*(.eh_frame)
KEEP (*(.init))
KEEP (*(.fini))
. = ALIGN(4);
_etext = .; /* define a global symbols at end of code */
} >FLASH
Initialized data values needs some extra handling as the initialization values needs to be
placed in flash and the startup code must be able to initialize the RAM variables with
correct values. The following example creates symbols _sidata, _sdata and _edata. The
startup code can then use these symbols to copy the values from FLASH to RAM during
program start. Example:
_sidata = LOADADDR(.data);
/* Initialized data sections into RAM, load LMA copy after code */
.data :
{
. = ALIGN(4);
_sdata = .; /* create a global symbol at data start */
*(.data) /* .data sections */
*(.data*) /* .data* sections */
. = ALIGN(4);
_edata = .; /* define a global symbol at data end */
} >RAM AT> FLASH
129 | P a g e
Getting Started
Uninitialized data values shall be reset to 0 by the startup code so the linker script file
needs to identify the location of these variables. The following example creates symbols
_sbss and _ebss. The startup code can then use these symbols to set the values of the
variables to 0.
. = ALIGN(4);
.bss :
__bss_start__ = _sbss;
*(.bss)
*(.bss*)
*(COMMON)
. = ALIGN(4);
__bss_end__ = _ebss;
} >RAM
When building an Atollic TrueSTUDIO Project Wizard generated project, a .map and a
.list file is created in the build output folder (Debug/Release). These files contains
detailed information on final location of code/data in the program.
The Build Analyzer view can be used to analyse the size and location of a
program in detail. Please read more about the Build Analyzer at page 264
Please read the Linker manual, accessible from the Atollic TrueSTUDIO
Information Center, for details about how the linker works. Especially section
3.6 and 3.7 could be of interest.
130 | P a g e
Getting Started
AUTOMATICALLY
This is the recommended method to generate a new Linker script.
Whenever anything in the Target Setting tab is changed a new Linker script can be selected
to be generated.
If the script is generated it can also be automatically used in the selected Build
Configuration. If possible the path to the script will be set to be relative to the project.
131 | P a g e
Getting Started
MANUALLY
The linker scripts can also be manually created. These scripts will not be automatically
added to any Build Configuration.
To manually create a new linker script, start by selecting the project to add the script into.
Right click the project and select New, Other…
1. In the dialog that then pops up select C/C++ and then Linker script.
2. Click Next.
3. The target must now be select properly. Here is the chance to select a new target.
The current settings can be found by right-clicking the project and selecting
Properties, C/C++ Build, Settings.
4. Click Finish.
132 | P a g e
Getting Started
In order to use the new script it needs to be selected in a Build Configuration. Right-click
the project and select Properties and in the dialog select C/C++ Build, Settings and in the
panel select the Tool Settings-tab, C Linker, General.
Modify the .ld-linker script’s memory regions. This is an example of a linker script file
containing the following memory regions:
MEMORY
133 | P a g e
Getting Started
{
FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 128K
RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 16K
MEMORY_B1 (rx) : ORIGIN = 0x60000000, LENGTH = 0K
}
Add a new area by editing the file. In this example the IP-Code region is added.
MEMORY
{
FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 64K
IP_CODE (x) : ORIGIN = 0x08010000, LENGTH = 64K
RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 8K
MEMORY_B1 (rx) : ORIGIN = 0x60000000, LENGTH = 0K
}
Variables and functions may not be placed in the same memory region.
Place the following code a bit further down in the script, between the .data { ... } and the
.bss { ... } section:
.ip_code :
{
*(.IP_Code*);
} > IP_CODE
This tells the linker to place all sections named .IP_Code* into the IP_CODE memory region
which is specified to start at target memory address: 0x8010000.
In the C-code, tell the compiler which functions should go to this section by adding
__attribute__((section(".IP_Code"))) before the function declaration.
Example:
The placed_logic()-function will now be placed in the IP_CODE memory region by the
linker.
134 | P a g e
Getting Started
Define a new memory region in the MEMORY {} region in the Linker script:
MEMORY {
...
EXT_RAM (xrw) : ORIGIN = 0x64000000, LENGTH = 8K
...
}
Then also define an output section for the code/data. This should be placed with a Load
Memory Address in EXT_RAM, and a Virtual Memory Address in FLASH:
. = ALIGN(4);
_eextram = .; /* define a global symbol at ext_ram end */
} >EXT_RAM AT> FLASH
Startup Code:
Then the external ram needs to be initialized and the code/data copied from flash to
external ram. The startup code can access the location information symbols _ siextram,
_sextram and _eextram by doing something like:
void copy_fn() {
const int *origin = &_siextram;
int *dest = &_sextram;
const int * const dest_end = &_eextram;
.... copy loop ....
}
135 | P a g e
Getting Started
MEMORY
{
FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 128K
RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 16K
MEMORY_B1 (rx) : ORIGIN = 0x60000000, LENGTH = 0K
}
A new memory region should be added by editing the file. In this example add the MYVARS
region.
MEMORY
{
FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 64K
MYVARS (x) : ORIGIN = 0x08010000, LENGTH = 64K
RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 8K
MEMORY_B1 (rx) : ORIGIN = 0x60000000, LENGTH = 0K
}
Variables and functions may not be placed in the same memory region.
Now the memory section should be added. Place the following a bit further down in the
script, between the .data { ... } and the .bss { ... } section:
.myvars :
{
*(.myvars*);
} > MYVARS
136 | P a g e
Getting Started
This tells the linker to place all sections named .myvars* from input into the .myvars
output section in the MYVARS memory region, which is specified to start at target memory
address: 0x8010000.
A section can be called almost anything except some predefined names such as data.
To be absolutely certain that the order will stay the same even if they are spread in
multiple files, add each variable to its own section. Then map the order of the variables in
the linker script.
__attribute__((section(".myvars.VERSION_NUMBER"))) uint32_tVERSION_N
UMBER;
__attribute__((section(".myvars.CRC"))) uint32_t CRC;
__attribute__((section(".myvars.BUILD_ID"))) uint16_t BUILD_ID;
__attribute__((section(".myvars.OTHER_VAR"))) uint8_t OTHER_VAR;
And then decide the order in the linker script by adding the specially named sections like:
.myvars :
{
*(.myvars.VERSION_NUMBER)
*(.myvars.CRC)
*(.myvars.BUILD_ID)
*(.myvars*);
} > MYVARS
Then the reference in the C file might look like this using the incbin directive and the
allocatable (“a”) option on the section.
asm(".section .binary_data,\"a\";"
".incbin \"../readme.txt\";"
);
That section is then added in the linker script with instructions that the section should be
put in flash.
137 | P a g e
Getting Started
.binary_data :
{
_binary_data_start = .;
KEEP(*(.binary_data));
_binary_data_end = .;
} > FLASH
This block can then be accessed from the C code with code similar to the following:
extern int _binary_data_start;
int main(void)
{
int *bin_area = &_binary_data_start;
…
}
Example
MEMORY
{
FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 64K
MY_DATA (rx) : ORIGIN = 0x08010000, LENGTH = 64K
RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 128K
}
2. Add a section for MY_DATA using the NOLOAD directive. This can be done using the
following code a bit further down in the linker script.
.my_data (NOLOAD) :
/* .my_data : */
{
*(.MY_Data*);
} > MY_DATA
Finally data can be used somewhere in the program by adding a section attribute when
declaring variables which shall be located in MY_DATA memory.
138 | P a g e
Getting Started
139 | P a g e
Getting Started
However, removing a Workspace from that list will not remove the files. Neither will
removing the files from the file system remove the workspace from this list.
In the menu select File, Export. Then in the panel select General, Preferences. Press the
Next button and in the next page enable Export All and a good filename of your choice.
Then select File, Switch Workspace and your new workspace. Atollic TrueSTUDIO will then
restart and open with the new workspace.
140 | P a g e
Getting Started
In the menu select File, Import and in the panel select General, Preferences. Press the
Next button and on the next page enable Import All and enter your file name. The
preferences will now be the same in the two workspaces.
Select the General node and then enable Show heap status. The currently used and
available Java Heap Space will then be displayed in the lower right corner of the
Workspace. The garbage collector can also be manually triggered there.
If Atollic TrueSTUDIO is started with a workspace that already is used by another instance
of the program, the following error message is displayed:
141 | P a g e
Getting Started
142 | P a g e
Getting Started
It is a good idea to only have the currently active projects opened. Close the
rest of the opened projects in the workspace. This will make the indexer work
faster and reduce the memory used by TrueSTUDIO. It also makes it easier
finding errors and bug in the code.
A project is closed by right-clicking it and select Close Project.
EDIT
Atollic TrueSTUDIO contains a state-of-the-art editor with almost any feature one can
imagine! Noteworthy features are spell checking of C/C++ comments, word- and code
completion, content assist, parameter hints and code templates. The editor also includes
an include-file dependency browser, code navigation using hypertext-links, bookmark &
to-do lists, and powerful search mechanisms.
There are so many features that it is easy to miss some really useful capabilities. While we
have simplified the user experience in Atollic TrueSTUDIO, there are probably still many
features that could be put to good use by more developers.
Below are some of the useful tools that are easily missed.
If a keyboard with numeric keypad is used and the + or – keys are pressed on the numeric
keypad then also use Shift key to make zoom work (Ctrl+Shift+ or Ctrl+Shift-).
143 | P a g e
Getting Started
Show In: Sends this file to one of the views chosen in the dropdown list (such as the
#include file dependency browser view)
Open With: Opens this file in any of the editors listed in the drop down list.
Open: This is probably the most commonly used option; it just opens the file in the
standard C/C++ editor.
BRANCH FOLDING
If a block is enclosed within #if/#endif, it can be folded. To activate the functionality, go to
Window, Preferences, C/C++, Editor, Folding and check the checkbox Enable folding of
preprocessor branches (#if/#endif). After the checkbox has been checked, the editor has
to be restarted. Just close the file and open it again and there should be a small icon in the
left margin of the editor.
144 | P a g e
Getting Started
Alt+Shift+A toggles selection mode between normal and block. When block mode is
enabled a block of text can be selected by either the mouse or the keyboard using SHIFT
and ARROW buttons.
Press Alt+Shift+A
Press the cursor somewhere in the text and drag it down. A column will now be marked.
145 | P a g e
Getting Started
146 | P a g e
Getting Started
147 | P a g e
Getting Started
THE INDEX
In Atollic TrueSTUDIO there is an important mechanism called Indexer that creates a
database of the source and header files. That database is called the Index and is used to
provide information for all navigation and content assist in Atollic TrueSTUDIO. It includes
the information about where to find information such as where a function is located and
used, where a preprocessor symbol is located and where global variables are defined.
Try pressing Ctrl and clicking on a function that is used somewhere in the code. The editor
will jump to its definition. Also hovering over it will display its comments and
documentation.
The Indexer is running in the background and keeps track on all changes in the project.
The Indexer is normally customized per Workspace, but can also be set on a per project
basis. To customize the Indexer per Workspace in the menu select Window, Preferences
and in the Preferences dialog select C/C++, Indexer.
148 | P a g e
Getting Started
To customize the Indexer setting per project right-click the project and select Properties.
In the Properties dialog select C/C++ General and then Indexer.
149 | P a g e
Getting Started
Select Enable project specific settings. It is a good idea to skip large files and files with
many hundreds of includes. This will prevent the Java heap from running out of space. If
the project is version controlled, it is also a good idea to store the settings within the
project.
From time to time the Index fails to keep track on the changes in the project. Most likely
this is due to some includes being changed or missed. Then the Index database needs to
be rebuilt. To do that right-click the project and select Index, Rebuild.
If this doesn’t solve the problem or the indexer’s database file (the . pdom-file) is corrupted,
open the workspace folder and locate the hidden directory:
.metadata\.plugins\org.eclipse.cdt.core
Delete the file: YOUR_PROJECT_NAME.pdom and restart Atollic TrueSTUDIO. The Index is
now rebuilt from scratch.
The most likely reason for a corrupted .pdom-file is that TrueSTUDIO somehow crashed
during indexing. That can happen if Atollic TrueSTUDIO runs out of Java heap space, see
Keeping Track on Java Heap Space on page 141 for more information about the Java Heap.
150 | P a g e
Getting Started
The preferences for the Scanner Discovery mechanism can be found by selecting Window
in the menu and then Preferences.
In the Preferences panel select C/C++, Build, Settings and then to the right the Discovery-
tab.
A list of the available Language Setting Providers are then displayed. A Language Setting
Provider is a specialized mechanism to discover settings. Some providers calls the tool
chain for built in compiler symbol and includes. Others scan the build output for that
information. The found entries are then stored in the workspace (shared) or for each
project.
The Atollic ARM Tools Language Settings is by default not shared between projects.
151 | P a g e
Getting Started
By selecting one provider that individual provider can be configured. If that provider have
found and are sharing some entries in the workspace, those entries can be removed by
pressing Clear Entries. That can be a good idea to do if the path to included files are
wrong.
Enable Allocate console in the Console View will send output to the console each time the
providers runs.
The project and Build Configuration specific settings and entries can be found by selecting
the project and then in the menu select Project, Properties and in the Properties panel for
the project select C/C++ General, Preprocessor Include Paths, Macros etc. and select the
Providers tab first.
When using a version control system it is best to enable Store entries in project setting
folder.
Do not enable the Use global provider shared between projects option! The Atollic ARM
Tools Language Settings is by default not shared between projects. Since each project has
different arguments to the tools based on the Target Settings, sharing between projects
will not give a totally accurate result.
The Entries tab displays the found entries for the different providers. At the top is the CDT
User Setting Entries. By selecting that user defined entries can be added.
152 | P a g e
Getting Started
When sharing a project in a version control system, it is a good idea to set the
SVN property svn:ignore on the file
%PROJECT_LOCATION%/.settings/language.settings.xml since it
includes a hash specific to each individual environment. See more in the
chapter about SVN on page 206.
The view is also able to display all the files included in the selected file and the name of the
folder where the files are located.
153 | P a g e
Getting Started
To be able to keep track on these changes and properly edit external source files in Atollic
TrueSTUDIO, a link to the folders or to the files needs to be added to the project. To add a
link to a file, right-click on a source folder and select New, File.
In the dialog click on the Advanced button and select Link to file in the file system.
Enter the file name and Browse to the file you want to create a link to.
154 | P a g e
Getting Started
When this is done, Atollic TrueSTUDIO will keep track of all changes in the file and rebuild
when the file is changed.
155 | P a g e
Getting Started
4. Add the path to the library and the library name by selecting Project, Properties,
C/C++ General, Paths and Symbols and then use the Path tab. (On page 93
another method is explained in Include Libraries). Remember not to include the
“lib”-prefix and the file extension (.a).
6. Copy the library files from the extracted folder CMSIS\lib\GCC to the folder
created in step 3. Very with the FPU settings in the Target Settings that the
correct library is used.
7. To be able to debug the library, the source to it must also be added to the known
sources, see page 90 for more information about how to do that.
It might also be a good idea to also update the header files with the ones provided in the
download.
156 | P a g e
Getting Started
5. Insert a row after it that looks almost the same, but with an extra “c”:
6. <nature>org.eclipse.cdt.core.ccnature</nature>
7. Do not remove the cnature-row!
8. Save the file and the project will now also compile with the C++ tools.
157 | P a g e
Getting Started
The Build tools selection has three options. Select option depending on your needs and
the file will be opened in the editor. The options are:
158 | P a g e
Getting Started
159 | P a g e
Getting Started
I/O REDIRECTION
The C runtime library includes many functions, including some that typically handle I/O.
The I/O related runtime functions include printf(), fopen(), fclose(), and many
others.
It is common practice to redirect the I/O from these functions to the actual embedded
platform, such as redirecting printf() output to an LCD display or a serial cable, or to
redirect file operations like fopen() and fclose() to some Flash file system
middleware. Atollic TrueSTUDIO also comes with an integrated Terminal that can be used
to display redirected I/O, see page 247 for more information.
In Atollic TrueSTUDIO three different techniques are generally most used. It is the old
UART output, Segger’s Real Time Terminal (RTT) that is explained on page 249 and on
targets that has support for SWV, the ITM output that is explained on page 302.
SWV Low or none CPU overhead but very limited bandwidth. Only supported by some
targets.
RTT A bit smaller CPU overhead than UART and higher bandwidth. Needs a Segger Probe.
Atollic TrueSTUDIO do support I/O redirection. To enable I/O redirection the file
syscalls.c should be included and built into the project:
1. In the Project explorer view, Right click on the project and select New, Other...
160 | P a g e
Getting Started
4. Click Browse... and select the src folder as new file container. Also select the
Heap Implementation. There is one dynamic heap implementation that is default
and a fixed one intended for RTOS use. If the latter is selected a modification of
the script linker_script.ld in accordance with the instructions is also
needed.
5. Click OK.
161 | P a g e
Getting Started
To redirect the printf() to the target output, the _write() function needs to be
modified. Exactly how this is done depends on the hardware and library implementation.
Here is an example:
162 | P a g e
Getting Started
The compiler has an option -fPIE that enables the compiler to generate position
independent code for executable. Add this option into the tool settings for the Assembler
and C Compiler in the Miscellaneous settings.
Also use this -fPIE option for the linker. E.g. in the Miscellaneous settings the Other
options field for the C linker, the command may look like
-Wl,-cref,-u,Reset_Handler -fPIE
163 | P a g e
Getting Started
Make sure that the stack pointer is set up correctly. Normally this is done by issuing a
monitor reset command as part of the Startup-script for the debug session.
However now the start code needs to set the stack pointer instead; do this by adding the
following assembly line at the top of the Reset_Handler()-function located in the
startup file:
This will make sure that the stack pointer is initialized when the Reset_Handler()-
function runs.
Since the monitor reset command is not used any more, it needs to be removed from
the Debug Startup Script.
Do this by opening your debug configuration, by pressing the Debug Configuration button,
switch to the Startup Scripts tab.
This contains all commands that are used to launch a debug session. Try commenting
the monitor reset line out by adding a # sign in front.
164 | P a g e
Getting Started
Also in some examples the SystemInit()-function for the vector table relocation needs
to be changed.
To test that the code is started where it should be, also comment out the continue
command from the Debug Startup script. This will suspend execution on the first
instruction in the Reset_Handler(), making it possible to debug the start-up code.
165 | P a g e
Getting Started
CMSIS-Pack is one of these components and from version 6.0 Atollic TrueSTUDIO supports
the CMSIS-Pack standard.
The CMSIS-Pack Management for Eclipse v2.0 software created by ARM is integrated into
Atollic TrueSTUDIO v7.0. and used to:
CONFIGURATION
Before using CMSIS-Pack the CMSIS Pack root folder needs to be configured. In the menu
select Window, Preferences and in the Preferences dialog configure the CMSIS-Pack root
folder to point to some location on the disk where downloaded Packs shall be stored. For
instance in this case the Packs are stored into F:\CMSIS_Pack.
166 | P a g e
Getting Started
The CMSIS Packs configuration also contains links to the sites where packages are
published. Use Add, Edit and Delete to change the sites which will be searched by the
CMSIS Pack plugin.
Open the CMSIS Pack Manager perspective, e.g. this can be done by writing Pack in the
Quick Access field and select CMSIS Pack Manager.
167 | P a g e
Getting Started
The Packs perspective is now opened and when using it first time the Packs view is empty.
See the figure below and the information about what the Packs view toolbar buttons does.
168 | P a g e
Getting Started
Use the Blue Arrow icon to check for updates of the packages definitions from all
repositories. All packs are now read from the repositories. This may take some minutes
If any errors occurs press Yes, if this does not help then press No or Cancel.
169 | P a g e
Getting Started
When updating is finished the Packs view is populated with new Device Specific and
Generic information. The Devices and Board tabs are populated with device and board
information from different vendors.
The Packs view shows the Software Packs available for the selected device or board. Enter
a pack name using wildcards into the field Search Pack to narrow the list.
The Devices and Boards tabs contains information on devices and boards from different
vendors.
The Devices view lists devices that are supported in available Software Packs. Select a
device to narrow the list in the Packs and Examples view.
170 | P a g e
Getting Started
171 | P a g e
Getting Started
Enter a device name in the Devices tab using wildcards into the field Search Device to
reduce the list.
172 | P a g e
Getting Started
The Boards view lists the boards that are supported in available Software Packs. Select a
board to narrow the list in the Packs and Examples view. E.g. STM32
173 | P a g e
Getting Started
The Installed CMSIS Packs (Sample view) displays the installed packages. Currently no
packages has been installed so at this time the view is empty. There is also a similar
Installed CMSIS devices (Sample view) which displays installed devices.
It is recommended to install the ARM.CMSIS Pack as this contains basic CMSIS software
and is used by most other CMSIS Packs.
174 | P a g e
Getting Started
Select the version of the Pack that shall be installed and press the Install button in the
action column. The installation will then start. We will now install the Keil.STM32F4xx_DFP
and the generic ARM.CMSIS packages.
175 | P a g e
Getting Started
When a Pack is installed the color of the icon for the Pack is changed to yellow in the Packs
view.
176 | P a g e
Getting Started
There are several ways to create projects based on CMSIS-Pack. One way is to create a
CMSIS C/C++ Project and another way is to use the Embedded C Project which will be
populated with devices/boards defined also in installed CMSIS-Pack files.
Press Next.
177 | P a g e
Getting Started
Select Create default main.c file, the Atollic ARM GCC Toolchain will be used and GCC and
software will be taken from the CMSIS-Pack files.
Note! Unfortunately many CMSIS-Pack files are not yet complete with GCC
startup and linker files included in the CMSIS-Pack so some manual
adaptations may be required after a project is created, to make it build
correctly.
If the startup and/or linker script file is missing when the project is generated
then investigate if these files are included in the Pack by using a file browser.
If the files are found then copy them into the project and rebuild the project.
If the startup and/or linker script file is missing in the Pack then create a
TrueSTUDIO project for the device if it is supported by Atollic TrueSTUDIO and
copy those files to the project. Alternatively create a basic ARM project for a
similar ARM core and base the startup and linker script for the CMSIS project
on these files. Make sure to update the startup file to include the interrupt
vectors and linker script file with the device memory mapping etc.
If the CMSIS-Pack project provides a linker script and you would like to change
some information in it there is a need to create a linker script outside the
normal folder, see information about this in the Updating Linker Script for
CMSIS C/C++ Project chapter at page 184.
Press Next.
Select the device from a package to generate the project for. In this case we use the
STMicroelectronics STM32F407VGTx device
178 | P a g e
Getting Started
Press Next.
179 | P a g e
Getting Started
For instance we would like use the Startup file from the STM32F407VGTx device.
180 | P a g e
Getting Started
As seen in the figure above the Startup file depends on files in the CMSIS CORE group so
we need to include also the CMSIS CORE files to this project.
181 | P a g e
Getting Started
Figure 153 – Configure CMSIS C/C++ Project with CMSIS CORE files
Save the setting by pressing on the Disk icon on the toolbar. If we build the project we get
the following build result.
182 | P a g e
Getting Started
As seen this project does not build correctly. The reason is that the CMSIS Pack file does
not contain correct information to build with gcc.
Note! If there are any build errors please check if the project contains a
startup file and a linker script file.
When using GCC the startup file and linker script file is tightly connected as for
instance the startup file needs to get information from the linker script where
memory and stack should be located.
If the Pack does not contain any startup or linker script file the Atollic
TrueSTUDIO wizard will generate and add generic startup and linker script
files to the project. In such cases there is a need to manually update the linker
script with stack location and memory location and size information. Also the
startup script only contains the first 16 generic Cortex-M interrupts so there is
a need to add the device specific interrupts into the startup file if such
interrupts are used.
183 | P a g e
Getting Started
To solve the problem in this case copy the startup file from the
RTE/Device/STM32F407VGTx folder (Note! This folder was not created as a source
folder) to the project root folder were the main.c file is located. Also copy the
system_stm32f4xx.c file to the project root directory.
If the linker script file is missing in the pack it can be copied from some other project for
STM32. The best way could be to create a standard Atollic TrueSTUDIO project for the
board and copy the linker script files from that project into the created CMSIS Pack
project. When the linker script file has been copied update the properties for the project
so that the linker file is used.
184 | P a g e
Getting Started
If the linker script for this project needs to be updated manually then please take a copy of
the linker script and make the updates in this new file. Then update the Linker script
setting in the Tool Settings tab in Properties for the project to point to the new script.
Start a debug session for the project. First time a project is debugged a new Debug
Configuration needs to be created. Select ST-LINK as debug probe and make sure that SWD
is enabled if the board to be debugged is using ST-LINK and SWD.
185 | P a g e
Getting Started
The RTE project can be debugged using a debug probe and a board. In this case we will
debug the created STM32project using the STM32F4-Discovery board which includes a ST-
LINK onboard.
Press F11 and the Edit Configuration dialog appears. In the Debugger tab select Interface
SWD.
Make sure the board is connected to the PC using the Debug connector on the board and
then Press OK.
The program is now loaded to the board and the debug session is started.
186 | P a g e
Getting Started
The Keil CMSIS_Pack for STM32 contains many examples for different board. One way to
easy test examples is to open the Pack in file explorer and double-click on a .project file in
an example. The project will then be imported into TrueSTUDIO. E.g. Open the following
folder in the Pack to discover how to use STM32 drivers.
F:\CMSIS_Pack\Keil\STM32F4xx_DFP\2.11.0\Projects\STM32F4-
Discovery\Examples\GPIO\GPIO_EXTI\TrueSTUDIO\STM32F4-Discovery
Build and test the program in the Debugger to discover the usage of GPIO drivers on the
board.
187 | P a g e
Getting Started
Atollic does not provide support for any third party plugins.
Support for third party plugins are always provided by their respective
manufacturer.
188 | P a g e
Getting Started
3. Then enter the URL to the update site for the plugin. If the URL is not known,
All Available Sites can be selected.
189 | P a g e
Getting Started
Select the appropriate plugins. Please remember that not all ECLIPSE™
plugins are compatible with Atollic TrueSTUDIO.
Click the Next button.
5. Read all the licenses agreements and click accept if the terms are found
acceptable. Then click the Finish button.
190 | P a g e
Getting Started
191 | P a g e
Getting Started
In the new panel select the plugin to uninstall and press Uninstall…
192 | P a g e
Getting Started
2. Identify the folder which corresponds to the Atollic TrueSTUDIO version you are
using.
3. Rename this folder and restart Atollic TrueSTUDIO. The product should now start
as it was first installed without any updates.
193 | P a g e
Getting Started
The ST-Link GDB-server used for debugging STM32 devices does not implement all
functionality available in the ST-Link utility. It is however possible to call ST-Link Utility
from inside the IDE, this can save a lot of time when performing various debugging related
tasks.
When certain parts of the flash need to be erased before loading binary
When you want to compare the binary file in target with the one just built with
Atollic TrueSTUDIO.
For faster loading into flash than is offered by the ST-Link GDB-server
REQUIREMENTS
St-Link Utility (Download it from http://www.st.com)
A working ST-Link
The ST-Link utility does not support elf-files. Use Intel Hex.
194 | P a g e
Getting Started
4. Create a Launch Group to perform the ST-Link Utility operations before the Atollic
TrueSTUDIO debugger starts
195 | P a g e
Getting Started
Press Apply
Test that the external tool just setup is working by clicking Run or Run, External Tools…,
ST-LINK_CLI
Be cautious about which Configuration that is selected! In the screenshot Debug was
selected so the conversion will not take place when building a Release configuration.
Click OK
196 | P a g e
Getting Started
The output name will be %PROJECT%.hex. Make sure that this binary is selected when
creating the debug configuration. This will not work with an .elf-file.
Change the name of this configuration to “… NO LOAD”, this is since GDB will not
be used to load the hex.
Open the Startup Scripts tab, comment out the “load” command load, #load. It
might also be a good idea to comment out the “monitor reset” command.
Click Apply.
197 | P a g e
Getting Started
Double-click on the Launch Group node to create a Launch group and give it a name.
Click Add…
Expand Programs and select your external tool configuration, i.e. ST-LINK_CLI.
198 | P a g e
Getting Started
Expand Embedded C/C++ Applications and select your debug configuration, i.e.
Project NO LOAD.
199 | P a g e
Getting Started
Click Apply
This will make the launch group available in Atollic TrueSTUDIO from the Run, Run-menu
and later the Run, Debug History…
FINISHED
ST-Link Utility is now flashing the binary into the target memory and the debugger is
started as soon as the ST-Link Utility has finished.
200 | P a g e
Introduction
MISCELLANEOUS TOOLS
The Quick Access search bar is an edit field in the toolbar, where any search phrase or
keyword can be entered. GUI objects like menu commands, toolbar buttons, preference
settings or views ca be found with it.
As any search string is typed, the Quick Access search bar shows all the GUI objects that
match the criteria, in “real-time”. Type a couple of more characters and the search results
list is refined correspondingly “on-the-fly”.
The Quick Access search bar is an enormous time saver when looking for a specific GUI
object that can’t be found quickly, such as finding a preference setting deeply buried in the
configuration dialogs. Or to just issue a menu command or toolbar button hidden in the
currently active perspective.
For example, in the screenshot above the search string “SWV” has been entered and the
Quick Access search bar immediately provides the list of matching views, GUI commands
and preference settings. To open the view or preference setting just click on the GUI
object in the search result list
201 | P a g e
Getting Started
VERSION CONTROL
Atollic TrueSTUDIO includes a basic version-system for projects that works well for a
project with just one developer on one computer. It allows users to keep tracks on local
file history.
For more information about a local repository see Local SVN Repository below.
However if users need to collaborate, keep better track of changes and perhaps work on
many workstations, a better version control-system is needed.
Atollic TrueSTUDIO supports three such systems GIT, Concurrent Versions System (CVS)
and Subversion (SVN). The CVS is an older system that Atollic TrueSTUDIO supports for
those that already have CVS-repositories.
File revision annotations, file difference viewer and revision graph viewer
Full traceability of all lines, in all files, throughout complete project history
SUBVERSION - SVN
Subversion (SVN) is an open source version control system that was design to replace the
older CVS. It is more or less a de facto standard in the computer industry.
A free and very good online book about SVN can be found here
http://svnbook.red-bean.com/
SVN manages files, directories and the changes made to them. That way it is possible to go
back to previous version of the code or inspect what changes has been made over time. It
also operates over a network and allows the same code to be changed simultaneously on
many computers, even over the internet. Thus development can be done faster and with
fewer errors. If some incorrect code is entered it can just revert to the previous version.
202 | P a g e
Getting Started
To be able to use SVN a Subversion repository is needed. How to set up and maintain a
network repository is out of the scope of this manual. On page 206 set up off a local
repository is explained. There are also several websites such as Freepository, Google Code
and SourceForge provides free source code hosting that can be accessed with Atollic
TrueSTUDIO’s SVN-integration. A good introduction to how to set up a repository can also
be found in chapter 5 in the SVN-book and in several good tutorials on the net.
After making sure a repository exists, the next thing to do to be able to use SVN in a
project, is to enable SVN in Atollic TrueSTUDIO. In the top menu select Window,
Customize Perspective.
In the dialog that opens up select the Command Groups Availability-tab. Find SVN in the
Available command groups-column and make sure it is selected. Click OK.
Some extra items are now available in the toolbar. However they should be greyed out.
There will also be a new top-menu called SVN.
There are several views in Atollic TrueSTUDIO for managing SVN. They can be found by in
the top-menu select Window, Show View, Other.
203 | P a g e
Getting Started
The first view needed is the SVN Repositories since that where repositories are connected.
Next step is to share the project in the repository. Right-click on the project and select
Team, Share Project. In the dialog that then pops up, select SVN and click on Next. Select
the repository and then Finish.
For more information about how to use SVN, see the tutorials at
http://www.atollic.com/index.php/videotutorials
For more information about how to use SVN, see the tutorials at
http://www.atollic.com/index.php/videotutorials
LOCKS IN SVN
In normal cases locks is never used in SVN. SVN is very good in merging different versions
and branches of the same file. That way more than one developer can edit the same
source-file without fearing to interfere in other developers work.
However in very special cases, such as editing images and other complex file-types, SVN
can’t merge. In that case we recommend to lock the file before editing it.
204 | P a g e
Getting Started
Locking is easy. Just right-click on the file, select Team, Lock and enter a brief comment on
why the file is locked.
If others now want to edit the same file, they will only have a read-only version of the file
and can’t save or check it in.
To make sure a file is always locked before anyone can edit it, do the following:
3. Check with Team, Show Properties that the property is correctly added
That string will be replaced with a text showing the revision number of that file.
205 | P a g e
Getting Started
Other possible values to the svn:keywords is Date, Author, HeadURL and Id.
"$Revision:: $".
IGNORE A FILE
To ignore sharing a specific file in a repository, the property svn:ignore needs to be set
instead. It is done in the same manner as the other properties above.
When sharing a project in a version control system, it is a good idea to set the SVN
property svn:ignore on the file
%PROJECT_LOCATION%/.settings/language.settings.xml since it includes a hash
specific to each individual environment.
206 | P a g e
Getting Started
1. Open the SVN Repositories by selecting Window, Show View, Other… and in the
panel select SVN, SVN Repositories and press OK.
3. In the Create Repository dialog enter the name and location for the new local
repository and make sure File System is selected.
207 | P a g e
Getting Started
5. To start version controlling a project in the repository, right click the project and
select Team, Share Project…
208 | P a g e
Getting Started
This is particularly important to remember when using tools such as STM32CubeMX that
crates project with code that are linked into the project and for different downloadable
example projects that lets the actual code reside outside the project.
There is however at least two different method to solve this. Since SVN doesn't commit
files that reside physically outside of the project it is necessary to show the files within a
Atollic TrueSTUDIO project. These examples are for STM32CubeMX but can easily be
adapted to fit other external resources.
Create a project for version control in the CubeMX-project-root (the folder that contains
the TrueSTUDIO, Inc, Src etc) and use it together with the normal development project.
Versioning project
In the top menu select File, New, Project
In the New Project wizard that is opened, select General, Project
Input a name for this project, for example MyVersionedCubeMXProject
Uncheck the Use default location, then browse to the CubeMX-project’s-root folder
Commit MyVersionedCubeMXProject to SVN
Development project
In the top menu select File, Import, General, Existing Projects into Workspace
Select root directory and browse to the MyVersionedCubeMXProject\TrueSTUDIO
folder
Make sure Copy projects into workspace is Unchecked!
Workflow of this setup is to develop/debug using the development project and version
control the project using the MyVersionedCubeMXProject
Alternative 2 - Resolve the project so that all code reside physically within the project
Export the CubeMX project as an archive, this will resolve all .c source code.
Remove the CubeMX project from the TrueSTUDIO workspace. Do not delete them, but
keep the CubeMX files on the disk a while longer.
Import the project that was exported in step one. This project will now contain all .c files
and settings. Lets call this project CubeMX-resolved from now on.
209 | P a g e
Getting Started
However since CubeMX doesn't make references to header files in the generated project
these will be missing. Included directories also needs to be manually inspected that they
still are intact.
Manually copy the needed header files from the original CubeMX project to the CubeMX-
resolved project
Open the Build Configuration for the CubeMX-resolved project and correct the include
paths in the C-Compiler, Directories node.
If the same structure for the header files is kept as they were in the original CubeMX
project then only ..\..\ needs to be removed from the include paths.
For example..\..\..\Drivers\STM32F4xx_HAL_Driver\Inc\Legacy
becomes..\Drivers\STM32F4xx_HAL_Driver\Inc\Legacy.
Commit the CubeMX-resolved to SVN
Individual views can also be de-attached from the IDE by clicking the tab with the view
name located in the upper left corner of the view and dragged to a new place on any
monitor. This can also be done with open editors, so that individual files can be opened
and edited in individual windows.
By in the top menu selecting Windows, New Editor the same file can also be edited
simultaneously in different editor windows. Changes will be displayed immediately in both
windows. One editor-window be dragged to another monitor. This is very practical when
editing large files.
If instead in the top menu Window, New Window is selected a cloned copy of the current
Atollic TrueSTUDIO IDE will be opened. It will however always work with the same
workspace and all editing done in the projects will be displayed in both opened IDEs. They
are after all clones and not individual instantiations Atollic TrueSTUDIO.
210 | P a g e
Getting Started
Figure 185 – Multiple Editors, Views and Windows used at the same time
Atollic TrueSTUDIO will now be opened in an additional window. This is useful when the
workplace is equipped with two screens. It is then possible to edit and debug at the same
time. One instance of Atollic TrueSTUDIO can then be used for editing and the other for
debugging.
211 | P a g e
Getting Started
SHELL ACCESS
To access Windows Shell (cmd.exe) open the shell by selecting Window, Show View and
select Terminal view.
212 | P a g e
Getting Started
In the Terminal view a Terminal is launched by clicking the Open a Terminal icon.
The Launch Terminal dialog is now opened. Select Local Terminal and the Encoding to use.
213 | P a g e
Getting Started
214 | P a g e
Introduction
DEBUGGING
This section provides information on how to begin using Atollic TrueSTUDIO for STM32.
Debug Configuration
Debug Perspective
Debugging
Advanced Debugging
215 | P a g e
Debugging
Debugging with Atollic TrueSTUDIO is done with a GDB Server. The GDB Server is a
program that connects GDB (GNU Debugger) on the PC to a target system. It can be
started locally or remotely as shown in the two conceptual pictures below:
216 | P a g e
Debugging
If Local debugging is selected Atollic TrueSTUDIO automatically starts and stops the GDB
server as required during debugging, thus creating a seamless integration of the GDB
server.
To prepare for debugging with an ST-LINK JTAG probe connected to your electronic board,
perform the following steps:
1. Verify that the RAM and FLASH configuration switches on the target board
is set to match the Atollic TrueSTUDIO project configuration, regarding
memory. Note: Not all boards have such configuration abilities.
3. Connect the JTAG cable between the JTAG probe and the target board.
4. Connect the USB cable between the PC and the JTAG probe.
5. Make sure the target board has a proper power supply attached.
Once the steps above are performed, a debug session in Atollic TrueSTUDIO can be
started.
217 | P a g e
Debugging
2. Click on the Debug toolbar button (the insect icon) or press the F11 key to
start the debug session.
218 | P a g e
Debugging
5. Click on the Debugger panel to display it. The panel contains information
on the JTAG probe to use, its configuration, and how to start it. Some
settings are probe-specific.
6. Open the Debug probe drop down list. Select the JTAG probe to be used
during the debug session.
219 | P a g e
Debugging
Figure 197 - Debug Configuration, Debugger Panel for the SEGGER J-Link
The Debugger Panel for SEGGER J-Link probe contains a checkbox Use specific
J-Link S/N. Enable this checkbox If several SEGGER debug probes are
connected to the PC and enter the serial number of the SEGGER J-Link probe to
be used.
Update the Device name if there is a problem to use Segger J-Link gdbserver
with default device name. The name to use can be found if
JLinkGDBServer.exe is started and Target device is selected in the Config GUI.
Select RTOS variant listbox can be used if Thread-aware RTOS support is used
with FreeRTOS and embOS.
It has been noticed that when Thread-aware RTOS support is used there may
be a need to updated the gdb Target Software Startup Scripts. The script is
available in the Startup Scripts tab. Please add “thread 2” command line
before the last “continue” command in the script. This will force a thread
context switch before the “continue” command is sent.
220 | P a g e
Debugging
The Debugger Panel for ST-Link probe contains a checkbox Use specific ST-Link
S/N. Enable this checkbox if several ST-Link debug probes are connected to the
PC. The Scan button can be used to get the serial numbers of connected ST-
Link’s. After a scan the serial numbers are presented in the list-box. Use the
list-box to select the ST-LINK to be used for debugging.
When using two GDB servers at the same time, they must both use different
port numbers, e.g. 61234 and port 61244.
221 | P a g e
Debugging
10. If the ST-Link JTAG probe was selected in step 6, the Misc settings
contains a checkbox External Loader. Enable this checkbox if the program
shall be programmed into an external flash on the board. The Scan button
can be used to get a list of external flash loader files, “.stldr”, included
with STM32 CubeProgrammer. Use the list-box to select the “.stldr” file
to be used for programming the external flash. It is also possible to
manually enter a path and filename to a “.stldr” filename directly into
the list-box.
11. If any other debug probe than ST-Link JTAG probe was selected in step 6,
the following Misc settings are relevant:
Atollic TrueSTUDIO is able to automatically recognize and launch J-Link
scripts at the start of a debug session. If a script is needed to debug a
wizard-created project, the wizard will also automatically create one.
To manually select the J-Link script to be launched, please enable the Use
J-Link script file option and browse to the desired script file.
To be able to use the Live Expressions view during debugging the Live
Expression mechanism has to be enabled during startup. It is enabled by
default.
222 | P a g e
Debugging
13. The Startup Script panel contains the initialization scripts that are sent to
the GDB debugger upon debugger start. The scripts can contain any GDB or
GDB server commands that are compatible with the application, JTAG
probe and target board. The Startup Script tab is also where GDB script
programs are defined.
For more information see The Startup Script chapter at page 227.
The Target Hardware Initialization tab is for the script used to initialize the
hardware and the Target Software Startup Scripts tab is for the scripts
used to initialize the software.
223 | P a g e
Debugging
To do that, open a command console window and change folder to the folder where the
GDB server is located (%INSTALLATION_DIR%\Servers\Selected Server).
224 | P a g e
Debugging
Open the debug configuration for the project and in the Debugger tab change the GDB
connection setting to be Connect to remote GDB server.
If the setting is made correctly when starting a debug session, some logging will be seen in
the command console window.
Please note that the JTAG Interface must be selected in the Debug Configuration for JTAG
Scan Chain to work.
In most cases, Atollic TrueSTUDIO is able to automatically detect these settings, in which
case the Auto option has been selected.
225 | P a g e
Debugging
If manual configuration is required, please select the Manual option. Then select Position
and IRPre for each core.
If a Segger JTAG Probe is used, more information can be found in the J-Link User Guide,
section 5.3.1 and 5.3.3, included with the Atollic TrueSTUDIO installation. It can be found
by selecting the Information Center toolbar button and open the Information Center
view. Locate Document center, Debugger utilities in the Information Center and press the
J-Link User Guide link.
For more information, please refer to the documentation from the debugger probe
manufacturer, microcontroller manufacturer and/or the manufacturer of the target board.
226 | P a g e
Debugging
More about the GDB script commands can be found in the Debugger manual bundled with
Atollic TrueSTUDIO and found in the Information Center.
It is possible to edit the script with the GDB commands needed to start the Debugging in a
proper way.
227 | P a g e
Debugging
Complete symbolic information is emitted by the tool chain to help the user
navigate the information in the source code, during the debug process.
After switching from the Debug to the Release build configuration, the target board can be
programmed by launching a debug session. During this process, caution must be executed
to prevent unexpected results from occurring.
The Atollic TrueSTUDIO philosophy of determining which executable image will be loaded
into the target, with the current project settings, must be considered carefully.
This brings up the list of existing debug launch configurations. By right clicking on an
existing configuration, the options to create a new configuration, duplicate the existing, or
delete it, appears.
The easiest way to create a new configuration is to duplicate an existing one, edit the
configuration settings in the dialog box, and then rename it. In this way multiple debug
launch configurations are easily created. The user may toggle among the debug launch
configurations in the list, and launch the most suitable session for the task at hand.
If the user does not explicitly choose a debug launch configuration from the existing list,
Atollic TrueSTUDIO launches the most recently used debug launch configuration.
Assume that a user has created a build configuration named Debug, and a debug launch
configuration that loads the ELF-file, created by the Debug build, to the target. Assume
further that the user launches a debug session to debug this ELF-file.
228 | P a g e
Debugging
Following this, the user switches to the build configuration named Release, and launches a
new debug session by clicking on the debugging icon. Atollic TrueSTUDIO will fetch the
most recent debug launch configuration, which specifies that the ELF-file from the Debug
build configuration, and not the Release ELF-file, is to be programmed into the target.
Atollic TrueSTUDIO has no means of automatically selecting the ELF-file associated with
the currently active build configuration (Debug or Release), when a debug session is
started. The build image used will always be the one specified in the debug launch
configuration, regardless of the active build configuration.
This behavior is different from some other development environments that automatically
reconfigure the debug launch mechanism, to use the ELF-file from the currently active
build configuration.
In Atollic TrueSTUDIO, the user must create a debug launch configuration that explicitly
refers to the particular ELF-file that is to be loaded, when a debug session is started.
Example: The user generates a project from the Project Wizard and builds an ELF-file using
the build configuration named Debug. The debug session configuration dialog box shows
the location of the ELF-file:
To create a debug launch configuration that refers to the Release ELF-file, instead of the
Debug ELF-file, simply change Debug in the above path to Release. It is recommended to
rename the debug launch configuration to clearly mark it as a Release configuration.
To load the Release ELF-file into the target, start a debug session based on this debug
launch configuration.
If desired, other properties of the new debug launch configuration can be edited as well.
For example, setting the temporary breakpoint at the first line of main(), may be
omitted by inserting a comment on the corresponding line in the GDB initialization script.
This is done via the Debug dialog box, in the Startup Scripts, Target Software Startup
Scripts panel.
229 | P a g e
Debugging
It is possible to use different variables in the path to the binary. They can be accessed by
pressing the Variables… button.
One such variable is ${build_configuration}. When using it in the path Atollic
TrueSTUDIO will attempt to determine the name of the active Build Configuration
(normally Debug or Release) and replace the variable with that string. This can be used to
create a generic Debug Configuration that can be used in all debugging for all Build
Configurations.
In the Debug Configurations dialog there is a Common tab. In this tab the Save as
selection is used to select to save the debug launch configuration as Local file or as Shared
file. Normally in projects created with TrueSTUDIO project wizard the selection is set to
save as Shared file. The file will then be located by default in the Project folder in the
workspace. This makes it easier to export or store the debug configuration setting into a
version control system.
230 | P a g e
Debugging
In this way it is possible to have x number of debug launch configurations saved in the
project. Each file will be named according to the debug configuration name you specify
plus extension. E.g. File name: STM32F3_Discovery.elf.launch
When save as Local file is configured the debug configuration will be saved in the
workspace instead. E.g. File name:
C:\TrueSTUDIO\ARM_workspace_5.3\.metadata\.plugins\org.eclips
e.debug.core\.launches
231 | P a g e
Debugging
232 | P a g e
Debugging
DEBUGGING
Once the debug session has been started, Atollic TrueSTUDIO switches automatically to
the Debug perspective, sets a breakpoint at main(), resets the processor, and executes the
startup code until execution stops at the first executable program line inside main().
The Debug perspective is now active. The next program line to be executed is highlighted
in the source code window. A number of execution control functions are available from
the Run menu:
Alternatively, the execution control commands are available in the Debug view toolbar.
233 | P a g e
Debugging
DISASSEMBLY VIEW
A common user action, not available from the Run menu, is to switch between C/C++ level
stepping in the C/C++ source code window, and assembler level instruction stepping in the
Disassembly view.
Click on the instruction stepping button to activate assembler level instruction stepping in
the Disassembly view. Click it once more to return to C/C++ level stepping in the C/C++
source code window.
234 | P a g e
Debugging
By right-clicking in the left part of the view, the Function Offset can also be displayed.
BREAKPOINTS
A standard code breakpoint at a source code line can easily be inserted by double-clicking
in the left editor margin, or by right-clicking the mouse in the left margin of the C/C++
source code editor. A context menu will appear in the latter case.
Select the Toggle Breakpoint menu command to set or remove a breakpoint at the
corresponding source code line.
More complicated types of breakpoints, such as Watch Points and Event Breakpoints (for
PC projects) are configured in the Breakpoints view.
235 | P a g e
Debugging
Since this is handled by the GDB server, it is handled slightly different depending on what
GDB server is used.
For example: the ST-Link GDB server only uses hardware breakpoints, and is therefore
limited to 6 breakpoints.
The SEGGER J-Link GDB server uses both hardware and software breakpoints depending
on the number of breakpoints that the user want to set.
The SEGGER J-Link GDB server should therefore be able to support virtually unlimited
number of breakpoints using software breakpoints. But even here there is no manual
control whether the breakpoint should be set as software or hardware breakpoint.
CONDITIONAL BREAKPOINT
When setting a normal breakpoint the program will break each time reaching that line. If
that is not the desired behavior a condition can be set on the breakpoint that regulates if
the program should actually break or not on that breakpoint.
Set a breakpoint at a line. Right-click it and open the Breakpoint Properties... The
Breakpoint Properties can also be opened from the Breakpoints view.
Enter a condition. In the example below “g1==100” is a global variable, but the variable
can also be a local stack variable.
236 | P a g e
Debugging
What happens when running now is that the gdbserver will break each time the line is
executed but gdb will test the condition and restart running if the variable g1 not is equal
to 100. This method could be used when debugging an RTOS with several tasks if the RTOS
kernel has a variable that the Breakpoint condition could be tested on to see which task is
running. The only problem with this method is that it takes some time for GDB to evaluate
the condition.
EXPRESSIONS
The Expressions view displays many different types of data, including global variables,
local variables and CPU core registers. The Expressions view also allows users to create
mathematical expressions that are evaluated automatically, such as (Index * 4 + Offset).
An expression is displayed in many formats simultaneously, and the view can parse
complicated data types and display complex data types like a C-language struct.
Furthermore, CPU core registers may be added to the view, in addition to local and global
variables. Open the Register view and select Watch to add the register to the Expressions
view.
237 | P a g e
Debugging
The users may drag and drop variables from the editor into the Expressions view. This
applies to complex data types as well.
The value of variables and writeable registers may also be changed via the Expressions
view.
By starting an expression with “=” regular expressions can be used to display collapsible
groups of local variables and arrays.
By starting an expression with “=$” pattern matched groups of registers can also be
created.
LIVE EXPRESSIONS
The Live Expressions view works a lot like the Expression view with the exceptions that all
the expressions are sampled live during the debug execution.
The view displays many different types of global variables. The Expressions view also
allows users to create mathematical expressions that are evaluated automatically, such as
(Index * 4 + Offset).
238 | P a g e
Debugging
An expression is displayed in many formats simultaneously, and the view can parse
complicated data types and display complex data types like a C-language struct.
Only one format of numbers is used at the same time to speed up the sampling. To change
the format, use the dropdown arrow.
The Live Expressions view requires a Segger J-Link probe and a Segger J-Link
GDBServer v4.78h or later.
To be able to use the Live Expressions view during debugging the Live
Expression mechanism has to be enabled during startup. This is by default
enabled when Segger J-Link probe is selected in the debug configuration.
Please read the Starting the Debugger section for more information.
LOCAL VARIABLES
The Variables view auto-detects and display the value of local variables. It provides
extensive information about each variable, such as value in hex/dec/bin format. The
content of complex variable types is also displayed.
239 | P a g e
Debugging
The location column can be displayed by selecting the small arrow in the upper right
corner and then layout, Select Columns… A dialog with the selectable columns will then
open up.
From the same small arrow, the Number Format can also be changed for the Value
column.
Bi right clicking a variable, it can also be opened in the Memory view and also by selecting
Watch to the Expression View.
Global Variables cannot be displayed in the Variables view. Use the Expression
view instead. See page 237 - Expressions for more information.
240 | P a g e
Debugging
The Memory Fill dialog is opened when the toolbar button is pressed.
The filled area is up to, but not including, the end address.
SFRS
Special Function Registers (SFRs) can be viewed, accessed and edited via the SFRs view.
The view displays the information for the current project. It will change its content if
another project is selected. To open the view, select the View, SFRs menu command.
241 | P a g e
Debugging
The SFRs view can also be useful in the C/C++ Editing Perspective, however
then only the names and addresses of the registers will be displayed.
242 | P a g e
Debugging
The top of the SFRs view contains a search field to filter visible nodes, e.g peripherals,
registers, bit fields. When some text is entered in the search field only the nodes
containing this text will be visible. When the node to view is found, select the node, then
press the Clear button to the right of the search field if all elements shall be seen.
The information at the end of the SFRs view displays detailed information of the selected
line. For registers and bit fields this include information of Access permission and Read
action.
RO (read-only)
WO (write-only)
243 | P a g e
Debugging
RW (read-write)
W1 (writeOnce),
RW1 (read-writeOnce)
The Read action contains information only if there is some kind of read action when
reading the register/bit field:
clear
set
modify
modifyExternal
The toolbar buttons are found at the top right corner of the SFRs view.
The RD button (A) is used to force a read of the selected register. This will cause a
read of the register even if the register, or some of the bit fields in the register,
contains a ReadAction attribute set in the SVD file.
When the register has been read by pressing the RD button all other registers
visible in the view will also be read again to reflect any other register updates.
The program needs to be stopped to perform a read of the registers.
Base format buttons (B) are used to change what base the registers values are
displayed in.
The Configure SVD settings button (C) opens up the CMSIS-SVD Settings
Properties Panel for the current project.
244 | P a g e
Debugging
Two CMSIS-SVD (System View Description) data files can be pointed out for the project. All
SVD-files must comply with the syntax as outlined in the CMSIS-SVD specification found on
ARM® website. If this requirement is not met, the SFR-view is likely not to show any
register information.
The Device file field is typically used to for the System View Description (SVD) file. This file
should include the information for the whole device. Other views may fetch information
from the SVD file pointed out by this field, therefore Atollic recommends only using this
field for SVD-files containing full system description. Updated SVD files can be obtained
from STMicroelectronics, see the HW Model, CAD Libraries and SVD in the device
description section on the ST web-site.
The Custom file field can be used to define special function registers related to custom
hardware, in order to simplify the viewing of different register states. Another possible use
case is to create a SFR favorites’ file, containing a subset of the content in the Device file.
This subset may be frequently checked or registers. If a Custom file is pointed out a new
top-node in the SFR-view will be created containing the Custom file related register
information.
Both fields may be changed by the user and both fields may be used at the same time.
FAULT ANALYZER
The Fault Analyzer view helps developers to identify and resolve hard-to-find system faults
that occur when the CPU has been driven into a fault condition by the application
software. The fault analyzer feature interprets information extracted from the Cortex-M
nested vector interrupt controller (NVIC) in order to identify the reasons that caused the
fault.
Within the debugger, after a fault has occurred, the code line where the fault occurred will
be displayed. The user can view the reasons for the error condition. Faults are broadly
categorized into bus, usage and memory faults.
Bus faults occur when an invalid access attempt is made across the bus, either of a
peripheral register or a memory location.
Usage faults are the result of illegal instructions or other program errors.
245 | P a g e
Debugging
To further aid fault analysis, an exception stack frame visualization option provides a
snapshot of the MCU register values at the time of the crash. Isolating the fault to an
individual instruction allows the developer to reconstruct the MCU condition at the time
the faulty instruction was executed.
In the Debugger perspective the Fault Analyzer view is opened from the menu. Select the
menu command View, Fault Analyzer or use the toolbar icon Show View to open a drop
down list; then select Fault Analyzer.
Below is an example of the Fault Analyzer view when an error has been detected. In this
case the error was caused by a project which configured the stack to be placed outside the
RAM of the Cortex-M4 device. This causes a Hard Fault Detetected and the Bus Fault
Details present the Stacking error (STKERR). The Register Content During Fault Exception
presents the sp value 0x2003ffd8 and this device only had RAM available from 0x20000000
to 0x2001ffff.
246 | P a g e
Debugging
TERMINAL VIEW
A terminal is included to allow I/O communication with target using Local, SSH, Serial, and
Telnet Terminal communication.
247 | P a g e
Debugging
It can be located by selecting the Open View toolbar button and then select Serial
Terminal in the dropdown list.
To start using the terminal, press button A. This will open up the Terminal Settings Dialog.
Select what type of connection is preferred. That will most likely be Serial communication.
248 | P a g e
Debugging
For more information for how to redirect the I/O to the Terminal, see the chapter about
I/O Redirection on page 160.
3. Make sure that these folders are treated as source code folders by right-clicking on
the c-file or the folder then select Resource configuration, Exclude from build… and
Deselect all.
4. Setup include paths by select in the menu Project, Build Settings, Tool Settings, C
Compiler, Directories and add all headers
5. Exclude the main.c supplied in the TrueSTUDIO example project. Also exclude the
tiny_printf.c and the syscalls.c (if available). This since RTT will override some
of these implementations.
6. The RTT-pack comes with three different demonstration examples. This means 3
different main() implementation. Make sure only one is built. Again for these (2 of
these 3) source files use: right-click on the c-files, Resource configuration, Exclude
from build… and Select all.
7. Please note that for some versions of the example package the SEGGER_RTT_printf()
contains a bug. The va_start() call must always be followed by a va_end call. The
function might then look like this:
va_start(ParamList, sFormat);
ret = SEGGER_RTT_vprintf(BufferIndex, sFormat,
&ParamList);
va_end(ParamList);
return ret;
}
8. Build and start a debug session. Open the “Terminal”-view. Setup a connection:
Encoding: ISO-8859-1
Host: localhost
249 | P a g e
Debugging
Port: 19021
Ok
250 | P a g e
Debugging
Finding the root cause of the problem in case of a CPU crash is further simplified by
learning how to use the Fault Analyzer view, see page 245.
This method is applicable to any Atollic TrueSTUDIO user who has a SEGGER J-Link/Trace
debugger. Before trying this approach consider whether halting the application in the
wrong state could potentially harm the hardware (i.e. in the case of a motor controller
application). Why? When GDB connects to the SEGGER J-Link GDB-server the target CPU
will be halted. This behavior is currently not possible to change and applies even if the
GDB-server is started with the -nohalt option.
It is quite simple to make Atollic TrueSTUDIO connect using a SEGGER J-Link. Essentially
the following three or four steps are needed:
4. Optionally analyze the CPU fault condition with the Fault Analyzer tool
The default generated debug configurations in Atollic TrueSTUDIO contains the GDB
commands needed to setup target communication speed, to flash and reset the device
and to set some breakpoints. This is not of any use to us when we want to connect to a
running system which may, or may not, have crashed. Therefore the first step is to make
sure that we have a debug script that will not accidentally flash or reset your CPU, which
could be very annoying when you finally have managed to trigger a crash behavior which
has been difficult to track down.
2. In the left frame of the Debug Configurations GUI, select the debug configuration
associated to the project/application that you want to debug and make a copy of
this by right-clicking it and click Duplicate
4. Go to the tab called Startup Script, Target Software Startup Script, Debug
251 | P a g e
Debugging
5. Use the # (hash-key) to comment out all GDB-commands or simply delete all
commands. See picture below.
Connect the J-link to the computer. Then connect it to the embedded target. No reset
should be issued.
Important! Do not make the mistake of launching the debug session using the wrong
debug configuration, that will probably flash and reset the target.
Instead the safest way to launch a debug session with full control of which debug
configuration is applied (and thereby preventing a potential reset) is by using the menu
selection Run, Debug Configurations... Then select the modified debug configuration in
the left frame and click Debug.
252 | P a g e
Debugging
Voilà - the debugger should now be connected to the embedded target which is
automatically halted. At this point different status registers and variables can be
investigated in the application. If the CPU has crashed, then also use the Fault Analyzer to
better understand what went wrong, why and where.
253 | P a g e
Debugging
254 | P a g e
Debugging
Note! If the debugging is stopped in a sudden way, the actual GDB Server
process might still be running without doing anything but eating up CPU
power and hanging the TCP/IP port. Please make sure that no process name
“arm-atollic-eabi-gdb.exe” is running when encountering this problem. It will
also eat up the memory and eventually nothing will work on the computer.
255 | P a g e
Debugging
Then change the setting that points out where the server is stored. Select the top-menu
Window, Preferences and then open Run/Debug, Embedded C/C++ Application, Debug
Hardware, and the name of the GDB probe used. The path to the newly installed GDB
server can be entered there.
256 | P a g e
Debugging
Open a command window (cmd) in Windows and move to the folder for the installed GDB
server:
JLINK.exe
Now there should have a new icon in Windows Notification Area (by default in the lower
right corner in Windows) for Segger J-Link GDB server. Right click to open it. The Control
panel for the GDB server will then be opened.
A good idea is now to in the General tab deselect Start minimized and Always on top.
257 | P a g e
Debugging
What does not happen is if the program alters the flash contents, the Memory panel does
not reflect that.
To fix this go to the Settings tab and deselect the Allow caching of flash contents.
2. Then open the Settings tab and enter a name of a log file.
4. The GDB server should now save information in the new log file.
258 | P a g e
Debugging
Then start the GDB server manually from the command line.
259 | P a g e
Debugging
1. First the program needs to be located into the RAM so the program needs to fit
into the RAM. In most cases microcontrollers have a smaller RAM compared to
the size of the FLASH so unfortunately in many cases it will not be possible to
have the complete program, data and stack stored into RAM.
2. Normally for Cortex-M based devices there is a need to set the Vector Base
Register (VBR) to the location in RAM where the interrupt vector is located. The
Cortex-M0 core does not have any VBR so when a microcontroller which is based
on Cortex-M0 is used it will not be possible to use any interrupts when code is
located to RAM.
Some STM32-EVAL boards have special Mode switches which shall be set in
RAM mode if debugging in RAM. This is a solution in STM32 to configure the
device so that it uses address 0x20000000 as the base of interrupt vector. In
that case there is no need to setup the vector base register to the RAM start
address offset when the Mode switches are in RAM mode.
3. When debugging in RAM the gdb script which loads the code must not have a
monitor reset command after the load command. Remove the monitor reset
command after the load command and gdb will set the Program Counter to the
entry of the program which has been loaded.
If there is a monitor reset command after load a reset will be issued and the
code will then execute from FLASH.
260 | P a g e
Debugging
In Atollic TrueSTUDIO this will typically require only running one instance of Atollic
TrueSTUDIO containing one project for each microcontroller.
The default port to be used for Segger J-Link is 2331 and for ST-Link 61234. This is
presented in the Debugger tab in the Debug Configurations dialog. The developer needs to
change the port for one of the projects to use another port, e.g. port 2341.
The developer needs to be quite fast to make the selection here and start the GDB server.
When the selection is made, the GDB server will start and connect to the board using the
selected probe and GDB will connect to the GDB server.
If this selection is not made fast enough the debug session in Atollic TrueSTUDIO will
timeout because there was no server to connect to.
When the Debug Configuration has been configured for both projects so that each board is
associated to a specific probe, the user may try to debug each board individually first.
When it is confirmed that this is working it is time to debug both targets at the same time.
Proceed as follow:
1. First start to debug HW_A.
2. The developer will automatically be switched to the Debug Perspective in Atollic
TrueSTUDIO when a debug session is started. Switch to C/C++ Perspective.
3. Select the project for HW_B and start debugging this. The Debug perspective will now
open again.
4. There will be two application stacks/nodes in the debug view: One for each project
(hardware). When changing selected node in the Debug view the depending editor,
variable view etc. will be updated to present information valid to the selected
project/board.
261 | P a g e
Debugging
If Connect to remote GDB server is selected, the developer must start the GDB server
manually before starting the debug session.
To start Segger J-Link GDB server manually please follow this procedure:
2. Change directory to the location where the GDB server is located, normally to:
C:\Program Files (x86)\Atollic\TrueSTUDIO for STM32 9.0.0\Servers\J-
Link_gdbserver
3. Start the GDB server: E.g start using port 2341 with SWD interface mode:
JLinkGDBServerCL.exe -port 2341 -if SWD -select usb=123456789
(The 123456789 is serial number of dongle.)
Start another GDB server in a second command prompt, using another port number in a
similar way and let this connect to the second probe.
Now when both GDB servers are running the developer can debug the two projects
individually or multi-target. Please note that the Debug Configurations needs to use the
same port as the GDB server is listening on and Connect to remote GDB server shall be
used.
262 | P a g e
Introduction
BUILD ANALYZER
This section provides information on how to use the Atollic TrueSTUDIO Build Analyzer view.
263 | P a g e
Build Analyzer
The view contains two tabs. The Memory Regions tab and the Memory Details tab.
The Memory Regions tab is populated with data if the .elf file contains a corresponding
.map file. When the .map file is available this tab can be seen as a brief summary of the
memory regions with information about region name, start address and size. The size
information also comprises total size, free and used part of the region, and a usage
number in percentage.
The Memory Details tab contains detailed program information based on the .elf file.
The different section names are presented with address and size information and each
section can be expanded and collapsed. When a section is expanded functions/data in this
section is listed (green icons are used to show function names and blue icons are used for
data variables). Each presented function/data contains address and size information. The
memory details tab also contain information for object files, .o files, when such files are
selected.
When there is a need to optimize or simplify a program the Build Analyzer view is good to
use when there is a need to optimize or simplify a program.
264 | P a g e
Build Analyzer
When the Build Analyzer view is open select an .elf or an .o file in the Project Explorer
view. The Build Analyzer view will then be updated with the information it founds in the
file. When an .elf file is selected and a .map file, with similar name, is found in the same
folder also information from the .map file is used by the view.
The Build Analyzer view will also be updated if a project node in the Project Explorer view
is selected. In this case the Build Analyzer uses the .elf file which corresponds to the
current active build configuration for the project. The view only provides information for
embedded projects so it will be empty for PC projects.
MEMORY REGIONS
The Memory Regions tab of the Build Analyzer view displays information based on the
corresponding .map file. If no information is displayed there is no corresponding .map file
found. When a .map file is found the Region names, Start address, End address, Total size
of region, Free size, Used size and Usage (%) information is presented.
These regions are normally defined in the linker script .ld file used when building the
program. If any changes of the location or size of a memory region needs to be done then
please update the linker script file.
265 | P a g e
Build Analyzer
The Memory Regions tab is empty if the .elf file does not have a
corresponding .map file. Memory Regions tab is also empty when a .o file is
selected.
The Usage (%) column contains a bar icon corresponding to the percentage value. The bar
has different color depending of the percentage of used memory:
MEMORY DETAILS
The Memory Details tab of the Build Analyzer view contains information for the .elf file.
The view can also display information about an object file, so if an object file is selected
the size information for the object file is updated.
Each section in the Memory Details tab can be expanded so that individual functions and
data can be seen. The table contains columns with Name, Run Address (VMA), Load
Address (LMA) and Size information.
266 | P a g e
Build Analyzer
Name Description
Run Address (VMA) The Virtual Memory Address contains the address used
when program is running.
Load Address (LMA) The Load Memory Address is the address used for load,
e.g. Initialization values for global variables.
SIZE INFORMATION
The size information in the Memory Details tab is calculated from the symbol size in the
.elf file. If a corresponding .map file is investigated this may contain a different size
value. Normally the size is correct for c-files but the value presented for assembler files
depends on how the size information is written in the assembler files. The constants used
267 | P a g e
Build Analyzer
by the function shall be defined within the .section definition. At the end of the section the
.size directive is used by the linker to calculate the size of the function.
.section .text.Reset_Handler
.weak Reset_Handler
.type Reset_Handler, %function
Reset_Handler:
ldr sp, =_estack /* set stack pointer */
CopyDataInit:
ldr r3, =_sidata
268 | P a g e
Build Analyzer
SORTING
The sort order of Memory Details tab can be changed by clicking on a column name.
E.g. Sort information by size:
269 | P a g e
Build Analyzer
270 | P a g e
Build Analyzer
271 | P a g e
Build Analyzer
272 | P a g e
Introduction
For example when making a copy of the selected lines in previous figure the copied
information will be:
"image1";"0x080c8000";"0x080c8000";"80000"
"image2";"0x080db880";"0x080db880";"52000"
".sound";"0x080f0000";"0x080f0000";"60000"
273 | P a g e
Introduction
274 | P a g e
Static Stack Analyzer
The view contains two tabs. The List tab and the Call Graph tab.
The List tab is populated with the stack usage for each function included in the program.
There is one line per function and each line consist of Function, Local cost, Type, Location
and Info columns.
The Call Graph tab contains an expandable list with functions included in the program.
Lines which are representing functions which are calling other functions can be expanded
to see the call hierarchy.
275 | P a g e
Static Stack Analyzer
The Static Stack Analyzer view will be populated when a project has been built and is
selected in the Project Explorer. The program needs to be built with option Generate per
function stack usage information enabled. Otherwise the view will not be able to present
any stack information.
276 | P a g e
Static Stack Analyzer
FUNCTION COLUMN
Normally there is a small icon to the left of the function name in the Function column. The
icon is:
green dot when the function uses STATIC stack allocation (fixed stack)
blue square when the function uses DYNAMIC stack allocation (run-time
dependent)
010 icon is used if the stack information is not known. This can be the case for
library functions or assembler functions.
Three arrows in a circle are used in the Call Graph view when the function makes
recursive calls
277 | P a g e
Static Stack Analyzer
DEPTH C OLUMN
The Depth column specifies the call stack depth this function uses
? when function makes recursive calls or the depth could not be calculated
TYPE COLUMN
The Type column specifies
Empty field (no stack usage information available for the function)
INFO COLUMN
The Info column contains specific information about the stack usage calculation. For
instance it can hold a combination of the following messages.
Max cost uncertain (the reason can be that the function makes a call to some
sub function where the stack information is not known or the function makes
recursive calls etc.)
No stack usage information available for this function (no stack usage
information available for this function)
Local cost uncertain due to dynamic size, verify at run-time (the function
allocates stack dynamically, e.g. depending on in parameter)
278 | P a g e
Static Stack Analyzer
LIST TAB
The List tab contains a list of all functions included in the selected program with options to
Hide dead code functions and to Filter visible functions.
The Hide dead code selection is used to enable or disable listing dead code functions.
The Filter field works in the way that when some characters are entered into the field only
functions matching the characters are displayed.
The column information in the List tab is described in the table below:
Name Description
Local cost The number displays how many bytes of stack the function
will use.
279 | P a g e
Static Stack Analyzer
By double-clicking on a line which displays the file location and line number in
the List tab, the function will be opened in the Editor view.
The Filter field works in the way that when some characters are entered into the field only
functions matching the characters are displayed.
The column information in the Call Graph tab is described in the table below:
Name Description
Max cost The number displays how many bytes of stack the function
will use including stack needed for called functions.
Local cost The number displays how many bytes of stack the function
will use.
280 | P a g e
Static Stack Analyzer
The main function is normally called by the Reset_Handler and can in those cases be
seen when expanding the Reset_Handler node. In this figure below the reset function
name is called ResetISR. By expanding the node it can be seen that the ResetISR calls
the main function which calls initLED and toggleLED functions. The local cost of stack
for the main function is in this case 16 and the max cost is 32 as the main function call
initLED and toggleLED functions which also consumes 16 bytes of stack.
By double-clicking on a line which displays the file location and line number in the tab, the
function will be opened in the Editor view.
The main function is normally called by the Reset_Handler and can in those
cases be seen when expanding the Reset_Handler node.
If unused functions are listed in the tab then please check if the linker option
dead code removal should be enabled to remove unused code from the
program. Read more on this in the Dead Code Removal chapter, page 121.
The next figure displays the List view using Filter field to see functions containing the
characters LED in the name.
281 | P a g e
Static Stack Analyzer
Another example is to use the Search field in the Call Graph tab. The function(s) matching
the search field is find, press Serch to find next function(s).
282 | P a g e
Static Stack Analyzer
For example when making a copy of the selected lines in previous figure the copied
information will be:
"STM_EVAL_LEDInit";"24";"STATIC";"stm32f4_discovery.c:122";""
"STM_EVAL_LEDOn";"16";"STATIC";"stm32f4_discovery.c:148";""
"SetSysClock";"16";"STATIC";"system_stm32f4xx.c:338";""
"SystemInit";"8";"STATIC";"system_stm32f4xx.c:204";""
"main";"16";"STATIC";"main.c:47";""
283 | P a g e
Getting Started
Statistical profiling
284 | P a g e
Serial Wire Viewer
Please note that the SWO is just one pin and it is easy to set a configuration that produces
more data than the SWO is able to send.
Serial Wire Viewer (SWV) provides the following types of target information:
Event counters
Based on this trace data, modern debuggers can provide developers with advanced
debugger capabilities.
285 | P a g e
Serial Wire Viewer
The ITM port has 32 channels, and by writing different types of data to different ITM
channels, the debugger can interpret or visualize the data on various channels differently.
Writing a byte to the ITM port only takes one write cycle, thus taking almost no execution
time from the application logic.
286 | P a g e
Serial Wire Viewer
The GDB server must also support SWV. The ST-LINK gdbserver must be of version 1.4.0 or
later, and the SEGGER J-LINK gdbserver must be of version 4.32.A or later. Older GDB
server versions that may be installed must be upgraded to the versions included in the
Atollic TrueSTUDIO product package in order to use SWV tracing.
To use SWV the board must support SWD. Please note that devices based on ARM Cortex-
M0 and Cortex-M0+ cores do not support SWV tracing.
287 | P a g e
Serial Wire Viewer
4. Enter the Core Clock frequency. This must correspond to the value set by
the application program to be executed.
5. Enter the desired SWO Clock frequency. The latter depends on the JTAG
Probe and must be a multiple of the Core Clock value. For Segger J-Link-
based probes, it is also possible to select Auto, which will automatically use
the highest available frequency by taking into account the capacity of the
JTAG Probe and the Core Clock.
288 | P a g e
Serial Wire Viewer
8. Open one of the SWV views. For first-time users, Atollic recommends the
SWV Trace log view because it will give a good view of the incoming SWV
packages and how well the tracing is working.
Thus, select the View, SWV, SWV Trace log menu command.
9. Open the Serial Wire Viewer settings panel by clicking on the Configure
Serial Wire Viewer button in the SWV Trace log view toolbar.
289 | P a g e
Serial Wire Viewer
290 | P a g e
Serial Wire Viewer
F. ITM stimulus ports – Enable one or more of the 32 ITM ports. The
most common way to use this is to send information
291 | P a g e
Serial Wire Viewer
Atollic recommends limiting the amount of data traced. Most ARM® -based
microcontrollers reads and writes data faster than the maximum SWO-pin
throughput. Too much trace data result in data overflow, lost packages and
possibly corrupt data. For optimum performance, trace only data vital to the
task at hand.
12. Press the Start/Stop Trace button to send the SWV configuration to the
target board and start SWV trace recoding. The board will not send any
292 | P a g e
Serial Wire Viewer
13. Start the target execution again by pressing the green Resume Debug
button.
14. Packages should now be arriving in the SWV Trace Log view (and possibly
other views too, dependent on trace configuration).
Collected data can be cleared by pressing the Empty SWV-Data button. All
the timers are also restarted when this button is pressed.
293 | P a g e
Serial Wire Viewer
SWV Trace Log - Lists all incoming SWV packages in a spreadsheet. Useful as
a first diagnostic for the trace quality. The data in this view can be copied to other
applications in CSV-format by selecting the rows to copy and type Ctrl+C. The
copied data can be pasted into another application with the Ctrl+V command.
SWV Exception Trace Log – The view has two tabs. The first is similar to the
SWV Trace Log, but is restricted to Exception events and also has additional
information about the type of event. The data can be copied and pasted into
other applications. Each row is linked to the code for the corresponding exception
handler. Double click on the event and the corresponding interrupt hander source
code is opened in the editor view.
The second tab displays statistical information about the Exception events. This
information may be of great value when optimizing the code. Hypertext links to
exception handler source code in the editor is included.
SWV Console - Prints readable text output from the target application.
Typically this is done via printf() with output redirected to ITM channel 0. Other
ITM channels can get their own console view too.
SWV Data Trace – Tracks up to four different symbols or areas in the memory.
For example, global variables can be referenced by name.
294 | P a g e
Serial Wire Viewer
SWV Data Trace Timeline Graph – A graphical display that shows the
distribution of variable values over time. Applies to the variables or memory areas
in the SWV Data Trace.
More than one SWV view may be open at the same time, for simultaneous tracking of
various events.
295 | P a g e
Serial Wire Viewer
Any graph can be saved as an image file by clicking the camera icon.
The zoom range is limited while debugging is running. More details are available
when debugging is paused.
Zoom in: Double-click on the left mouse button. Zoom out: Double-click on the
right button or use the corresponding toolbar buttons in the view.
The tooltip shows the number of packages in each bar. Except for the Trace
Timeline Graph, the content of bars with less than 50 packages is showed in a
detailed view.
The Data Trace Timeline displays distinct values for variables during execution and
has different features than the above graphs.
STATISTICAL PROFILING
This is a way to obtain information about the amount of execution time spent within
various functions. It is not based on code analysis but on statistical information regarding
the part of the code executed. This is a technical limitation of the SWV protocol.
296 | P a g e
Serial Wire Viewer
3. Push the red Start/Stop Trace button to send the configuration to the
board.
4. When you start executing code in the target system, Atollic TrueSTUDIO
starts collecting statistics about function usage via SWV.
5. Suspend (Pause) the debugging. The collected data is displayed in the view.
The longer the debugging session, the more statistics will be collected.
297 | P a g e
Serial Wire Viewer
EXCEPTION TRACING
To make it possible to trace the exceptions encountered during execution, the exception
packages needs to be enabled. Open SWV Configuration as described above.
Enable EXETRC: Trace Exception. This will generate Trace Exception packages. Disable all
other packages not needed at the moment.
EXCEPTION DATA
The exception packages are displayed in the SWV Exception Trace Log view. The view has
two tabs, the Data tab and the Statistics tab.
By double-clicking on an entry in the tab, the function will be opened in the Editor if it is
available in the source code.
298 | P a g e
Serial Wire Viewer
Name Description
Index The Id for the exception package. Are shared with the
other SWV packages.
EXCEPTION STATISTICS
The exception statistics is collected whenever Exception packages are received by SWV. It
can be found in the SWV Exception Trace Log view, in the Statistics tab.
299 | P a g e
Serial Wire Viewer
The statistics can be access by selecting the Statistics tab in the view.
By double-clicking on an entry in the tab, the function will be opened in the Editor if it is
available in the source code.
Name Description
% of exception time How big part of the execution time for all exceptions that
this exception type have.
% of debug time How big part of the total execution time for this debug
session that this exception type have. All the timers are
restarted when the Empty SWV-Data button is pressed.
Total runtime The total execution time in cycles for this exception type.
Avg runtime The average execution time in cycles for this exception
type.
300 | P a g e
Serial Wire Viewer
Name Description
type in cycles.
301 | P a g e
Serial Wire Viewer
In the Project explorer, right click on the project and select New, Other...
Expand System calls.
Select "Minimal System Calls Implementation" and click next.
Click Browse... and select the src folder as new file container and click OK.
Click on Finish and verify that syscalls.c is added to the project.
3. Next step is to locate the core_cmX.h file which contains the function
ITM_SendChar(). The core_cmX.h file is included by the Device
Peripheral Access Layer Header File (i.e. stm32f4xx.h). That file in turn
needs to be included in the syscalls.c file.
If uncertain about where to find the Device Peripheral Access Layer Header
File, use the Include Browser. Drop the core file in the Include Browser
view, and check that which files are including the core_cmX.h file.
302 | P a g e
Serial Wire Viewer
Select the menu command Widows, Preferences. In the dialog select Run/Debug,
Embedded C/C++ Application and then Serial Wire Viewer.
The buffer is stored in the heap. The allocated heap is displayed by first selecting Window,
Preferences and General; then enabling “Show heap status”. The current heap and
allocated memory will be displayed in the lower, right corner.
There is an upper limit to the amount of memory Atollic TrueSTUDIO can allocate. This
limit can be increased to store more information during a debug-session.
Proceed as follows:
303 | P a g e
Serial Wire Viewer
The Core Clock of the target is incorrectly set. It is very important to select the
right Core Clock. If the frequency of the target Core Clock is unknown, it can
sometimes be found by setting a breakpoint in a program loop and open the
Expressions View, when the breakpoint is hit.
Click on Add new expression, type SystemCoreClock and press Enter. This
is a global variable that according to the CMSIS-standard must be set to the
correct speed of the Core Clock.
For most devices that do not have libraries that follow the CMSIS-standard, the
Core Clock can be found in the startup code. It is often named SYSCLK, or a
similar abbreviation. Also note that if software dynamically change the CPU clock
speed during runtime, then SWV might stop as the clocking suddenly becomes
wrong during execution.
The SWV configuration has not been sent to the target board.
Some manufacturers, such as Energy Micro, disable SWO pin by default. In this
case, enable SWO with a function-call, such as DBG_SWOEnable().
The SWO receives too much data. Reduce the amount of data enabled for tracing.
The JTAG Probe, the GDB server, the target board, or possibly some other part,
does not support SWV.
Open the SWV configuration. Disable all tracing except PS Sampling and
Timestamps. Set the Resolution to the highest possible value.
Start tracing.
Make sure that incoming packages can be seen in the SWV Trace Log.
304 | P a g e
Getting Started
MTB TRACING
(CORTEX-M0+)
This section provides information on how to use the CoreSight Micro Trace Buffer (MTB)
which is a simple execution trace block available on some Cortex-M0+ devices.
Introduction to MTB
Configure MTB
Using MTB
305 | P a g e
MTB Tracing
INTRODUCTION TO MTB
The CoreSight Micro Trace Buffer (MTB) is an optional hardware included on some Cortex-
M0+ processor based devices. MTB contains a simple execution trace block which can log
trace information in a memory buffer in the processor RAM. The buffer location and size
are configurable. Currently STM32 microcontrollers does not include MTB support.
The MTB Tace Log view in Atollic TrueSTUDIO is used to configure MTB and view
instruction trace data from the device. As the trace data is stored in the processor RAM
the MTB Trace Log view does not need any special debug probe. A normal debug
connection works fine and it works both in Serial Wire Debug mode and in JTAG Debug
mode.
The MTB execution trace packet consists of a pair of 32-bit words generated by the MTB
when it detects a branch instruction or an exception entry. The trace packet consist of a
source address (current PC location) and a destination address (next PC address). The MTB
module stores all such branches into the processor RAM.
Open the MTB Trace Log view, for instance by writing MTB in the Quick Access field in the
toolbar and select views MTB Trace Log. The MTB Tace Log view reads the trace packets
from the processor when the program is stopped and then visualize the executed
instructions using program information from the .elf file.
306 | P a g e
MTB Tracing
CONFIGURE MTB
The MTB must be configured before it can be used. Buffer locations and buffer size needs
to be set and it is also possible to configure specific behavior on MTB when buffer is full.
Configuration of MTB is done after a debug session is started.
Open the Configure MTB Trace dialog box by clicking on the Configure MTB Trace Setting
button in the MTB Trace Log view toolbar.
In the Configure MTB Trace dialog configure the Buffer location and Buffer size and the
trace operation to be used when/if trace buffer is full. The addresses where to store the
configured data is read from the device CMSIS-SVD file. The CMSIS-SVD file needs to have
a MTB node including information about the POSTION, FLOW, MASTER, and BASE
registers. The reason to read the CMSIS-SVD file to get this information is because the
location of MTB registers on the Cortex-M0+ device is defined by the chip manufacturer
when designing the chip. The MTB Trace Log view updates these registers to control the
behavior of the trace features.
If a Cortex-M0+ device is used which includes MTB but does not have these registers
specified in the CMSIS-SVD files the registers can be added into a custom CMSIS-SVD file.
Make sure to add an MTB node in this custom file containing information about the
POSTION, FLOW, MASTER, and BASE registers.
Please note, the buffer must be located to a memory area which is not used by the
debugged application. There are also some restriction on the buffer location and the
buffer size. For instance the size needs to be a power of 2. (e,g. 32, 64, 128, …) The
configuration dialog will signal if any errors in the settings is made. See example below
where wrong configuration is entered.
307 | P a g e
MTB Tracing
The MTB configuration is saved in the debug information for the project and reloaded when a new
debug session is started for the project.
308 | P a g e
MTB Tracing
USING MTB
Press the Start/Stop Tracing button to start/stop MTB trace. Actual tracing will not start
until the target starts to execute.
Note! If the Start/Stop MTB button is disabled, color grey, then the MTB
Trace Log view has not been able to detect that MTB is available for the
device when reading the CMSIS-SVD file. Please verify that the Cortex-M0+
contains MTB.
Please also investigate the CMSIS-SVD file which can be seen in the SFRs view.
If the MTB node is missing or if the necessary registers in the MTB view are
missing then create a custom CMSIS-SVD file containing these registers. If the
MTB node with registers are available in the file then please try to restart the
debug session again.
When trace is started the trace buffer in the processor will be automatically read by the
MTB Tace Log view each time the program is stopped, after a step, breakpoint executed or
processor stopped by some reason. Each time the buffer has been read by the the MTB
Tace Log view it will configure the CoreSight MTB unit to store next trace instruction data
at the start of the target trace buffer.
Start the target execution by pressing the green Resume Debug button or by issuing step
commands.
The MTB Trace Log view will be updated when new trace data is found in the target trace
buffer.
Collected data can be cleared by pressing the Clear the Buffer button.
The Scroll Trace on Update button is used to toggle if the view shall scroll when updated
with new data.
309 | P a g e
MTB Tracing
Name Description
Raw packet Packet information. E.g. If the Raw packet displays 0x752-
0x760 and then 0x744-0x74e. First time 0x752-0x760 is
displayed the MTB instruction log signals that an
instruction on 0x752 is executed. The MTB then signals at
0x760 that a branch is made to 0x744. The MTB Trace Log
view calculates the lines in between.
Table 9 – MTB Trace Log View Columns
310 | P a g e
MTB Tracing
The Additional column can also indicate “Trace buffer wrapped” which means that the
instruction trace buffer has been wrapped over. When this happens some trace data has
been lost since last run.
311 | P a g e
MTB Tracing
Select the lines to be copied (using Shift) and scroll down or mark all lines in the view
(using Ctrl+A). The marked lines are then copied in a comma separated list and placed in a
clipboard using Ctrl+C. The clipboard can be pasted into another file using an editor.
312 | P a g e
INSTRUCTION TRACING
This section provides information on how to do Instruction Tracing with Atollic TrueSTUDIO
for STM32.
Enable Trace
313 | P a g e
Instruction Tracing
INSTRUCTION TRACING
Atollic TrueSTUDIO supports instruction tracing, provided that trace-enabled hardware is
being used. Instruction tracing records the execution flow of the processor in real-time.
The recorded trace buffer can then be analyzed to locate the cause of software errors.
Instruction tracing is particularly useful when debugging problems that only occur
sporadically.
Atollic TrueSTUDIO supports instructing tracing using both the ETM and the ETB methods:
ETM tracing works with many Cortex-M devices but requires using an ETM-trace
enabled JTAG probe. Atollic TrueSTUDIO supports ETM tracing using the Segger J-
Trace JTAG probe. The J-Link and ST-LINK probes cannot be used for ETM tracing
as they have no trace buffer. The trace buffer in ETM-compatible trace probes are
typically many megabytes in size.
ETB tracing can only be used with Cortex devices that have this feature enabled in
the silicon. ETB tracing can be done using any of the supported JTAG probes,
including Segger J-Link, as the trace buffer is not located in the JTAG probe but
instead inside the target device. This adds to the chip cost and therefore is not
supported by all chip vendors. The on-chip ETB trace buffer is tiny; typically 2KB
or 4KB only.
Both ETM and ETB tracing records all executed machine code instructions, until the
hardware limits are reached. A trace buffer is filled very quickly even though it is highly
compressed. The compressed trace buffer in a JTAG probe with a 16MB of trace buffer
typically expands into 200MB of uncompressed machine readable data, and to 2-3GB of
human readable data. Instruction tracing thus quickly generates a huge amount of data.
ETM/ETB Trace may not work on max CPU clock speed. Please check the User
manual from the board/microcontroller manufacturer if there are any trace
clock limitations.
There is also a limitation of the clock speed for Segger J-Trace for Cortex-M
debug probe. This version of debug probe is specified up to 100 MHz trace
clock. This means that, as the trace clock usually is ½ of the speed of the CPU
clock, the max CPU clock speed is 200 MHz when using Segger J-Trace for
Cortex-M. For higher CPU frequencies, the Segger J-Trace PRO Cortex-M
should be used.
314 | P a g e
Instruction Tracing
The ETMv4 uses a much more complex and packed protocol than the ETMv3 and currently
Atollic TrueSTUDIO only supports basic instruction tracing for ETMv4 based devices.
Support for speculated execution and data tracing is not implemented yet and only RAW
and Assembly filtering levels in the Trace Log view can be used for Cortex-M7.
As mentioned earlier, the Segger J-Trace for Cortex-M debug probe is specified
up to 100 MHz trace clock which normally means that the speed of the CPU
clock can be up to 200 MHz. For higher CPU frequencies, the Segger J-Trace
PRO Cortex-M should be used.
ENABLE TRACE
Instruction tracing (using ETM or ETB) must be enabled in the debug configuration. To
enable instruction tracing, first open the debug configuration dialog box:
315 | P a g e
Instruction Tracing
1. In the Debug probe dropdown list, select Segger J-Trace (for ETM and ETB
tracing) or Segger J-Link (ETB tracing only).
2. In the Trace systems dropdown list, select the ETM or ETB trace system.
3. Ensure the Probe buffer size setting corresponds to the JTAG probe in use (ETM
tracing only).
4. For ETM tracing, make sure the Trace Port config selection points to a file that
setup the ETM trace pins of the device in a way that works for the target board in
use. The commands in the file are sent to the target when trace recording is
started first time in a debug session. See the section below for information on
how to write a new trace port configuration file for custom designed or
unsupported boards.
For ETM tracing it is also possible to Save raw ETM trace data to file. Such file
contains the raw trace data received from the Cortex-M device and the file can
be used for deeper investigation of trace data.
Atollic TrueSTUDIO comes with a readymade trace port configuration file for most of the
supported boards, but it is possible to edit them, or create new ones, to enable ETM
tracing on new boards. It is recommended to copy such readymade file to the Project or
some other folder on the files system if any changes are needed. Make the change in the
copied file and make sure to point to the correct file in the Trace Port Config selection in
the debug configuration.
if ($tracePortWidth == 1)
#Trace Port 1-bit configuration
#Enable trace in 1-pin mode
set *((unsigned long*) 0xE0042004) &= ~0x000000E0
set *((unsigned long*) 0xE0042004) |= 0x00000060
316 | P a g e
Instruction Tracing
317 | P a g e
Instruction Tracing
To configure trace, suspend the debug session and open the Trace Log view (Select View in
the top menu and then ETM/ETB, Trace Log).
In the Trace Log view toolbar, click on the Configuration toolbar button.
Configure the Trace Port Width dropdown list to match the number of pins used for ETM
tracing on the hardware board.
318 | P a g e
Instruction Tracing
Using the Stall processor on FIFO full checkbox, select one of these two options:
Stall the processor when the ETM trace FIFO buffer becomes full. With this
setting, no trace data is lost but the timing behavior of the application can be
changed.
Do not stall the processor when the ETM trace FIFO buffer becomes full. With this
setting, the processor will always continue to run at full speed but trace data may
be lost.
Some devices support timestamps. Enabling the timestamps can be useful if timing
information is needed. It will however reduce the amount of other information available.
There are four hardware triggers that can be set to starting and stopping the tracing on
different conditions.
To access them, open the Trace Configuration as above and select Add Trace Triggers…
319 | P a g e
Instruction Tracing
For each of the triggers 0-3, it is possible to define that the trigger shall start or stop
tracing, if its configured conditions are met. Each trigger has the following options:
Enter the address to trigger on in the Expression/Address field. This field accepts:
Typically, at least one trigger is configured to start tracing, and another trigger is
configured to stop tracing. Once the trace start and stop conditions have been configured,
click OK to save the trace trigger settings.
When using ETMv4 based devices, Cortex-M7, only PC triggered type of events
are supported. Data Read, Data Write, or Data Read/Write triggered events
are not supported.
320 | P a g e
Instruction Tracing
Right click on the ruler to the left in the editor window and select Add Trace Trigger.
A new trigger will be created and tracing starts to be collected when execution reaches
that line of code.
321 | P a g e
Instruction Tracing
From this view the triggers can easily be inactivated, activated, removed and even added.
Bear in mind that the hardware supports up to a maximum of four simultaneous Trace
Triggers.
With trace recording enabled, start target execution. When execution is suspended, the
Trace Log view is filled with the recorded instruction trace (provided the trace start trigger
condition was fulfilled).
322 | P a g e
Instruction Tracing
The Trace Log view shows detailed information on what the processor was doing up to the
point of suspending execution.
Please note the column with graphical icons that annotate the Trace Log view with
information about execution flow branches:
At the end of the view is the End of Trace marker displayed. This is added to the Trace Log
each time the buffer is overflowed and it indicates that some trace data most likely is lost.
323 | P a g e
Instruction Tracing
The other important marker is the Trace restarted marker. It indicates that the target
wasn’t able to generate all the trace information without affecting the performance of the
running application. Some data is lost.
To overcome this issue, enable Stall processor on FIFO full in the Trace Configuration.
Enabling Stall processor on FIFO full will slow down the processor in some
situation and hence affect the timing of the execution. For some real time
applications this is unacceptable.
DISPLAY OPTIONS
The Log Trace view supports several different display options:
C tracing
Assembler tracing
Use the different Display Options Toolbar Buttons to switch between the different view-
modes.
The Function call tracing displays what function the execution is in and from where it is
called or returned from.
When using ETMv4 based devices, Cortex-M7, only Assembler tracing and Raw
trace packet log are supported.
324 | P a g e
Instruction Tracing
Using the search feature it is possible to search for certain data of particular interest. For
example, assume a system crash sometimes happens because a variable has an illegal
value. By searching the instruction trace for the address of the variable, it is possible to
understand what code modifies the value and gives it the illegal value causing a system
crash.
The trace log can be saved to either comma separated value files (*.csv) that can be
imported into Microsoft® Excel®, or to human readable ASCII text files (*.txt).
Configure the trace record range to export using the From Index and To Index fields.
As the saved trace log becomes approximately 200 times larger than its compressed size in
the JTAG probe trace buffer, the saved trace log can optionally be split to many files in
order to avoid exported trace logs which are several gigabytes in size (for example, the
16MB compressed trace buffer in Segger J-Trace expands to 2-3GB when saved to a
human readable trace log file in *.CSV or *.TXT formats).
Select the file filename and folder to use for the export using the Browse button. In the
Save As dialog box, select the desired filename and folder, select *.CSV or *.TXT file
format, and click Save to return to the Export Trace dialog box. Click OK to start exporting
the trace log.
325 | P a g e
RTOS-Aware Debugging
RTOS-AWARE
DEBUGGING
This section provides information on how to debug Real Time Operating Systems (RTOS) with
Atollic TrueSTUDIO for STM32.
Segger embOS
Micrium uC/OS-III
Quadros RTXC
TOPPERS/ASP
326 | P a g e
RTOS-Aware Debugging
Several different Real Time Operating Systems are supported and the current state of the
RTOS kernel and the various RTOS kernel objects can easily be inspected in a set of
dedicated views, in the Atollic TrueSTUDIO Debug perspective.
327 | P a g e
RTOS-Aware Debugging
SEGGER EMBOS
The kernel awareness features for Segger embOS in Atollic TrueSTUDIO provide the
developer with a detailed insight into the internal data structures of the embOS kernel.
During a debug session, the current state of the embOS kernel and the various embOS
kernel objects such as tasks, mailboxes, semaphores and software timers, can easily be
inspected in a set of dedicated views, in the Atollic TrueSTUDIO Debug perspective.
REQUIREMENTS
The kernel awareness features require Segger embOS version 3.80 or later.
Please note that the level of information available in the different views in
Atollic TrueSTUDIO depends on the options used when the embOS kernel was
built. This manual refers to an embOS kernel built with the debug and
profiling (DP) build options. Please note that microcontrollers based on the
ARM-cores Cortex-M0 and Cortex-M0+ do not support Serial Wire Viewer
tracing.
These views can be opened from the Show View toolbar dropdown list button.
328 | P a g e
RTOS-Aware Debugging
SYSTEM INFORMATION
The embOS System Information view displays a number of system variables available in
the embOS kernel, such as status, number of tasks, etc.
This view also provides descriptive fault information messages for any fault conditions
detected by the OS kernel.
329 | P a g e
RTOS-Aware Debugging
Name Description
OS_pCurrentTask The address (TCB) and name of the currently running task.
OS_pActiveTask The address (TCB) and name of the next running task.
embOS build The build options of the currently running embOS kernel.
In the example, debugging and profiling information (DP)
is available.
Table 10 – embOS System Variables
TASK LIST
The embOS Task List view displays detailed information regarding all available tasks in the
target system. The task list is updated automatically each time the target execution is
suspended.
There is one column for each type of task parameter, and one row for each task. If the
value of any parameter for a particular task has changed since the last time the debugger
was suspended, the corresponding row will be highlighted in yellow.
Please note that due to performance reasons, stack analysis (the Stack Info column) is
disabled by default. To enable stack analysis, use the Stack analysis toggle toolbar button
in the View toolbar:
330 | P a g e
RTOS-Aware Debugging
Name Description
Status The current status of the task. The type of object that
currently blocks a task is presented in parenthesis.
Waitable Object The address of the object the task is waiting for.
Events The event mask of the task. A value of 0x0 means that the
task is not waiting on any events.
Stack Info The amount of used stack space, the available stack space
and the stack start address. [Used/Total@Address].
Note! This feature must be enabled in the View toolbar.
Round Robin The number of remaining time slices (ticks) and the time
slice reload value, during round robin scheduling.
Table 11 – embOS Task Parameters
TIMERS
The embOS Timers view displays detailed information regarding all available software
timers in the target system. The timers view is updated automatically each time the target
execution is suspended.
331 | P a g e
RTOS-Aware Debugging
There is one column for each type of timer parameter, and one row for each timer. If the
value of any parameter for a particular timer has changed since the last time the debugger
was suspended, the corresponding row will be highlighted in yellow.
Name Description
Hook The address and name of the function that is called when
the timer expires.
RESOURCE SEMAPHORES
The embOS Resource Semaphores view displays detailed information regarding all
available resource semaphores in the target system. The view is updated automatically
each time the target execution is suspended.
There is one column for each type of semaphore parameter, and one row for each
semaphore. If the value of any parameter for a particular semaphore has changed since
the last time the debugger was suspended, the corresponding row will be highlighted in
yellow.
332 | P a g e
RTOS-Aware Debugging
Column Description
Owner The address (TCB) and name of the task currently owning
the semaphore.
Use counter The semaphore use counter. Keeps track of how many
times the semaphore has been claimed by a task.
Waiting tasks The address (TCB) and name of all tasks waiting on the
semaphore.
Table 13 – embOS Resource Semaphore Parameters
MAILBOXES
The embOS Mailboxes view displays detailed information regarding all available mailboxes
in the target system. The view is updated automatically each time the target execution is
suspended.
There is one column for each type of mailbox parameter, and one row for each mailbox. If
the value of any parameter for a particular mailbox has changed since the last time the
debugger was suspended, the corresponding row will be highlighted in yellow.
333 | P a g e
RTOS-Aware Debugging
Column Description
Waiting tasks The address (TCB) and name of all tasks waiting on the
mailbox.
Table 14 – embOS Mailbox Parameters
334 | P a g e
RTOS-Aware Debugging
REQUIREMENTS
The kernel awareness features described in this document is based on eTaskSync Versions
3.01.
335 | P a g e
RTOS-Aware Debugging
TASK LIST
The eTaskSync Task List view displays detailed information regarding all available tasks in
the target system. The task list is updated automatically each time the target execution is
suspended.
There is one column for each type of task parameter, and one row for each task. If the
value of any parameter for a particular task has changed since the last time the debugger
was suspended, the corresponding row will be highlighted in yellow.
Name Description
Time Slice The time slice. This is not always present. Only if
SYNC_TIME_SLICE_ENABLE option is set at compile time in
hcc/src/config/config_sync.h.
336 | P a g e
RTOS-Aware Debugging
The kernel awareness features for FreeRTOS in Atollic TrueSTUDIO provide the developer
with a detailed insight into the internal data structures of the FreeRTOS kernel. During a
debug session, the current state of the FreeRTOS kernel and the various FreeRTOS kernel
objects such as tasks, mailboxes, semaphores and software timers, can be easily inspected
in a set of dedicated views, in the Atollic TrueSTUDIO Debug perspective.
REQUIREMENTS
In order for the FreeRTOS Queues and the FreeRTOS Semaphores views to be able to
locate the appropriate RTOS kernel data structures, the associated kernel objects need to
be added to the FreeRTOS queue registry. Please consult the FreeRTOS reference manual
for details.
The following define fixes so GDB doesn't fail when going through the stack of
a task in FreeRTOS 7.6. The same problem might also affect earlier releases.
These views are available from the Show View toolbar dropdown list button.
337 | P a g e
RTOS-Aware Debugging
TASK LIST
The FreeRTOS Task List view displays detailed information regarding all available tasks in
the target system. The task list is updated automatically each time the target execution is
suspended.
There is one column for each type of task parameter, and one row for each task. If the
value of any parameter for a particular task has changed since the last time the debugger
was suspended, the corresponding row will be highlighted in yellow.
338 | P a g e
RTOS-Aware Debugging
Please note that due to performance reasons, stack analysis (the Min Free Stack column)
is disabled by default. To enable stack analysis, use the Stack analysis toggle toolbar
button in the View toolbar:
Name Description
Priority (Base/Actual) The task base priority and actual priority. The base priority
is the priority assigned to the task. The actual priority is a
temporary priority assigned to the task due to the priority
inheritance mechanism.
Start of Stack The address of the stack region assigned to the task.
Event Object The name of the resource that has caused the task to be
blocked.
Min Free Stack The stack “high watermark”. Displays the minimum
number of bytes left on the stack for a task. A value of 0
(most likely) indicates that a stack overflow has occurred.
Note! This feature must be enabled in the View toolbar.
339 | P a g e
RTOS-Aware Debugging
Name Description
Note! A clock is used to generate timer interrupts and
macros needs to be defined in <FreeRTOSConfig.h> to get
the profiling information. See info below.
QUEUES
The FreeRTOS Queues view displays detailed information regarding all available queues in
the target system. The queues view is updated automatically each time the target
execution is suspended.
There is one column for each type of queue parameter, and one row for each queue. If the
value of any parameter for a particular queue has changed since the last time the
debugger was suspended, the corresponding row will be highlighted in yellow.
340 | P a g e
RTOS-Aware Debugging
Name Description
Max Length The maximum number of items that the queue can hold.
SEMAPHORES
The FreeRTOS Semaphores view displays detailed information regarding all available
synchronization objects in the target system, including:
Mutexes
Counting semaphores
Binary semaphores
Recursive semaphores
The view is updated automatically each time the target execution is suspended.
There is one column for each type of semaphore parameter, and one row for each
semaphore. If the value of any parameter for a particular semaphore has changed since
the last time the debugger was suspended, the corresponding row will be highlighted in
yellow.
341 | P a g e
RTOS-Aware Debugging
Column Description
#Blocked tasks The number of tasks currently blocked waiting for the
object.
Table 18 – FreeRTOS Semaphore Parameters
TIMERS
The FreeRTOS Timers view displays detailed information regarding all available software
timers in the target system. The timers view is updated automatically each time the target
execution is suspended.
There is one column for each type of timer parameter, and one row for each timer. If the
value of any parameter for a particular timer has changed since the last time the debugger
was suspended, the corresponding row will be highlighted in yellow.
342 | P a g e
RTOS-Aware Debugging
Name Description
Period The time (in ticks) between timer start and the execution
of the callback function.
343 | P a g e
RTOS-Aware Debugging
QUADROS RTXC
The kernel awareness features for Quadros RTXC RTOS in Atollic TrueSTUDIO provide the
developer with a detailed insight into the internal data structures of the RTXC kernel.
During a debug session, the current state of the RTXC kernel and the various RTXC kernel
objects such as tasks, semaphores, mailboxes, etc, can be easily inspected in a set of
dedicated views, in the Atollic TrueSTUDIO Debug perspective.
REQUIREMENTS
The kernel awareness features described in this document is based on RTXC Version 2.1.2.
The views can be accessed from the Show View toolbar dropdown list button.
344 | P a g e
RTOS-Aware Debugging
KERNEL INFORMATION
The RTXC Kernel Information view displays general information about the kernel.
Name Description
345 | P a g e
RTOS-Aware Debugging
There is one column for each type of task parameter, and one row for each task. If the
value of any parameter for a particular task has changed since the last time the debugger
was suspended, the corresponding row will be highlighted in yellow.
Name Description
346 | P a g e
RTOS-Aware Debugging
There is one column for each type of stack information, and one row for each task. If the
value of any parameter for a particular task has changed since the last time the debugger
was suspended, the corresponding row will be highlighted in yellow.
Name Description
347 | P a g e
RTOS-Aware Debugging
ALARMS
The RTXC Alarms view displays detailed information regarding all available alarms in the
target system. The view is updated automatically each time the target execution is
suspended.
There is one column for each type of alarm parameter, and one row for each alarm. If the
value of any parameter for a particular alarm has changed since the last time the debugger
was suspended, the corresponding row will be highlighted in yellow.
Name Description
Wait order The alarm’s wait order that can be either Priority or FIFO.
Waiter(s) The task(s) that is waiting on the alarm, if any. Only the
first 5 tasks are shown.
Table 23 – RTXC Alarm Parameters
348 | P a g e
RTOS-Aware Debugging
COUNTERS
The RTXC Counters view displays detailed information regarding all available counters in
the target system. The counter information is updated automatically each time the target
execution is suspended.
There is one column for each type of parameter, and one row for each counter. If the
value of any parameter for a particular task has changed since the last time the debugger
was suspended, the corresponding row will be highlighted in yellow.
Name Description
EVENT SOURCES
The RTXC Event Sources view displays detailed information regarding all available event
sources in the target system. The event source information is updated automatically each
time the target execution is suspended.
349 | P a g e
RTOS-Aware Debugging
There is one column for each type of parameter, and one row for each event source. If the
value of any parameter for a particular event source has changed since the last time the
debugger was suspended, the corresponding row will be highlighted in yellow.
Name Description
EXCEPTION BACKTRACE
The RTXC Exception Backtrace view displays detailed backtrace information during an
exception.
Each line represents an exception that is either executing, or was preempted by the item
above it. The topmost line shows the active component, which preempted the component
listed on the second line, which in turn preempted the third, and so on.
350 | P a g e
RTOS-Aware Debugging
Name Description
EXCEPTIONS
The RTXC Exceptions view displays one line entry for each exception in the application.
Name Description
351 | P a g e
RTOS-Aware Debugging
MAILBOXES
The RTXC Mailboxes view displays detailed information regarding all available mailboxes
in the target system. The view is updated automatically each time the target execution is
suspended.
There is one column for each type of mailbox parameter, and one row for each mailbox. If
the value of any parameter for a particular mailbox has changed since the last time the
debugger was suspended, the corresponding row will be highlighted in yellow.
Name Description
Wait order The mailbox’s wait order that can be either Priority or
FIFO.
Waiter(s) The task that is waiting on the mailbox, if any. Only the
first 5 tasks are shown.
Table 28 – RTXC Mailbox Parameters
352 | P a g e
RTOS-Aware Debugging
MUTEXES
The RTXC Mutexes view displays detailed information regarding all available mutexes in
the target system. The view is updated automatically each time the target execution is
suspended.
There is one column for each type of mutex parameter, and one row for each mutex. If the
value of any parameter for a particular mutex has changed since the last time the
debugger was suspended, the corresponding row will be highlighted in yellow.
Name Description
Wait order The mutex’s wait order that can be either Priority or FIFO.
Waiter(s) The task(s) that is waiting on the mutex, if any. Only the
first 5 tasks are shown.
353 | P a g e
RTOS-Aware Debugging
PARTITIONS
The RTXC Partitions view displays detailed information regarding all available partitions in
the target system. The view is updated automatically each time the target execution is
suspended.
There is one column for each type of parameter, and one row for each partition. If the
value of any parameter for a particular partition has changed since the last time the
debugger was suspended, the corresponding row will be highlighted in yellow.
Name Description
Wait order The partition’s wait order that can be either Priority or
FIFO.
Usage The usage count for the partition. Partition statistics must
be enabled for displaying this information.
354 | P a g e
RTOS-Aware Debugging
Name Description
displaying this information.
PIPES
The RTXC Pipes view displays detailed information regarding all available pipes in the
target system. The view is updated automatically each time the target execution is
suspended.
There is one column for each type of pipe parameter, and one row for each pipe. If the
value of any parameter for a particular pipe has changed since the last time the debugger
was suspended, the corresponding row will be highlighted in yellow.
Name Description
355 | P a g e
RTOS-Aware Debugging
Name Description
Usage The usage count for the pipe. Pipe statistics must be
enabled for displaying this information.
QUEUES
The RTXC Queus view displays detailed information regarding all available queues in the
target system. The view is updated automatically each time the target execution is
suspended.
There is one column for each type of queue parameter, and one row for each queue. If the
value of any parameter for a particular queue has changed since the last time the
debugger was suspended, the corresponding row will be highlighted in yellow.
Name Description
Wait Order The queue’s wait order that can be either Priority or FIFO.
356 | P a g e
RTOS-Aware Debugging
Name Description
SEMAPHORES
The RTXC Semaphores view displays detailed information regarding all available
semaphores in the target system. The view is updated automatically each time the target
execution is suspended.
There is one column for each type of semaphore parameter, and one row for each
semaphore. If the value of any parameter for a particular semaphore has changed since
the last time the debugger was suspended, the corresponding row will be highlighted in
yellow.
357 | P a g e
RTOS-Aware Debugging
Name Description
Wait Order The semaphore’s wait order that can be either Priority or
FIFO.
358 | P a g e
RTOS-Aware Debugging
REQUIREMENTS
The kernel awareness features described in this document is based on ThreadX Cortex-
M4/GNU Version G5.5.5.0.
These views are available from the Show View toolbar dropdown list button.
359 | P a g e
RTOS-Aware Debugging
THREAD LIST
The ThreadX Thread List view displays detailed information regarding all available threads
in the target system. The thread list is updated automatically each time the target
execution is suspended
There is one column for each type of thread parameter, and one row for each thread. If
the value of any parameter for a particular thread has changed since the last time the
debugger was suspended, the corresponding row will be highlighted in yellow.
Please note that due to performance reasons, stack analysis (the Stack Usage column) is
disabled by default. To enable stack analysis, use the Stack analysis toggle toolbar button
in the View toolbar:
360 | P a g e
RTOS-Aware Debugging
Name Description
State The state of the current thread. The name of the object
that currently suspends a thread is presented in
parenthesis. For sleeping threads, the remaining sleep
time (ticks) is presented.
SEMAPHORES
The ThreadX Semaphores view displays detailed information regarding all available
resource semaphores in the target system. The view is updated automatically each time
the target execution is suspended.
There is one column for each type of semaphore parameter, and one row for each
semaphore. If the value of any parameter for a particular semaphore has changed since
the last time the debugger was suspended, the corresponding row will be highlighted in
yellow.
361 | P a g e
RTOS-Aware Debugging
Column Description
MUTEXES
The ThreadX Mutexes view displays detailed information regarding all available mutexes
in the target system. The view is updated automatically each time the target execution is
suspended.
There is one column for each type of mutex parameter, and one row for each mutex. If the
value of any parameter for a particular mutex has changed since the last time the
debugger was suspended, the corresponding row will be highlighted in yellow.
362 | P a g e
RTOS-Aware Debugging
Column Description
MESSAGE QUEUES
The ThreadX Message Queues view displays detailed information regarding all available
message queues in the target system. The view is updated automatically each time the
target execution is suspended.
There is one column for each type of message queue parameter, and one row for each
message queue. If the value of any parameter for a particular message queue has changed
since the last time the debugger was suspended, the corresponding row will be highlighted
in yellow.
Column Description
363 | P a g e
RTOS-Aware Debugging
Column Description
Message size The size (in 32-bit words) of each message entry.
EVENT FLAGS
The ThreadX Event Flags view displays detailed information regarding all available event
flag groups in the target system. The view is updated automatically each time the target
execution is suspended.
There is one column for each type of parameter, and one row for each event flag group. If
the value of any parameter for a particular event flag group has changed since the last
time the debugger was suspended, the corresponding row will be highlighted in yellow.
Column Description
364 | P a g e
RTOS-Aware Debugging
TIMERS
The ThreadX Timers view displays detailed information regarding all available software
timers in the target system. The timers view is updated automatically each time the target
execution is suspended.
There is one column for each type of timer parameter, and one row for each timer. If the
value of any parameter for a particular timer has changed since the last time the debugger
was suspended, the corresponding row will be highlighted in yellow.
Name Description
Functions The address and name of the function that will be called
when the timer expires.
Table 39 – ThreadX Timer Parameters
There is one column for each type of parameter, and one row for each memory block pool.
If the value of any parameter for a particular memory block pool has changed since the
last time the debugger was suspended, the corresponding row will be highlighted in
yellow.
365 | P a g e
RTOS-Aware Debugging
Column Description
There is one column for each type of parameter, and one row for each memory byte pool.
If the value of any parameter for a particular memory byte pool has changed since the last
time the debugger was suspended, the corresponding row will be highlighted in yellow.
366 | P a g e
RTOS-Aware Debugging
Column Description
367 | P a g e
RTOS-Aware Debugging
TOPPERS/ASP
The kernel awareness features for TOPPERS RTOS in Atollic TrueSTUDIO provide the
developer with a detailed insight into the internal data structures of the TOPPERS kernel.
During a debug session, the current state of the TOPPERS kernel and the various TOPPERS
kernel objects such as tasks, semaphores, mailboxes, etc, can be easily inspected in a set of
dedicated views, in the Atollic TrueSTUDIO Debug perspective.
Each view for the TOPPERS RTOS contains two tabs - one tab for the hardcoded Static
Information and one tab for the Current dynamic status.
REQUIREMENTS
The kernel awareness features described in this document is based on TOPPERS/ASP
Release 1.7.0.
They are available from the Show View toolbar dropdown list button.
All displayed functions can be double-clicked and opened in the editor if the source file can
be found in a source folder located within the Toppers project.
368 | P a g e
RTOS-Aware Debugging
TASKS
The TOPPERS Tasks view displays detailed information regarding all available tasks in the
target system. The task list is updated automatically each time the target execution is
suspended.
There is one column for each type of task parameter, and one row for each task. If the
value of any parameter for a particular task has changed since the last time the debugger
was suspended, the corresponding row will be highlighted in yellow.
By double-clicking on a task entry, the source code for the entry will be opened in the
editor if it can be found in a source folder located within the project.
By double-clicking on a Tex routine, the source code for it will be opened in the editor if it
can be found in a source folder located within the project.
Name Description
Auto start If the Task is to auto start or not. Displays yes or No.
369 | P a g e
RTOS-Aware Debugging
Name Description
Name Description
Waiting object When Status is Waiting, this column displays Delay, Sleep,
Recv DTQ, Recv PDTQ, Semaphore, EventFlag, Send DTQ,
Send PDTQ, Mailbox or Mempool
370 | P a g e
RTOS-Aware Debugging
Name Description
DATAQUEUES
The TOPPERS Dataqueues view displays detailed information regarding all available data
queues in the target system. The list is updated automatically each time the target
execution is suspended.
There is one column for each type of data queue parameter, and one row for each data
queue. If the value of any parameter for a particular data queue has changed since the last
time the debugger was suspended, the corresponding row will be highlighted in yellow.
Name Description
371 | P a g e
RTOS-Aware Debugging
Name Description
Name Description
First Waiting Task (receive) When there is a waiting task of this object, displays 1st
waiting task ID. When there is no waiting task of this
object, displays blank space.
First Waiting Task (send) When there is a waiting task of this object, displays 1st
waiting task ID. When there is no waiting task of this
object, displays blank space.
Queuing Data Top When there is queuing data, display 1st queuing data
address as Hex.
Table 45 – TOPPERS Dataqueues Current Status
372 | P a g e
RTOS-Aware Debugging
EVENT FLAGS
The TOPPERS Event Flags view displays detailed information regarding all available event
flags in the target system. The list is updated automatically each time the target execution
is suspended.
There is one column for each type of event flag parameter, and one row for each event
flag. If the value of any parameter for a particular event flag has changed since the last
time the debugger was suspended, the corresponding row will be highlighted in yellow.
Name Description
373 | P a g e
RTOS-Aware Debugging
Name Description
First Waiting Task When there is a waiting task of this object, displays 1st
waiting task ID. When there is no waiting task of this
object, displays blank space.
Table 47 – TOPPERS Event Flags Current Status
MAILBOXES
The TOPPERS Mailboxes view displays detailed information regarding all available
mailboxes in the target system. The list is updated automatically each time the target
execution is suspended.
There is one column for each type of mailbox parameter, and one row for each mailbox. If
the value of any parameter for a particular mailbox has changed since the last time the
debugger was suspended, the corresponding row will be highlighted in yellow.
374 | P a g e
RTOS-Aware Debugging
Name Description
375 | P a g e
RTOS-Aware Debugging
Name Description
ID The Mailbox ID
First Waiting Task When there is a waiting task of this object, displays 1st
waiting task ID. When there is no waiting task of this
object, displays blank space.
MEMORY POOLS
The TOPPERS Memory Pools view displays detailed information regarding all available
memory pools in the target system. The list is updated automatically each time the target
execution is suspended.
There is one column for each type of memory pool parameter, and one row for each
memory pool. If the value of any parameter for a particular memory pool has changed
since the last time the debugger was suspended, the corresponding row will be highlighted
in yellow.
376 | P a g e
RTOS-Aware Debugging
Name Description
Name Description
First Waiting Task Display 1st waiting task ID when there is a waiting task
of this object.
Table 51 – TOPPERS Memory Pools Current Status
377 | P a g e
RTOS-Aware Debugging
CYCLIC HANDLERS
The TOPPERS Cyclic Handlers view displays detailed information regarding all available
cyclic handlers in the target system. The list is updated automatically each time the target
execution is suspended.
There is one column for each type of cyclic handler parameter, and one row for each cyclic
handler. If the value of any parameter for a particular cyclic handler has changed since the
last time the debugger was suspended, the corresponding row will be highlighted in
yellow.
By double-clicking on a handler, the source code for the handler will be opened in the
editor if it can be found in a source folder located within the project.
Name Description
378 | P a g e
RTOS-Aware Debugging
Name Description
Rest time until cyclic event Display Remaining time as ms in decimal form when
Cyclic event is started.
Table 53 – TOPPERS Cyclic Handlers Current Status
ALARM HANDLERS
The TOPPERS Alarm Handlers view displays detailed information regarding all available
alarm handlers in the target system. The list is updated automatically each time the target
execution is suspended.
There is one column for each type of alarm handler parameter, and one row for each
alarm handler. If the value of any parameter for a particular alarm handler has changed
since the last time the debugger was suspended, the corresponding row will be highlighted
in yellow.
By double-clicking on a handler, the source code for the handler will be opened in the
editor if it can be found in a source folder located within the project.
379 | P a g e
RTOS-Aware Debugging
Name Description
Name Description
380 | P a g e
RTOS-Aware Debugging
Name Description
Rest time until alarm Display Remaining time as ms in decimal form when
Alarm is started.
Table 55 – TOPPERS Alarm Handlers Current Status Information
PRIORITIZED DATAQUEUES
The TOPPERS Prioritized Dataqueues view displays detailed information regarding all
available prioritized data queues in the target system. The list is updated automatically
each time the target execution is suspended.
There is one column for each type of prioritized data queue parameter, and one row for
each prioritized data queue. If the value of any parameter for a particular prioritized data
queue has changed since the last time the debugger was suspended, the corresponding
row will be highlighted in yellow.
Name Description
381 | P a g e
RTOS-Aware Debugging
Name Description
Name Description
First Waiting Task (receive) When there is a waiting task of this object, displays 1st
waiting task ID. When there is no waiting task of this
object, displays blank space.
First Waiting Task (send) When there is a waiting task of this object, displays 1st
waiting task ID. When there is no waiting task of this
object, displays blank space.
Queuing Data Top When there is queuing data, display 1st queuing data
address as Hex.
Table 57 – TOPPERS Prioritized Dataqueues Current Status Information
382 | P a g e
RTOS-Aware Debugging
SYSTEM STATUS
The TOPPERS System Status view displays detailed information regarding the system.
There is two columns with status values. If one value has changed since the last time the
debugger was suspended, the corresponding row will be highlighted in yellow.
Name Description
There is one column for each type of interrupt parameter, and one row for each interrupt.
The SWV Exception view is recommended for more information about each interrupt. See
Page 298 - Exception Tracing.
383 | P a g e
RTOS-Aware Debugging
Name Description
There is one column for each type of interrupt parameter, and one row for each interrupt.
The SWV Exception view is recommended for more information about each interrupt. See
Page 298 - Exception Tracing.
By double-clicking on an interrupt handler, the source code for it will be opened in the
editor if it can be found in a source folder located within the project.
384 | P a g e
RTOS-Aware Debugging
Name Description
There is one column for each type of exception parameter, and one row for each
exception.
By double-clicking on an Exception handler, the source code for it will be opened in the
editor if it can be found in a source folder located within the project.
385 | P a g e
RTOS-Aware Debugging
Name Description
386 | P a g e
RTOS-Aware Debugging
MICRIUM µC/OS-III
The kernel awareness features for Micriµm µC/OS-IIITM in Atollic TrueSTUDIO provide the
developer with a detailed insight into the internal data structures of the µC/OS-III kernel.
During a debug session, the current state of the µC/OS-III kernel and the various µC/OS-III
kernel objects such as tasks, memory partitions, message queues, semaphores and
software timers, can be easily inspected in a set of dedicated views, in the Atollic
TrueSTUDIO Debug perspective.
REQUIREMENTS
The kernel awareness features described in this document is based on µC/OS-III V3.02.00.
Please note that the level of information available in the different views in
Atollic TrueSTUDIO depends on the configuration of the µC/OS-III RTOS. If
some feature is not enabled, the views presented in this document may
contain columns presenting information such as “N/A” (Not Applicable) or “0”
instead of expected values when debugging the target system. The Micriµm
µC/OS-III Users Guide contains information on how different features can be
enabled in the operating system.
These views are available from the Show View toolbar dropdown list button.
387 | P a g e
RTOS-Aware Debugging
SYSTEM INFORMATION
The µC/OS-III System Information view displays a number of system variables available in
the µC/OS-III kernel, such as state, version, CPU usage, different counter information, etc.
388 | P a g e
RTOS-Aware Debugging
Name Description
Max Interrupt Disable Time The maximum interrupt disabled time (µs).
389 | P a g e
RTOS-Aware Debugging
Name Description
Scheduler Lock Nesting Counter The counter for the nesting level of the scheduler
lock.
Max Scheduler Lock Time The maximum amount of time the scheduler was
locked irrespective of which task did the locking
Table 62 – µC/OS-III System Variables
TASK LIST
The µC/OS-III Task List view displays detailed information regarding all available tasks in
the target system. The task list is updated automatically each time the target execution is
suspended.
There is one column for each type of task parameter, and one row for each task. If the
value of any parameter for a particular task has changed since the last time the debugger
was suspended, the corresponding row will be highlighted in yellow.
Name Description
390 | P a g e
RTOS-Aware Debugging
Name Description
parenthesis the name of the actual object.
Ticks Rem The amount of time (ticks) remaining for a delayed task to
become ready-to-run or for a pending task to timeout
CtxSwCtr The number of times the task has executed (switched in).
SLT The maximum amount of time (µs) the scheduler has been
(Scheduler Lock Time) locked by the task.
Task Sem Ctr The number of times the task has been signaled while the
task was not able to run.
SEMAPHORES
The µC/OS-III Semaphores view displays detailed information regarding all available
resource semaphores in the target system. The view is updated automatically each time
the target execution is suspended.
There is one column for each type of semaphore parameter, and one row for each
semaphore. If the value of any parameter for a particular semaphore has changed since
391 | P a g e
RTOS-Aware Debugging
the last time the debugger was suspended, the corresponding row will be highlighted in
yellow.
Column Description
MUTEXES
The µC/OS-III Mutexes view displays detailed information regarding all available mutexes
in the target system. The view is updated automatically each time the target execution is
suspended.
There is one column for each type of mutex parameter, and one row for each mutex. If the
value of any parameter for a particular mutex has changed since the last time the
debugger was suspended, the corresponding row will be highlighted in yellow.
392 | P a g e
RTOS-Aware Debugging
Column Description
Owner The name of the task that currently owns the mutex.
Owner Org Prio The owning task original priority (task priority may have
been raised due to priority inheritance).
Owner Nest Ctr The owning task nesting counter. Number of times the
owning task acquired the mutex.
MESSAGE QUEUES
The µC/OS-III Message Queues view displays detailed information regarding all available
message queues in the target system. The view is updated automatically each time the
target execution is suspended.
There is one column for each type of message queue parameter, and one row for each
message queue. If the value of any parameter for a particular message queue has changed
since the last time the debugger was suspended, the corresponding row will be highlighted
in yellow.
393 | P a g e
RTOS-Aware Debugging
Column Description
Pend List List of tasks pending on the queue. Highest priority tasks
are sorted first in list.
Table 66 – µC/OS-III Message Queue Parameters
EVENT FLAGS
The µC/OS-III Event Flags view displays detailed information regarding all available event
flag groups in the target system. The view is updated automatically each time the target
execution is suspended.
There is one column for each type of parameter, and one row for each event flag group. If
the value of any parameter for a particular event flag group has changed since the last
time the debugger was suspended, the corresponding row will be highlighted in yellow.
394 | P a g e
RTOS-Aware Debugging
Column Description
Time Stamp The last time the group was posted to.
Pend List Entries The number of tasks pending on the event flag group.
Pend List List of tasks pending on the event flag group. Highest
priority tasks are sorted first in list.
Table 67 – µC/OS-III Event Flag Parameters
TIMERS
The µC/OS-III Timers view displays detailed information regarding all available software
timers in the target system. The timers view is updated automatically each time the target
execution is suspended.
There is one column for each type of timer parameter, and one row for each timer. If the
value of any parameter for a particular timer has changed since the last time the debugger
was suspended, the corresponding row will be highlighted in yellow.
Name Description
395 | P a g e
RTOS-Aware Debugging
Name Description
Delay The expiration time for one-shot timers and initial delay
for periodic timers.
Callback The address and name of function to call when the timer
expires.
Table 68 – µC/OS-III Timer Parameters
MEMORY PARTITIONS
The µC/OS-III Memory Partitions view displays detailed information regarding all available
memory partitions in the target system. The view is updated automatically each time the
target execution is suspended.
There is one column for each type of parameter, and one row for each memory partition.
If the value of any parameter for a particular memory partition has changed since the last
time the debugger was suspended, the corresponding row will be highlighted in yellow.
396 | P a g e
RTOS-Aware Debugging
Column Description
397 | P a g e
Introduction
398 | P a g e
Revision History
In order to put the concepts and terminology used in Atollic TrueSTUDIO into context, the
two flow charts below are provided.
The first flow chart shows a commonly deployed software review workflow. The second
flowchart shows the individual source code review steps available in Atollic TrueSTUDIO.
The dashed lines between the two flow charts, map the steps of one flow chart to the
corresponding steps in the other.
Figure 372 – Atollic TrueSTUDIO Support for the Code Review Workflow
399 | P a g e
Revision History
400 | P a g e
Revision History
The comments may thus be shared between reviewers using a commonly accessed version
control system. This is a big advantage, as no server-side database needs to be installed,
configured and administered to perform code reviews. The normal version control system,
such as GIT or Subversion, is used for team collaboration.
In order to perform a code review the first step is to create a review ID for this specific
code review session. Creating a review ID is typically done by a moderator, which may be a
team leader or an employee from the quality assurance department. This is a simple
operation where the user is prompted to configure the following options:
The steps to create a specific code review session can be severely simplified by taking the
time to create a project, or company standard, review template. All future reviews that are
created later can then be based on this review template. The moderator will thus only be
required to configure most of the above options once for each TrueSTUDIO workspace.
This is described in next chapter.
Review comments are stored as XML formatted files in a selectable folder within the
TrueSTUDIO project; one file for each reviewer. The overall review settings are saved as a
hidden XML formatted file in the project root folder in the workspace.
401 | P a g e
Revision History
CREATING A REVIEW ID
In order to create a review ID the user must access the properties for the Atollic
TrueSTUDIO project that is containing the desired work product. This is done by
performing the following steps:
4. The user may choose to add a New, or Edit or Remove an existing, review
in the dialog box.
402 | P a g e
Revision History
6. Give the review a Review ID, i.e. a name. It is recommended not to use
whitespaces as this will be part of the file name. Also provide a short
description for the meeting. Click Next.
7. The next step determines the work product for the meeting. Choose which
files that will be subject to this review. Use the buttons to Add and
Remove files.
403 | P a g e
Revision History
9. Select an author among the reviewers. The review issues identified in the
Team Phase will be assigned to the author as default. Naturally, an explicit
assignment overrides the default.
10.In this step, it is possible to configure available parameter options for the
review comments. The parameter options are:
404 | P a g e
Revision History
11.It is possible to set a default option for each of the above review
parameters. This will be used unless an option is chosen explicitly when a
review comment is created or modified.
12.Choose the folder name where review issue data will be saved within the
project. This folder will be stored in the root level of the corresponding
project. It is possible to put the review issue data in a subfolder, i.e.
“ProjectName/reviews/MileStone1_2013-01-02/” by using “/”
(forward slash). The previous example would be specified as:
“reviews/MileStone1_2013-01-02”
405 | P a g e
Revision History
13.In the final step the user can customize which information shall be shown
in the Review Table view during the three different phases; Individual,
Team, Rework. This is done by setting up filters. These filter can be toggled
on and off in the Code Review Table view during the inspection.
Individual Phase – The default filter allows the reviewers to view their
own comments only. It is recommended is to keep this filter, so that
reviewers are not biased by each other’s review comments.
Team Phase – The default filter allows the moderator and the
reviewers to view only comments which have “Resolution: Unset”.
This means that only review comments that still require a decision are
shown.
406 | P a g e
Revision History
Click Finish to save all settings for the specific Review ID.
14.As a final, and very important, step, make sure to commit the review
settings file which resides in the project root folder and is called
.code_review_properties to the version control system. Configuration
files are typically hidden from the rest of the project resources by using a
leading “.” (dot-character) in the filename. A file with a leading “.” in the
filename will not be shown by the Project Explorer view. In order to
commit this file the user must open the Navigator view which also shows
hidden configuration files.
Default selections
The DEFAULT review ID template can be edited from the Review panel in the Project
Properties by selecting DEFAULT and clicking Edit…
407 | P a g e
Revision History
The user may also choose to remove a Review ID by clicking Remove… in the Review panel
in the Project Properties. This will remove the corresponding sections from the review
settings file and all individual reviewer files containing the individual review issue data.
408 | P a g e
Revision History
The Code Review perspective contains a number of unique views and toolbar buttons.
409 | P a g e
Revision History
The Code Review perspective has a toolbar adapted for navigation of review issues. The
toolbar has the following buttons and functionality:
Individual Phase Log into the individual phase and add code
review comments
Team Phase Log into the Team Phase, and perform a code
review meeting
Rework Phase Log into the Rework Phase, and correct the
problems assigned to you at the code review
meeting
Table 71 - Code Review Toolbar Buttons
The following views are primarily associated to the code review perspective:
The main editor area – The editor area of the perspective is needed to review the
source code files.
The Code Review Table view – This is the list of review issues. Different set of
issues will be listed depending on selected Phase and Reviewer.
The Code Review Editor view – An editor showing the current issue being created
or modified. The editor view provides different toolbar buttons depending on the
current phase of the review.
410 | P a g e
Revision History
Edit the code review Edit the settings for this specific code
review
Add code review issue Adds a code review issue associated to the
code line the marker currently is on
411 | P a g e
Revision History
INDIVIDUAL PHASE
In order to start working in the individual phase and add review comments, the reviewer
must use their own associated reviewer ID to log into a review session. The user does this
by clicking on the toolbar button Individual Phase in the Code Review perspective.
The Review ID selection dialog will appear when the user clicks on either of the three code
review phase related toolbar buttons. Review ID must be chosen so that the associated
work product is shown to the reviewer. The user must also choose his or her name from
the Reviewer ID drop-down menu. This will make sure that all review issues found are
associated with the specified Reviewer ID.
When a user has logged into the individual phase of a certain Review ID, it is possible for
him or her to start adding review comments. This is done by reviewing the work product.
The work product can be browsed by using the Go to the source code button in the Code
Review Table.
412 | P a g e
Revision History
By selecting a file from the drop-down menu it will be opened in the Editor window of the
IDE.
1. In the editor select a code-line with the mouse cursor, doing so the selected text will
be copied into the “description” field of the review issue.
2. Right-click on the line number and choose “Add code Review Issue…”
If the user right-clicks in the editor instead of the line number, the review issue
may not be associated to the correct line number.
If no text is selected, the review issue description field will be empty.
When clicking Add Code Review Issue… the reviewer will be hyper-linked into the Code
Review Editor view where a new review issue is being created.
413 | P a g e
Revision History
The top of the Code Review Editor view shows information about who found the review
issue, in which file and at which code line. The user may also choose to select a code block,
right-click and then click Add Cod Review Issue… In this case the content of the code block
will be copied into the description field of the Review issue. The type and severity fields
are mandatory information for each review issue.
The type field identifies the type of review issue and the severity field defines the severity
level for the current issue.
After entering all information into the review issue being added, click the Save button in
the Code Review Editor view. Upon saving, the review issue will become visible in the
Code Review Table view. A review marker will also be added to the left margin of the main
editor window.
Go through the different files included in the work product and add review comments.
When an individual user has finished reviewing the work product, he/she must remember
to commit the .review file to the version control system. This enables other reviewers to
access the review issues by retrieving the files them from the version control system.
This path to the .review file was specified during the review configuration phase. By
default the file is saved in the review subfolder within the project folder.
TEAM PHASE
In this phase the team members gather in a code review meeting to discuss all the review
issues that were found by the individual reviewers. Before starting this phase it is
important that the review moderator assures that all reviewers have committed their
.review file, and subsequently updates his or her own local copy of each .review file
414 | P a g e
Revision History
from the version control system. If this is not done properly, the issues from one, or more,
reviewers are not taken into account, and will not show up in the collaborative Code
Review Table view.
To start the team phase (code review meeting), click on the Team Phase toolbar button in
the Code Review perspective.
The Review ID Selection dialog will appear where the user is prompted to select a Project,
a Review ID and a Reviewer ID. The Reviewer ID in this phase is typically the author of the
work product under review or the moderator hosting the meeting.
All review issues collected by all reviewers are now displayed in the Code Review Table
view (provided that the review comment files have been committed to the version control
system, and have subsequently been updated to the computer being used for the code
review meeting).
Click on any review issue in the Code Review Table view and its content will be shown in
the Code Review Editor view. If an already existing review issue is modified in this phase,
make sure to click Save, Next, or Previous button to automatically save any changes. By
double-clicking on any review issue in the Code Review Table view, the associated source
code lines are also shown in the editor area of the IDE.
Review issues can also be navigated from the Code Review Editor view by using the Next
and Previous buttons. The Go to the source code button allows jumping from the Code
Review Editor view into the source code.
The Assigned To field contains the author’s Review ID by default, but can be changed to
the Reviewer ID of any other team reviewer. When the group has reached a decision on
how to handle the review issue at hand, the Resolution field must be changed to reflect
this decision. The Annotation field allows additional information to be added.
415 | P a g e
Revision History
By single-clicking on a review marker in the source code, the summary and description of
the review issues for the specific code line will be shown in a tooltip.
Review markers are also subject to the filter that is configured for the current phase of the
code review. For example, if the filter is set to show Resolution: Unset issues only, then
only review markers associated with such review issues will be shown.
When all review issues have been handled in the code review meeting; a reviewer has
been assigned and a resolution has been chosen for all review comments, it is important to
remember to commit the .review files to the version control system. When this is done
all reviewers are able to access the decision outcome information from the Team Phase,
and the code review can enter the Rework Phase.
REWORK PHASE
In this phase each reviewer will work on the review issues that were assigned to him/her
at the code review meeting, in order to implement the agreed resolution. Before starting
this phase it is important that the each reviewer updates the folder containing the
.review files from the version control system. If this is not done, the reviewer will not be
able to access any assigned-to or resolution information from the code review meeting.
To start this phase click on the Rework Phase toolbar button in the Code Review
perspective.
The Review ID Selection dialog will appear where the user is prompted to select a Project
a Review ID and a Reviewer ID.
In the Code Review Table view, the user will only see the review issues that were assigned
to the reviewer that was selected in the Review ID Selection dialog when entering this
phase. The purpose of this phase is that each reviewer addresses the review issues that
were assigned to him/her respectively.
416 | P a g e
Revision History
The Code Review Editor view will now contain the fields Status, Resolution and Revision.
The Status field allows the status of each review issue to be changed. The resolution fields
simply states the agreed resolution decided at the code review meeting. It can and should
not be changed in this phase. The Revision field provides the possibility to write a
comment related to the implemented resolution.
Figure 398 - Code Review Editor View Content in the Rework Phase
When all fields are filled in for the Review issue at hand, the reviewer must click Save,
before the buttons Next and Previous can be used to view the next review issue to fix.
When updated statuses for all review issues have been saved, the Code Review Table view
will be empty. The reviewer must then remember to commit the .review file to the
version control system so that the moderator can verify that everything has been fixed.
ADDITIONAL SETTINGS
The Code Review Table view can also be customized temporarily without overwriting the
.code_review_properties file. This is done from the Preference settings found in the
Code Review Table view toolbar.
In this customization dialog the user may change filters that are applied on the Code
Review Table view in order to show only review issues that have a certain parameter
combination. It is also possible to tailor which columns, and thereby which parameters, are
visible in each phase.
417 | P a g e
Revision History
418 | P a g e
Revision History
REVISION HISTORY
This section provides information what’s changed in this document in each revision.
419 | P a g e
Revision History
REVISION HISTORY
The revision history of this document is briefly described below.
Updated Introduction
420 | P a g e
Revision History
421 | P a g e