1 2 3 Previous Next

ARM and Keil Tools

90 posts

Freescale will be hosting their Design with Freescale event in São Paulo on October 8th, and I will be there to support the technology sessions and the Technology Lab, demonstrating ARM's software tool solutions that support all of Freescale's ARM based Portfolio.

 

As you likely know if you are reading this, ARM is ubiquitous in the industry from sensors to servers. Freescale similarly offer ARM based products, from Kinetis MCUs, through the Vybrid and i.MX series of Application processors, to advanced Layerscape Networking solutions.

 

ARM tools support these devices with Keil MDK toolchain and DS-5 Development Studio as appropriate. Furthermore there are a variety of Freescale platforms supporting the mbed Development Platform.

 

Also at the event, my colleague Drew Barbier will talk about the ARM Accredited Engineer (AAE) program. This is a run-through of the subject matter covered by the ARM Accredited MCU Engineer accreditation, focusing on software aspects of the ARMv-6M and ARMv7-M Microcontroller architectures as implemented in the Cortex-M processor family. Drew will offer a look into the subject matter needed for the exam, in order to benefit from the industry-recognized qualification.

 

I look forward to meeting you there!

Visit us at the ARM Techcon in USA or at the Conference for ARM-Systems in Germany to learn about the new innovations for Cortex-M microcontrollers and the related CMSIS software standard.

 

Santa Clara, USA, October 1 - 3, 2014

The ARM TechCon 2014 in Santa Clara is a great event to get the latest information about the Cortex-M processors and the numerous microcontroller families that are based on that processor technology.

 

Visit the ARM booth for an in-dept demonstration of the Keil MDK Microcontroller Development Kit Version 5 that incorporates the Run-Time Environment (RTE). With RTE you compose sophisticated software frameworks for your embedded application from pre-built CMSIS and middleware software components.

 

Don't miss on October 2, the session Create an USB Application Using CMSIS-Drivers. In this TechCon conference session you will learn the benefits of CMSIS-Driver for creating microcontroller applications. During a 50 minute training session, Bob Boys and Reinhard Keil explain the concept of the CMSIS-Drivers. An example USB application shows how CMSIS-Drivers help to create embedded applications for supported Cortex-M microcontrollers faster by using the industry standard CMSIS software framework. The first 30 attendees registered to that TechCon workshop will get a complementary evaluation board and a full 60-day license for MDK-Professional which allows you to replicate the projects.

 

Munich, Germany, October 8 - 9, 2014

The Konferenz für ARM-Systementwicklung" in Munich is just one week after the ARM TechCon. This event is a great opportunity to get the latest update from ARM specialists and other ARM partners. Dr. Krisztian Flautner, Vice President Research & Development ARM, presents on 9. October 2014 his keynote on the topic Internet of Things and explains how this applies to industrial and automotive applications.

 

Other ARM speakers at this event cover the following topics:

  • Cortex-M – The best fitting architecture for my application: Dr. Ian Johnson
  • CMSIS – faster Software Development using software components such as DSP Library: Christopher Seidl
  • Benchmarking of Microcontrollers: Joseph Yiu
  • ARM big.LITTLE Technology: Why? What? How?: Kinjal Dave
  • Real-time hypervisors for safer control systems: Chris Turner
  • Building High End, Low Power Wearable SoCs using Application Processors: Kinjal Dave

Last month I covered the details of using ARM Compiler 6 to compile bare metal software included in Carbon Performance Analysis Kits (CPAKs) for ARMv8 processors such as the Cortex-A53. This time I will outline the flow used to connect ARM DS-5 version 5.19 to debug software. DS-5 is a full set of tools for end-to-end software development for ARM processors and includes the ability to connect to cycle accurate models running in SoC Designer and debug software.

 

Overview of DS-5 to SoC Designer Connection

 

Setting up SoC Designer for use with DS-5 involves the following steps:

  1. Use a DS-5 supplied program called cdbimporter to create a DS-5 configuration database.
  2. Add the configuration database to the list of systems to which DS-5 can connect.
  3. Create a DS-5 Debug Configuration which specifies the system to connect to and the software to debug.
  4. Connect to a SoC Designer simulation using the Debug Configuration to perform software debugging tasks.

 

This article presents a summary of the flow. The last two steps are common to debugging with eclipse, but the first two steps may be new to eclipse users. There is an application note in the SoC Designer release which provides additional information about cdbimporter. SoC Designer users can look at the file $MAXSIM_HOME/doc/DS5_App_Note.pdf

 

Generating a DS-5 Configuration Database

 

The database is created with a DS-5 utility called cdbimporter, which provides a number of useful features to help automate the process such as:

  • Query the host machine for running CADI servers
  • Identify the simulation of interest
  • Identify the cores included in the simulation
  • Generate the configuration database

 

I will use a Cortex-A53 Baremetal CPAK with SoC Designer 7.14.6 for reference.

 

a53x1 resized 600

To set up the DS-5 configuration database start the simulation as specified in the CPAK README file and load the software. Do not start running the simulation.

 

Run the simulation:

 

$ sdsim -b A53-cpak.conf -b $MAXSIM_PROTOCOLS/etc/Protocols.conf Systems/A53v8-MP1-CCI400.mxp

 

Then load the sorts_v8.axf file from the Applications/ directory and go to the shell prompt to run cdbimporter.

 

Setup the DS-5 shell environment using the path to your DS-5 installation:

 

$ /o/tools/linux/ARM/DS5_5.19/64bit/bin/suite_exec_ac6 bash

 

Now cdbimporter should be in the PATH and ready to run.

 

The output from cdbimporter is a directory containing the DS-5 configuration database which will be used in the next step.


Add the Configuration Database to DS-5

 

The next step is to make DS-5 aware of the new configuration database. Start by launching eclipse and set the workspace directory.

 

Import the database generated by cdbimporter as follows:
Open the Preferences page from the menu: Windows -> Preferences.
From the Preferences popup, select DS-5-> Configuration Database -> Add. The Add configuration database location dialog opens:

 

Capture1 resized 600

 

Use the Browse button to navigate to the directory which contains the configuration database created in the first step.

 

Use the Name field to name this database for later identification in the Preferences (it can also be left blank).
Click OK to close the Add configuration database location dialog.
Click OK again to close the Preference window. You will see a dialog box indicating it is adding the new database.

 

The configuration database is now included in the DS-5 list of target systems.

 

Create a DS-5 Debug Configuration

 

The next step is to create a DS-5 Debug Configuration that creates the connection to the system to be debugged.

 

Start the DS-5 debug perspective as follows:

 

From the top menu, select Windows -> open perspective -> DS5 Debug.

 

From the top menu, select Run > Debug Configurations… (or right-click from the upper left “Debug Control” view and select debug configurations -> DS-5 Debugger).

 

From the “Debug Configurations” pop up, right-click on DS5-Debugger and select New.

 

On the Connection tab, close default groups, then scroll down and select the imported system; e.g., Carbon > A53-MP1-CCI400.mxp > Bare Metal Debug > Debug Cortex-A53_0

 

Capture2 resized 600


On the Files tab select the .axf file of the application, in this case sorts_v8.axf.

 

Load symbols from file assumes you already loaded the application to debug from SoC Designer. To load the application from DS-5 instead, enter the name in the Application on host to download box and the application will be written to memory when the debugger connects.

 

Capture3 resized 600

 

On the Debugger tab, in the Run Control panel, select "Connect only."

 

Capture4 resized 600


Connect DS-5 to a SoC Designer Simulation and Debug Software

 

The final step is to launch the Debugger Configuration and connect to the SoC Designer simulation. You can do this immediately using the Debug button on the lower right of the Debug Configurations dialog.

 

You can also use the Debug Control tab by right-clicking on the connection and selecting “Connect to Target” from the context menu (shown below).

 

Capture5 resized 600

 

After the debugger is connected the status is shown as “connected”:

 

Capture6 resized 600


After connection, DS-5 can be used to debug the software running on the SoC Designer simulation.


Simulation on Another Machine or Port

 

If multiple simulations are starting and stopping there is a chance the port number the simulator is using is different than it was when the configuration database was created. The first simulation is normally port 7000, then the next is 7001. The numbers will recycle as simulations start and stop. It’s not necessary to start from scratch and create a new configuration database. There is an environment variable that is the easiest way to adjust to a new port number:

 

For bash I use:

 

$ export CADI_TARGET_MACHINE=localhost:7001

 

This environment variable can also be used to connect to a simulator on another machine by using the name or IP address of the machine which has the running simulation.


Conclusion

 

This summary covered the steps to connect DS-5 to SoC Designer. DS-5 is the best debugger to handle bare metal software for the AARCH64 state compiled with ARM Compiler 6 and DWARF4 debug information. Make sure to review the application note provided with each SoC Designer release for the latest information.

 

Jason Andrews

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.

Having started at ARM about a week ago, I have been very excited to work on Juno, ARM's first 64-bit Development Platform.

Juno is aimed at accelerating the development of 64-bit software for the mobile and enterprise markets. Based on the ARMv8-A big.LITTLE™ architecture, Juno offers software developers an open, vendor neutral, reference platform for 64-bit software development. Interestingly, Linaro has also released an Android Open Source Project (AOSP) port for the 64-bit ARMv8-A architecture. The entire software stack for the platform is now available through Linaro. The software bundle includes ARM Trusted Firmware, Linux file systems and a Linux kernel (3.10) that can support both OpenEmbedded Linux and Android (AOSP) file systems.


Juno is aligned with the ARM® Server Base Architecture (SBSA), which means that developers can use the system for early access of porting and performance-tuning OS kernel or driver code to the 64-bit architecture, based on the ARM® Cortex®-A57 and ARM Cortex-A53 processors. This means Juno creates a common foundation for the software developers in the ARMv8 ecosystem and allows early access to the silicon. For the hardware vendors, Juno provides the entire ARMv8 IP portfolio working together in a big.LITTLE™ implementation, delivering high performance and low power consumption.

 

The timing of the platform release is important, as Google recently announced the details of the their "Android L", which would include a new Virtual Machine "ART" to support both 32 and 64-bit ARM architectures. The platform definitely aims to accelerate the time to market for future 64-bit ARM designs.


Hardware Overview

 

Juno Design.jpg

 

The Juno SoC was built by ARM with an aim to keep the implementation functionally correct so that it can be representative of a potential mobile platform. Therefore, like many development platforms, Juno isn't meant to deliver highest standards of performance or efficiency. It is meant

to enable software developers to port their applications to 64-bit ARMv8-A. Juno includes ARM's own Mali™-T624 graphics processor, the mobile-focused CCI-400, dual DDR3 memory controllers, and an ARM® Cortex® M3 System Control Processor that handles SoC-level power management and system control. Juno also offers SoC hardware expansion for customers wishing to implement their own custom RTL designs. This is enabled through the LogicTile design and Thin Links technology, which can be used to prototype custom CPU, GPU and peripheral designs. Lets have a quick look at Juno hardware specs:

 

FeatureDetails
CPUs

ARM® Cortex®-A57 MP2 cluster

    Speed: 1.1GHz (Overdrive)

    Caches: L1 48KB I, 32KB D, L2 2MB

 

ARM® Cortex®-A53 MP4 cluster

    Speed: 850MHz (Overdrive)

    Caches: L1 32KB, L2 1MB

GPUsARM® Mali™-T624 MALI T624

   Speed: 600MHz

   Caches: L2 128KB

Memory

  8GB 1600MHz DDR,

  64MB user NOR FLASH,

  256KB SRAM in IOFPGA

SoCARM® CoreSight ETM/CTI per core,

VFS and power gating,

4 energy meters,

DMC-400 dual channel DDR3L interface,

Internal CCI-400, 128-bit, 533MHz

Rest of SoC

Internal NIC-400, 64-bit, 400MHz

DMAC : PL330, 128-bit

Static Memory Bus Interface : PL354

HDCLD dual video controllers: 1080p

Expansion support

AXI expansion to FPGA daughterboard

USB 2.0 with 4 port hub

Debug & Trace

ARM® JTAG : 20-way DIL box header

ARM® 32/16 bit parallel trace

 

Software Overview

ARM has been working closely with Linaro to provide a stable software stack that includes low-level firmware for runtime services and high-level file systems such as OpenEmbedded Linux and Android (AOSP).

Linaro ARMv8 ports are based on Linux kernel 3.10 (Linaro Stable Kernel), and compiled with GCC 4.9 and can run both Juno and ARMv8 fast models. The entire software stack for Juno is available through the Linaro website.

 

linaro website.png

 

Let's drill-down into the different software components:

 

SoftwareDescription

MCC Microcontroller Firmware

The MCC firmware takes care of early setup before the SCP or application processors are powered on. The MCC is also responsible for managing firmware upgrades.

Systems Control Processor (SCP) Firmware

The SCP firmware loads the runtime that provides low level power management and system control for the Juno platform.
ARM Trusted FirmwareThe ARM Trusted Firmware provides an open source framework enabling easy integration of secure OS and run-time services to ARMv8-A platforms. The project has been hosted as an open-source project on GitHub
Unified Extensible Firmware Interface (UEFI)The Juno UEFI implementation provides Linux loader support for the Juno platform. It is based on the open source EFI Development Kit 2 (EDK2) implementation from the Tianocore sourceforge project.
A 64-bit Linux Kernel with big.LITTLE™ and Mali supportThe Linux Kernel can support both Android and OpenEmbedded file systems. It is being managed by Linaro and can be downloaded from the Linaro website as a part of the entire software stack.
Linux-based file systemsThis includes Android Open Source Project (AOSP) and OpenEmbedded Linux. Linaro has been responsible for porting AOSP to 64-bit ARM and will be maintaining this project. It can be downloaded from the Linaro website along with other software deliverables.


Clearly, Juno offers software developers and system architects a robust product stack including cutting-edge hardware and software, which would serve as a firm baseline for testing future 64-bit ARM-based designs. It has received a lot of attention in the press. A simple Google News search on "Juno ARM 64-bit" would yield a number of blogs and news articles on the Juno platform, including details about the software stack provided by Linaro. Some of the top links are listed below.

 

ARM Unveils Juno Platform for 64-Bit Development

ARM arms devs for 64-bit push with 'Juno' board • The Register

ARM releases Juno dev platform for 64-bit computing - Software - News - HEXUS.net

ARM-Launches-New-Reference-Platform-For-64bit-Developers-Bakes-In-Linaro-Support

 

Support

For support and queries around the Juno platform, contact:  juno-support@arm.com


Getting Started

In order to get started with the Juno board, a detailed getting-started guide can be found here.

 

If you want to learn how you could get Android installed on Juno, watch the following TUTORIAL: Installing Android on Juno ARM Development Platform

 

Additional Links

Juno ARM Development Platform Technical Reference manual

Juno ARM Development Platform datasheet

Juno ARM Development Platform Technical Overview

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

Juno was announced yesterday along with Android (AOSP) support via Linaro.  It is available to order from ARM or distributors in limited quantities (SAP code V2M-Juno-0317B).   Details on the platform are available here:  www.arm.com/juno

Juno was designed to accelerate the porting and optimization of code for ARMv8-A platforms, it is suitable for companies that want early access to advanced hardware.

 

Normal World Software available now

 

Less well known is that the Juno board is a focus for our ARM Trusted Firmware OSS project so that Trusted OS developers can port easily to ARMv8-A  on a generic platform.   You can find out  more about ARM Trusted Firmware here and download the source  code:

https://github.com/ARM-software/arm-trusted-firmware

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.

Filter Blog

By date:
By tag: