1 2 3 Previous Next

ARM and Keil Tools

85 posts

The concept of "exceptions" to most experienced programmers in languages ​​like Java, in my case, is a sign of failure or error during code execution.

 

However, in assembly language programming for the ARM, this concept indicates an internal requisition, be a reset, a System Tick or a call from the supervisor, but there are also architectures that throw exceptions in case of problems such as division by zero.

 

In ARM, external signals that interfere in the implementation process are called interruptions, but all are exceptions, most commonly used for internal signals.

Such signals are called events.

 

The blocks of codes dealing more events are called Exceptions Handlers when dealing with exceptions (internal) or Interruptions Handlers when dealing with interrupts (external).

 

Now expanding a bit with my studies, I realized that there is a possibility that the exception "Hard Fault" occurs, so get more knowledge about the moments that it can occur update this post.

A couple of months ago I posted this blog discussing how to get started with the Fixed Virtual Platform supplied with DS-5 Ultimate Edition. I'm writing this blog as a follow up, as ARM has just released their first ARMv8 Development Platform, Juno. Furthermore, in DS-5 version 5.19 (and later) there is a ready made debug configuration for the Juno Platform. You can download the latest version of DS-5 here. For more on Juno, see other blogs from my colleagues here and here. Linux and Android ports to this board are available via Linaro.I used the 14.06 Linaro LAMP file system in the examples below, which was the latest available at the time of writing.

 

One of the best things about using DS-5 is that the look and feel is very consistent, regardless of the type of target you are using. The only notable difference between using DS-5 with the Juno (or any other) platform vs the Fast Model, is in the Debug Configuration Pane.


Let's start with configuring a JTAG based debug connection using DSTREAM. Connect the DSTREAM hardware to the JTAG port at the rear of the Juno platform. Note that if TPIU ("off-chip") trace is needed, you will need to remove the top of the casing to access the trace connectors.

 

Launch the Eclipse GUI, and select Run Debug Configurations to launch the pane. On the left hand side, select DS-5 Debugger, and click on the New Configuration Button. Give the configuration a meaningful name. You will see a long list of known targets, in what we call the configuration database. Typing "Juno" in the filter window will jump straight to the required configuration database entry, which you can expand like this:

 

pic1.png

You will notice a wide variety of options here. You will see options to connect to the individual CPUs present in the platform. You also have options to connect to the distinct Cortex-A53 and Cortex-A57 CPU clusters (in an SMP configuration). Finally you have an option to connect to all six application processors in a big.LITTLE configuration. You will need to understand how the platform boots to know which is available and when. Assuming you are using the platform exactly as supplied by ARM, the initial bootloader and UEFI run on Cortex-A53_0 (as labelled above). The Cortex-A57 cluster is held in reset, during this process, and so any attempt to connect to any of the Cortex-A57 processors, including the big.LITTLE configuration, will result in a debugger error. You should select either the Cortex-A53_0 or the Cortex-A53x4 SMP connections. If you are connecting to a fully booted system, you should be able to select any of the options. Note if running Linux, and debug symbols of your kernel are available, you may wish to use the connections listed under "Linux Kernel and/or Device Driver Debug" for enhanced debugger features.

 

Click the DTSL Options "Edit" button to show the range of different trace configurations available to you. You can enable trace for any or all CPUs that you wish to connect to.

 

pic2.png

 

Click the Browse button to locate your DSTREAM unit. Finally, use the File and Debugger tabs to configure your debug session as necessary. Click Apply to save your setup and then OK, to commence the debug session.

 

Example 1: Debugging the Cortex-M3

pic9m3.png

 

Example 2: Debugging the Cortex-A53 cluster (UEFI running on target)

pic7uefi.png

 

Example 3: Debugging the entire big.LITTLE cluster (Linux running on target)

pic6bl.png

 

For Linux Application Debug, the steps are identical to those in my previous blog. I did however spot a problem with the Linux Application Debug option within the Juno configuration database entry, which refers to a AArch32 gdbserver (code on Juno is highly likely to be running in AArch64).

 

pic3.png

 

If you attempt to use this configuration (with AArch64 code) you get an unrecoverable error of the form:

 

ERROR(TAD90-INT9):

! Failed to read state of device gdbserver

! The address "<address>" is invalid

 

The solution to this is to use the Linux Application Debug Application Debug Connections via AArch64 gdbserver configuration:


pic4.png

DS-5 Ultimate Edition has full Streamline support for Cortex-A53 and Cortex-A57, Mali-T624, and other system hardware present on Juno. Initial support is provided within the Linaro images, and I expect this to be extended over time.

 

pic8streamline.png

 

Both DS-5 Ultimate Edition v5.19 and the Juno ARM Development Platform are available to order now. Please contact your ARM Representative for more information.

I am writing this short blog to help illustrate a great feature we have added to DS-5, available in version 5.19 and later. You can always get the latest version of DS-5 here. We have a new MMU view, as well as associated command line (CLI) commands to help visualize the virtual and physical mapping of the memory system. In the first release, we support all ARMv7-A CPUs, such as Cortex-A9 and Cortex-A15. It is an easy to use feature, requiring no particular configuration of the debugger, as this information is automatically determined by the tools, reading the translation table base register(s) of the CPU, and processing the translation tables accordingly. It is a great utility to help you verify that the MMU has been configured as you wanted, else it can help you to drill down to the reason why if it isn't.


I am using a Zedboard platform, running SMP Linux on the dual-core Cortex-A9MP CPU within the Xilinx Zynq device. I am connected to the target via DSTREAM. However this will work with any suitable CPU configuration, real hardware or even an FVP.

 

You will first need to locate the MMU pane in the Eclipse GUI of the debugger, as it is not visible by default. Navigate through the Eclipse GUI menu system, from Window Show View Other DS-5 Debugger MMU, and the window will appear. The easiest use case of the view is to simply enter an address in the Translation tab, specify whether this is a Physical or a Virtual address, and click translate. The debugger will tell you the translated address, as well as some information on how the address was resolved. An easy first test is to translate a virtual to a physical address, and then translate the result back again:

 

pic4.png

As an aside, note that the translated result is listed as SP:0x01007000. The SP address qualifier refers to a "Secure Physical" address.

 

pic5.png

 

From the above, we see that the virtual address 0x8000 maps to physical address 0x01007000, and vice versa. We also see that physical address 0x01007000 also maps to other virtual addresses (0xC1007000 in this case). That is a very common scenario.

 

From there, we can easily explore deeper into the MMU page tables. Click to the Memory Map tab, and you will see the following:

 

pic1.png

Click the Show Memory Map button, and the debugger will populate the view, grouping together virtual address ranges and their corresponding physical address ranges, and summarizing the properties of each range:

 

pic2.png

 

We see that the virtual memory region starting at 0x8000 maps to the physical region starting at 0x01007000, exactly as the Translation tab said it would. We also see the access permissions and other properties of the addresses. This type of information is useful to help decipher ordering or coherency issues that you may encounter.

 

If more detailed information on the page table entries is needed, you can go to the Tables tab, and expand this view as needed.

 

pic3.png

We can also use the MMU view to easily explore alternative scenarios. Click on the MMU Settings button, and you can apply custom settings by changing the parameters to point to alternative translation tables, and examine the new translation state.

 

pic9.png

 

The above GUI views are ideal for human interactive debugging. It is also possible for you to generate similar reports from the command line, or hence via DS-5 scripts that you may wish to generate, and for this we have added a new family of mmu commands:

 

pic6.png

 

Note that as for all DS-5 commands, you can use Ctrl+Space to help auto-complete the command as well as provide a simple pop-up explaining its use.

 

pic8.png

 

Most of the options are somewhat self explanatory. I recommend using the mmu list commands to assist in determining the appropriate parameters to use. For example you may wish to do something like the below.

 

pic7.png

 

Note again that this feature is added in DS-5 5.19. If you have an earlier version (which you can determine from the Eclipse Menu in Help About ARM DS-5), you will need to update your installation from here. In the first release we only support ARMv7-A CPUs. We plan to support ARMv8-A in a future release.

Overview

The GNU ARM Eclipse project includes a set of open source Eclipse plug-ins that enhance Eclipse CDT (C/C++ Development Tooling) with the specific functionality required to create/build/debug/manage ARM (32-bit) and AArch64 (64-bit) applications and static/shared libraries, using the latest GNU ARM GCC toolchains. These plug-ins will be the foundation of a future integrated suite intended to meet the growing demands of entry level users and small companies.

Project sites

The main source of information for GNU ARM Eclipse is the project site http://gnuarmeclipse.livius.net/blog/, currently with the following home page:

HomePage.png

The Git repositories and all public releases are available from SourceForge.

SourceForge.png

Install

The recommended way to install the GNU ARM Eclipse plug-ins is to use the Eclipse standard install/update mechanism: in the Eclipse menu go to: HelpInstall New Software… and use the update site location: http://gnuarmeclipse.sourceforge.net/updates

Install.png

The managed build

The managed build plug-in allows to create C/C++ managed projects and to configure an extensive list of compiler and linker options.

ToolSettings.png

The GNU ARM Eclipse build plug-in also provides extensive configuration options for selecting the toolchain and to portably manage the toolchain path:

Toolchains.png

Extra build steps

In addition to building the ELF file, the build plug-in can also create a binary file (ihex, srec, binary) to be programmed in the processor flash memory, create a listing, and display the program size.

ExtraBuildSteps.png

Discovery Options & Indexing

In order to allow Eclipse users to navigate to definitions and declarations, to allow smart completion, refactoring and all these nice features, the CDT needs to have exactly the same knowledge of the source files as the compiler. For this, it also needs to know the system headers used at compile time and the default preprocessor definitions issued by the compiler. GCC provides a magic combination of command options to do this (-E -P -v -dD ${plugin_state_location}/specs.c), so the CDT needs to issue the proper compiler commands (one for each language, C & C++). The build plug-in provides these details, for each toolchain.

LanguageProviderOptions.png

The result of a proper discovery setting is a correct set of preprocessor definitions that reflect the compiler options and a correct set of include folders:

Includes.png

Functional ready to run templates

For beginners, who need initial help to put together all details for their first project, a complete sample with startup code, linker scripts, semi-hosting support and all necessary options already set, can be a major time saver.

Elaborated templates are available for the STM families of processors STM32F[01234]x, and for some Freescale KLxx processors. They create the classical application that blinks a LED, and, specific for the Debug configuration, prints a string on the tracing (SWV or semi-hosting) output.

NewProjectTemplate.png

For processors from other families, there is also a generic Hello World ARM Cortex-M3 Project template.

Debugging support

During the lifetime of a project, creating/editing source files and building binaries are certainly important activities, but in many cases the most time is spent during debugging sessions, therefore a reliable debugging environment is an absolute must.

There are many debugging techniques and tools, but GNU ARM Eclipse recommends two solutions:

The preferred solution is the SEGGER J-Link, and the J-Link plug-in allows to configure most relevant J-Link GDB server options:

jlink.png

Packs support

Packs refers to a new modular technology, intended to simplify distribution of software and documentation. The main difference from usual libraries or source archives is that the actual source/object files are accompanied by some form of metadata, defining the dependencies between files, the use of constraints and conditions, plus lists of devices the software runs on, with full descriptions, memory map, registers and peripherals, etc.

The GNU ARM Eclipse Packs Support plug-in is intended to manage (list/install/inspect/remove) packs from multiple sources. It currently implements the specifications of CMSIS Packs v1.2, as defined by ARM/Keil, with some extensions.

PacksPerspective.png

The importance of the packs technology is amazing, and there are many useful things available in the packs; unfortunately most of the existing ones, being created by ARM/Keil, were designed with Keil MDK in mind, so are expected to be included in projects compiled with the outdated ARMCC compiler; moreover all available examples can be used only with Keil MDK, and are of no direct use for Eclipse and GCC environments.

For the moment, inspecting the content of the packs is all that can be done, but the packages also include some portable files, that can and will be used in future versions of the plug-ins, for example:

  •   the list of supported devices and memory maps will be used to associate devices to projects; this will allow to automatically fill in some of the compile options, like the architecture (M0/M0+/M3/M4); even more importantly, it will allow to automatically generate the linker scripts with the correct values (avoiding severe headaches for many users, especially beginners);
  •   the detailed list of device peripherals and the register bits will be used to extend the debug perspective with a detailed view presenting the register bit values, a very convenient feature when developing embedded software;
  •   the list of documentation files (PDF or CHM) will be available on a project view, for easy access to the specific device or board documentation;
  •   the vendor CMSIS headers and source files will be used in the future version of the project template.

And, in the mid-term future, the GNU ARM Eclipse templates will be fully replaced with component based projects, allowing an easy update and advanced configurability for projects.

More info

For more info about the GNU ARM Eclipse project, please refer to the project site http://gnuarmeclipse.livius.net/blog/.


Hi, I would like to share an exciting product the team has been working on for the last couple of months. It's Juno, one of the first available ARMv8 Development Platforms with software ports for Android and Linux are available from Linaro

juno_straight down_thumb.png

It enables

  • ARMv8-A AArch64 kernel and tools development for Cortex-A50 series
  • Secure OS & Hypervisors through ARM Trusted Firmware
  • Expansion using a LogicTile Express 20MG FPGA board that connects directly to
    the platform
  • 3D graphics and GPU compute with native big.LITTLE and Mali support
  • Middleware & file systems porting and optimisation to 64-bit
  • Real-time debug, trace and performance tuning with CoreSight technology

 

juno_compute subsystem.jpg

 

There is lots of detail at www.arm.com/juno with links to Linaro and other places, and a number of reviews in the press, I think it's quite an interesting product. Hope you find it interesting.

 

Liam

Dear All,

 

Please share me if any of you have prepared QAC personality files for ARM GCC 4.8.3

 

Many thanks in advance

Best Regards

Harikrishna

7/9 I got some information from QAC...still I have issues....Pls let me know if you have any solution

 

Prlgcc utility is used to generate complier personality files for GNU based compilers. The prlgcc_win_4.1.zip utility can be downloaded from the link provided

http://products.programmingresearch.com/Common/GCC_Integration/

 

I have downloaded the run the .exe as per below in the command prompt.

However, I get the error below. Kindly advice us.

 

We are using the QAC version 8.0 R

 

D:\>Hari\work\qac\GeneratePersonality\prlgcc_win_4.1\prlgcc\prlgcc.exe qac -pers

onalities C:\Program Files\PRQA\QAC-8.0-R\personalities\ -compiler C:\gcc_arm\ar

m-none-eabi\bin\gcc.exe -header C:\gcc_arm\arm-none-eabi\include\

compiler=gcc, executable=C:\gcc_arm\arm-none-eabi\bin\gcc.exe

No suitable configurations found for qac 100.

In the last week, Infineon Technologies held two customer workshops, one in their central office in Munich and one in Milan (Italy). Nearly 100 participants were given the latest information on the XMC microcontroller family from Infineon based on the ARM® Cortex®-M4 processor. Experts from Infineon demonstrated feature innovations from the latest additions to the XMC family and introduced the DAVE development environment. Hands-on sessions on Keil MDK Version 5 and IAR Embedded Workbench® for ARM by IAR Systems brought the developers quickly up to speed with professional software tools.

 

In Munich, the local ARM team supported the event, whereas in Milan engineers from Tecnologix were answering the participant's questions. The Keil MDK sessions were very well attended. The topics that were taught ranged from exporting DAVE projects to µVision up to creating sophisticated applications using MDK-Professional Middleware with CMSIS compliant drivers provided from Infineon in their Device Family Packs. For those who could not attend, I have attached the teaching material from the MDK session to this blog.

 

Here is an impression from the event in Milan:

InfineonCustomerWorkshopMilan_small.jpg

These two developer days were the first ones for Infineon that were done in this way. Due to the tremendous success, I'm quite sure that we will see this kind of events more often in the near future.

 

If you are interested in more information on how MDK can support your development project for Infineon XMC microcontrollers, please visit www.keil.com/infineon. On that page you will find more information and interesting videos, as well as a link to download the free Keil MDK for Infineon XMC1000 development tools suite.

Embedded

We're occasionally asked whether it's possible to add extra toolchains to ARM DS-5 Development Studio, such as GCC Launchpad or a different Linaro GCC release to the one that we include.

 

The answer is yes! This is more of a tip-of-the-day than a blog, but we thought it was worth putting it down on record.

 

There's a quick and easy way thanks to the Eclipse Cross GCC CDT plugin which is available for download and install directly from DS-5 via the Help > Install New Software... dialog.

 

If you're familiar with Eclipse, it's simply a case of pointing it at the correct URL and letting it carry out the install. Following on from that, you can create a new project with Cross GCC selected as the compiler.

 

This should work for bare-metal or Linux compilation toolchains. I tested it with gcc-linaro 4.9 (AArch64) and ran the resultant code on the ARMv8 FVP.

 

For full instructions, read the tutorial on the DS-5 website.

 

Update: we have a similar tutorial on using GCC for bare-metal development here: http://ds.arm.com/debugging-bare-metal-applications-on-fvps-using-ds-5-and-gcc-compiler/

Developing an embedded product takes time. This white paper describes some of the slick hooks Altera has incorporated into SoC FPGA architecture and toolset to shorten development time and ease debug and development efforts. It is worth noting that Altera is the only embedded FPGA with

  • System Trace Macrocells - the only system level CoreSight Macrocells designed specifically for high performance Cortex-A9 based systems.
  • Adaptive Debugging - whereby the DS-5 debugger automatically imports peripheral register description files from the Altera SoC FPGA even as peripherals iterate during development.

 

Read more here:  http://www.altera.com/literature/wp/wp-01198-fpga-software-debug-soc.pdf

robkaye

So, that was DAC 2014

Posted by robkaye Jun 13, 2014

Last week I was at the 51st DAC in San Francisco.  As I write that first line, it struck me that this was the 30th anniversary of the first DAC I attended in Albuquerque.  During the Conference I crossed paths with many colleagues that have been around as long as I have: if I had a dollar for each one that commented on how the event had changed over the years, I might have been able to afford a beer at the hotel.  Just.

 

My impression was that the Conference was as strong and vibrant as ever but that the associated trade show has declined in impact and relevance.  Companies are no longer sending large delegations as much of the information they need is available online: definitely not the case when I first attended.

 

This year, I presented in the Monday Tutorial sessions and the Designer Track as well as manning the Fast Models demo pod.  The theme for the presentations was "Hybrid Virtual Platforms", i.e. an environment where a programmer's view Virtual Platform (or Prototype) is connected to an emulator (e.g. Cadence's Palladium XP) to create a simulation environment for an SoC.  This is gaining acceptance amongst our partners, several of whom - including CSR and NVidia - presented on how and why they are adopting the solution.   The subject is heavily featured in  Frank Schirrmeister's recent blog from DAC.

 

20140603_140233s.jpg

The author "in action" at the Cadence Theater, DAC 2014.

 

The Fast Models demo focused on trace, debug and analysis.  Assuming that the basic requirements(*) for a Virtual Platform have been met, the demos showed how the platform is leveraged to extract and display information on the execution.

 

Tracing Fast Models in ARM DS-5

 

Part of the demo showed how can the model developer's knowledge of (for example) a peripheral be used to build test harnesses that quickly provide feedback that the software is using the IP as expected.  In this example, we are using the Fast Model Python interface to attach a script that checks whether the LCD Controller in our example platform has correctly been set up by the software application running on the Virtual Platform.

pyCADI_good_crop.jpg

Results of checking the CLCD setup in the Virtual Platform

 

This methodology is particularly useful when working with complex peripheral IP such as MMUs, GICs and cache coherent interconnects and results from the experience gained in supporting partners getting started with ARMv8 designs..

 

We got a good response to this demo and we plan to follow up with more details in webinars/workshops later in the year and at ARM Techcon in October.

 

(*) fast, accurate, complete models of the required IP.

It’s May in Cambridge. It’s raining, flowers are in bloom, the birds are singing and students are falling off punts into the River Cam. May also means that it’s time for the biannual ARM® Fast Models™ release. This release cycle we are actually making two concurrent releases: Fast Models 9.0 and 8.4. Why two? This is a step towards our long term strategy for the models that focuses on 64-bit. Making this statement immediately raises questions with partners: what do we mean by this statement? Many partners have jumped to the conclusion that it is related to ARMv8 and AArch64.

 

What it actually means is the simulators built by the Fast Models tools will be 64-bit objects. ARMv8, ARMv7 (and earlier generation) models are still supported as is AArch32. The two releases are identical in functionality, identical in the IP and flows that they support, the only difference is that 9.0 will build a 64-bit executable and 8.4 a 32-bit executable. Making this clean split now enables us to develop new functionality on the 64-bit, 9.X branch whilst maintaining the 8.4 release for the subset of partners that need ongoing support for 32-bit host hardware. 64-bit is required to support the memory footprint that complex virtual prototypes require and performance benefits for the AArch64 models and is therefore front and center to our modelling needs.

 

Other than the 64/32 split the new releases address the three main pillars of the modelling technology: supporting the latest IP, providing accuracy and performance and enabling the development and debug of complex software stacks in advance of hardware availability. New models in this release include the ARM Cortex®-A17 processor (including big.LITTLE™ processing), the CCN-508 Cache Coherent Network and the GIC-500 Generic Interrupt Controller. As systems (and processors) continue to spiral in complexity it’s an ongoing challenge to provide the necessary levels of performance needed to make the models useful whilst providing all the debug and analysis capabilities that partners need. Longer term we are looking at further improvements to the underlying modelling technology, but for this release we have done extensive analysis on workloads such as Android and Windows and identifying model optimizations. The good news is that as a result we haves measured up to 2.5X speed up in booting standard Linaro OSs on Fixed Virtual Platforms of the ARMv8 models. For the software development we have been investing in closer links to the DS-5 tool chain to leverage its trace and analysis capabilities.

 


 

Fast Models 9.0 (64-bit) and 8.4 (32-bit) performance improvements versus the 8.3 release

 

We will be demonstrating these new features at DAC from June 2nd-5th. Stop by our booth (#2007) to get a flavor of what we are doing, ask those awkward questions and find out how a growing number of ARM partners are leveraging the benefits of virtual prototypes. I promise not to bring the soggy Cambridge weather with me.

ARM has recently launched DS-5 Ultimate Edition which adds support for the latest ARMv8-A Architecture and associated ARM Processors. Included in the package is the ARMv8-A Fixed Virtual Platform (FVP) model, giving you a platform to develop code on in advance of hardware availability. In this blog I will attempt to explain the necessary steps to get a working Linux system running on this platform.

 

But first, especially if you are new to DS-5, we provide some bare-metal examples within DS-5, which you can use to quickly ensure that everything is working correctly. You should be able to use Import... → General Existing Projects into Workspace from the File menu to import the fireworks example from the \\DS-5\examples\Bare-metal_examples_ARMv8.zip archive. This contains an already configured debug configuration, allowing you to connect via the Debug Control pane, and run this application on the FVP. As this all works "out-of-the-box", it should be a useful first step for learning the GUI, locating register views etc.

Once you are happy that everything is working, we will now move to install a Linaro Linux distribution to the FVP. The latest ARMv8-A distribution is always available here, and is updated approximately monthly. If you simply wish to boot Linux on the platform, you will be able to use the pre-built files. You will need to retrieve the img.axf kernel binary, and the appropriate file system image. There are two options used below, which should be unzipped on the host.

 

vexpress64-openembedded_minimal-armv8-gcc-<version_and_date>.img.gz is a minimal file system (~80MB)

vexpress64-openembedded_lamp-armv8-gcc-<version_and_date>.img.gz is a fully featured file system (~430MB)

 

We can launch the model either stand alone, or within the debugger GUI. The procedure is similar for both. To launch stand alone, I recommend creating a batch file, that runs the following command line. Note that this needs to be edited to point to the kernel binary and the file system image used:

 

<path_to>\DS-5\sw\models\bin\FVP_VE_AEMv8A.exe \

-a <path_to>img.axf \

--parameter motherboard.mmc.p_mmc_file="<path_to>\<unzipped_filesystem_image>.img" \

--parameter motherboard.mmc.card_type=eMMC \

--parameter motherboard.smsc_91c111.enabled=true \

--parameter motherboard.hostbridge.userNetworking=true \

--parameter motherboard.hostbridge.userNetPorts="5555=5555,8080=8080,22=22"

 

For a description of these options, see the latest FVP documentation. From testing on various machines, it takes about 60-120 seconds to boot the minimal file system image, about 4-7 minutes to boot the full LAMP filesystem.

 

 

To launch from the DS-5 debugger, select Debug Configurations... from the Run menu, and click the New launch configuration button in the upper left. Give this configuration a name, and then locate the VE_AEMv8 target. I find it easier to enter this in the Filter window, and the tools will automatically jump to it. Navigate down the tree to Linux Kernel debug, and then Debug ARMAEMv8-A_MP_SMP, to connect to all four CPUs in this model.

 

 

You then need to paste the same options above (bar the call to the executable itself) into the Model Parameters window.

 

 

Click on the Debugger Pane, and select Connect Only. Click on Debug to connect the debugger, click go, and let the system boot as before. You can now also control execution (start/stop etc) with the debugger.

 

If you have rebuilt the kernel to include debug information (the pre-built images do not contain debug information), you can stop the target, and now use either the Debug Contol pane's Load feature

 

load file.png

 

 

or from the CLI:

 

add-symbol-file <path_to>\vmlinux

 

and the debugger will now display the status of all threads running on the target:

 

 

Note that all below requires use of the above full featured file system (or an equivalent that you have built yourself).

 

You can create a Remote System View of the file system, by opening the Remote Systems pane, creating a  (right-click) New Connection → General Linux, and set the Hostname to LOCALHOST, and give the connection an arbitrary Connection name (FVP Linux in the below). Then click Next, and select ssh.files in the Configuration section. Click Finish. You will then be able to expand the file system view (set username as root if prompted).

 

 

 

New Connection.png

New Connection2.png

New Connection3.png

 

From this view, you can also right-click on Ssh Terminals, and launch a terminal window within the DS-5 GUI, thus eliminating the need to jump back and forth to the telnet window.

 

Finally, for completeness, you can also use DS-5 to debug an application on the target. I built the hello.c that is present in this image (gcc -g hello.c) directly on the target. Then I started a gdbserver session with "gdbserver :5555 a.out" (you will notice this port was specified in the model parameters when launching the model). I can then create an Application Debug Configuration, as below, and debug the image.

 

terminal1.png

debug config.pngdebug control.png

Alternatively, if building the application on the host, you could use the "download and debug" option, and the debugger would write the image to the target, via the remote system connection.

 

download and debug1.png

ARM is constantly providing updates to our DS-5 toolchain, and details of these updates are provided in the change log. When you purchase the tools, you will receive either a term or perpetual license depending on what you purchased, as well as support and maintenance (S+M) for these tools. The default S+M tem is one year from date of purchase. Once S+M has elapsed, even if you still have an ongoing license to use the tools, you may start to see errors of the form:

 

Error: C9932E: Cannot obtain license for Compiler (feature compiler5) with license version >= 5.0201401

 

It is not immediately obvious what this error means, other than the obvious, that you cannot obtain a suitable license for your compiler.

 

The key is the number string, such as 5.0201401 in the above example. It may be clearer if the number was presented as

 

5.0     2014/01

 

Here, 5.0 represents ARM Compiler 5, and so will enable the compiler within DS-5, as well as previous versions of the ARM Compiler, as provided in our legacy tools, such as the RealView Development Suite.

 

The date string, 2014/01 in this case, means that to use this particular version of the ARM Compiler, requires valid support and maintenance up to at least the end of January 2014. If you do see this error, please contact your ARM sales representative or ARM tools distributor, and they can help you renew your S+M. Else you will need to downgrade to an older version of the tools, released previous to this date.

 

It is not always obvious to know which version you are entitled to use, and so I have prepared the below table, based on the above change log. Note that ARM Compiler 6 was also added in v5.18 and later releases. This is a brand new compiler (armclang), and is provided in DS-5 Ultimate Edition. Though use of this compiler will not generate the above error. I mention it in the below for completeness (armcc is also provided in these releases). As an aside, I've noticed many ARM Compiler 6 users have an unrelated, but similar licensing error of the form:

 

     License checkout for feature Product.CPU.Cortex-A53 was denied by product definition

 

This is due to not correctly setting DS-5 Ultimate Edition in the ARM License Manager (available from the DS-5 GUI's Help menu). If this is not set, it can be worked around by adding the “--tool_variant=ult” option to the command line, or to the below environment variables (that augment the command line):

 

     ARMCOMPILER6_ASMOPT=--tool_variant=ult

     ARMCOMPILER6_CLANGOPT=--tool_variant=ult

     ARMCOMPILER6_FROMELFOPT=--tool_variant=ult

     ARMCOMPILER6_LINKOPT=--tool_variant=ult

 

 

DS-5 Version

Compiler VersionDate
5.00N/AJuly 2010
5.01N/AAugust 2010
5.02N/A

September 2010

5.03N/ADecember 2010
5.04N/AFebruary 2011
5.055.00May 2011
5.065.00u1July 2011
5.06a5.00u1August 2011
5.075.01September 2011
5.07b5.01November 2011
5.085.01u1November 2011
5.085.01u1January 2012
5.095.01u2March 2012
5.105.01u3May 2012
5.115.01u4July 2012
5.125.02October 2012
5.135.02u1December 2012
5.145.03March 2013
5.155.03u2June 2013
5.165.03u3October 2013
5.175.04December 2013
5.17.15.04January 2014
5.185.04u1 / 6.00April 2014
5.18.15.04u1 / 6.00u1May 2014
5.195.04u2 / 6.00u1July 2014

 

You can download all versions of DS-5 here.

Micrium uC/OS goes ARMv8-A

 

In case you've missed it: Micrium announced yesterday support for ARM Cortex-A50 series of 64-bit processors in both uC/OS II and uC/OS III RTOSs. As a key embedded operating system partner within the ARM ecosystem, we are very happy see Micrium achieve this milestone, supported by ARM tools. You can read the full story here: Micrium Paves the Way with ARMv8 RTOS Support | Micrium

 

Get a head start on your software development

 

The tools your need to accelerate your ARMv8 project, including simulator models, are available now from ARM. Check out ARM DS-5 Ultimate Edition.

ARM® Compiler 6 is the next generation C/C++ compilation toolchain from ARM, based on Clang and the LLVM Compiler framework. Version 6.00 of the toolchain provides architectural support for v8 of the ARM Architecture and alpha support for v7-A. It can be used in conjunction with ARM DS-5 Development Studio to build and debug ARMv8 executable code. In this blog post, we shall look at the scalability benefits that LLVM brings for solving code generation problems for modern microarchitectures that are complex and product designs that are demanding in terms of performance and functionality. We shall also explore how the collaborative open source development process helps in responding to the challenges of ever shorter design cycles, by making tools development more agile and efficient.

 

The power of modular design, optimizer and IR

The compiler in ARM Compiler 6 toolchain is armclang, based on Clang, a C/C++ front end for the LLVM code-generation framework. LLVM is designed as a set of reusable libraries with well defined interfaces. In comparison, armcc, the compiler in ARM Compiler 5 is composed of modules with less well defined interfaces and separation, which makes the parts less reusable across a larger code generation problem space. armclang strictly adheres to the three phase LLVM design with a front end parser and syntax checker, a mid end optimizer and code generators that produce native machine code in the backend. The three phases have clear separation in terms of their intended function and this aspect of LLVM makes it reusable and flexible.

 

LLVM IR, or Intermediate representation, is the glue that connects the three phases. LLVM IR is the only interface to the optimizer and is designed as a first-class language with well defined semantics. LLVM IR was designed from ground up, with supporting common compiler optimizations in mind. The optimizer itself is designed as a set of passes that apply transformations to the input IR to produce IR that feeds into the code generator, which then can produce efficient machine code. The library based design of the optimizer allows the toolchain designers to select passes and optimizations that are most relevant for the given application domain and produce efficient code with minimum effort.

 

LLVM framework also makes it easier to add new targets, e.g. by using target description (.td) files to concisely describe a large part of the target architecture in a domain-specific language. Partners also have the option of adding their own backends for custom DSPs or GPUs as plugins into the toolchain. The code generator itself is based on several built-in passes for common problems like instruction selection, register allocation, scheduling etc, so adding new code generators from scratch is relatively easy. The expressiveness of target description syntax is being continuously improved, so that it becomes easier to add targets in the future. The modular design and robust LLVM IR format yields itself well to specialized code generation challenges such as security related extensions sometimes found on embedded microcontrollers .

 

ARM Compiler 6 comes with optimized libraries and armlink, an industrial strength linker that has been developed over the years as part of the ARM Compiler toolchain and this nicely complements the benefits accrued from LLVM as detailed above. For example, we expect to introduce link time optimization in a future version of the product that would bring together the benefits of LLVM technology for optimization (leveraging the support for bitcode format in LLVM) and the time tested robustness of armlink. When introduced, this would enable optimization across library boundaries which was not possible using older versions of ARM Compiler. By applying ARM’s best-in-class embedded libraries, ARM Compiler 6 generates highly optimized library functions tuned specifically for the ARM architecture, improving both performance and power consumption.

 


The power of open source – Agile innovation in a collaborative environment

LLVM is licensed under the University of Illinois/NCSA Open source license which means

  1. you can freely distribute LLVM
  2. commercial products can be derived from LLVM (which ARM Compiler 6 is an example of) with few restrictions
  3. there is no requirement to make derived works open source


LLVM development happens in the open, with contributions committed to the codebase on a regular basis. Each contribution is evaluated on its merits by a rigorous development process that involves community led code reviews, addition of new tests for the contribution and qualification by a 100% pass rate on existing regression tests before it gets accepted into the codebase. The support for ARMv8 Advanced SIMD introduced in the LLVM AArch64 backend for ARMv8 is a good example of a successful result of this process in action, where ARM and Qualcomm collaborated in the community to deliver a well validated piece of functionality to upstream LLVM. The AArch64 backend itself is validated and kept free of regressions by means of a community hosted buildbot which tests whether Clang can correctly cross-compile itself and runs LLVM regression tests using the cross-compiled Clang, targeting an AArch64 Linux platform. This means ARM partners bringing products to market can focus on true differentiating factors and spend less in terms of software development effort on the correctness and quality of common code generation. This development model cuts waste and prevents fragmentation of code generation efforts across the partnership. ARM is at the heart of a rich ecosystem of silicon partners, tools vendors, EDA, OEM and software development partners and combining the strength of the partnership with that of the open development model helps in speeding up innovation across the segments that the partnership operates in.

 


We'd like to hear from you!

We have seen how ARM Compiler 6 makes use of the modular design of LLVM and how this can help to solve code generation problems for product designs based on the ARM architecture. This is the first version of the product in which we are switching from proprietary compiler technology (whose origins date back to the initial days of the ARM architecture itself) to LLVM and what an exciting transition this has been! With the successful transition, I believe we are on a firm foundation to meet the code generation challenges posed by superscalar architectures with multiple pipeline stages, heterogeneous multi-processors, and exacting power efficiency requirements. We would love to hear from partners who wish to collaborate on LLVM technology and/or on ARM Compiler 6. ARM Compiler 6 is supported initially in DS-5 Ultimate Edition. If you are interested in evaluating ARM Compiler 6, you can request an evaluation by going to DS-5 Ultimate Edition.

Filter Blog

By date:
By tag: