1 2 3 Previous Next

ARM and Keil Tools

95 posts

For the last TechCon, my colleage Bob Boys has created a comprehensive application note that tells you how to create a middleware applications using CMSIS-Drivers and our middleware that comes with Keil MDK-ARM Professional. You'll learn how to start a project from scratch, adding features as you go. The application note explains how to setup, debug and run a CMSIS-compliant application using CMSIS-RTOS RTX, USB and graphic display capabilities. It uses the STMicroelectronics STM32F429IDISCOVERY kit, but works similarly with all ARM Cortex-M based microcontrollers and development boards that have CMSIS-Drivers available (for example the MDK5 - KeilMCB1800 based on NXP LPC1857).


Check out the application note on the Keil website: Application Note 268: Creating a CMSIS Middleware Application

Happy Friday!! This week is over and that is a beautiful thing. I am going to celebrate finishing my operating systems midterm by answering a rtx question today.

This week is from the Connected Community:

"Hi Experts,


There is code pieces on Full context and reduced context in the RTX code.


What this is actually intended for ?"


Full context Vs Reduced Context  techguyz



There are 2 types of task switch in RTX library for ARM7 and ARM9: reduced context switch and full context switch.

Reduced context switch does not store all registers to the stack on task switch. The advantage of this move is to make the system more efficient in that the switch is faster and requires less space on the stack. Some functions that utilize this type are os_tsk_pass, os_dly_wait, os_sem_wait, etc.

Then there is the full context switch that stores all registers to the stack. This task switch is slower and needs more space on the stack, ideal for swithces with timeouts (i.e. round robin). Some of the functions that utilize the full context are os_dly_wait and isr_evt_set.

Since the rate of the context switch can make or break a real-time operating system's ability to process efficiently, RTX takes advantage of the reduced context to save time wherever possible and full context in functions where the register contents are too critical to omit.

It's also worth noting that this is not relevant for Cortex-M processors, which use the CMSIS-RTOS compliant version of RTX. 



MCB2300 Influence of TCPnet on RTX scheduler

TestPCF8563.rar RTX_Config.c

For some time msr and mrs works on CP15 registers, so instead of using the cryptic


mrc p15,0,r0,c0,c0,5     ; hint: r0 = MPIDR


it can be as simple as


mrs r0,MPIDR

Unfortunatley, it just works for 32 bit registers. For 64 bit registers there is still just mcrr and mrrc

So here is a macro that solves this:


    m__op64 $op,$reg0,$reg1,$coproc,$opcode,$crn
        $op $coproc,$opcode,$reg0,$reg1,$crn

    m_op64 $sReg,$op,$reg0,$reg1
        IF ("$sReg" = "PAR")
            m__op64 $op,$reg0,$reg1, p15,0,c7
        ElIF ("$sReg" = "TTBR0")
            m__op64 $op,$reg0,$reg1, p15,0,c2
     ; .....
     ; ..... add more regs here
     ; .....
            INFO 42,"$sReg"
            ASSERT {FALSE}

    ; "m_msrr" works like "msr", but puts two core regs into one
    ; 64 bit reg
    m_msrr $sReg,$reg0,$reg1
        m_op64 $sReg,mcrr,$reg0,$reg1

    ; "m_mrrs" works like "mrs", but puts one 64 bit into two
    ; core regs
    m_mrrs $reg0,$reg1,$sReg
        m_op64 $sReg,mrrc,$reg0,$reg1


So now you can write things like


  m_mrrs r0,r1,PAR
  m_msrr TTBR0,r0,r1


And one day, when armasm implements msrr and mrrs all it take is removing the "m_" there.....


Join us for a live webinar on Wednesday 22nd October 1:00 pm EDT (10:00 am PDT) to learn how ARM tools can be used more widely for safety-related development, now that the ARM Compiler toolchain is fully certified by TÜV SÜD, a recognized safety industry expert. This will be hosted by Daniel Owens, ARM Compiler Product Manager, and Johannes Bauer, Keil MDK Product Manager.


The webinar will feature the TÜV certified ARM Compiler and Qualification Kit, support for coding standards and code coverage in Keil MDK. This enables anyone deploying ARM products into a variety of safety-related sectors (for e.g. automotive, industrial control, railway, aerospace and medical), to reduce risk and gain confidence that the system is functioning according to design.


The TÜV certified compiler and compiler Qualification Kit are now part of both Keil MDK-ARM Professional Edition and DS-5 Development Studio Ultimate Edition.



Register for your place »

We've been showcasing the latest and greatest tools for ARM software development over the last couple of days at TechCon 2014 in Santa Clara. It's been a busy week, with plenty of announcements from our friends at ARM Mali Graphics and mbed along with lots of questions and feedback from engineers already using our tools.


Here's my summary of what we've been demonstrating or announcing this week in the world of tools:


DS-5 Development Studio

We've been using DS-5 Development Studio Ultimate Edition coupled with DSTREAM for JTAG debug and trace of the Cortex-A53x4 and Cortex-A57x2 based Juno Development Platform. DS-5 handles connections to individual cores, clusters or the whole system, depending on what you want to target. Upcoming changes to the registers view allow you to easily see the split between AArch64 and AArch32 registers, whilst the disassembly and trace views handle ARMv8 instructions just as they had previously handled earlier instruction sets. Many of our visitors asked about the debugging experience of ARMv8, so it was great to be able to show the jump from AArch64 to AArch32 when launching 32-bit apps such as Angry Birds on our 64-bit Android OS.


DS-5 has now been around for over 4 years, so we spend a lot of time at events like this catching up with customers who have been successfully developing ARM software using our tools. It's been great to hear feedback from DS-5 users and a lot of fun showing off the features that our engineering teams have worked hard to develop since the previous TechCon. If you're a DS-5 user, I encourage you to sign up to our monthly developer newsletter, which shows you how to use each new feature to solve every day programming problems.


Streamline and OpenCL for NEON

Streamline has always been a popular tool with engineers at exhibitions across the world and TechCon has been no different. With counters to support ARMv8 profiling, as well as a slick live capture mode, Streamline is now a firm favorite for system optimization with software development studios.


One of the announcements this week was around OpenCL support between GPU and CPUs with NEON, using Streamline to demonstrate the dependencies. This is a great extension of the OpenCL mode that we released earlier this year and should help to make compute processing a whole lot easier for developers. Read more here: Heterogeneous Multiprocessing Gets a Boost with the New OpenCL for NEON Driver


Keil MDK-ARM v5

Reinhard Keil was here this week to show off new features in MDK, including the software packs concept, demonstrating how easy it is to carry out microcontroller software development when you have access to the extensive range of middleware that is included in the packs. Along with Bob Boys, Reinhard delivered a training session to explain the concept of CMSIS-Drivers in order to create a USB application faster using the CMSIS software framework. 


V Certified Compiler

Another exciting announcement this week is that we are including a certified version of ARM Compiler 5, with long term support in MDK Professional and DS-5 Ultimate Edition. This makes software development for safety critical applications easier in both tools, especially for IEC 61508 and ISO 26262. We also include the ARM Compiler Qualification Kit to assist you in making your compliance case. This struck a chord with a lot of developers who were working on automotive software projects who dropped by the booth, so we hope it will be useful to many of you.


Fast Models and Fixed Virtual Platforms

Rob Kaye was on hand to deliver a great set of demos showing the integration between ARM Fast Models and DS-5. With model trace and Streamline for models in development, he gave visitors a glimpse into the future of models and was kept busy both days by the number of engineers already using models for ARM software development.


Of course, there have been new features and announcements from all of the software tools providers in our ARM ecosystem. My colleague Andy Frame (@andyframe_ARM) took on the role of roving reporter this week to cover their exciting news. Check out his blog here: Day 1 of TechCon 2014 with Simon Segars, Atmel MCUs, Freescale Kinetis, STMicroelectronics STM32 F7, HP Moonshot, Dell s…


What did you think?

Were you at TechCon? Did you come and visit any of the ARM software tools teams? Let us know what you thought in the comments below... and see you all next year!

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.



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:



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.




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



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



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



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).




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



! 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:


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.




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:



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


  8GB 1600MHz DDR,

  64MB user NOR FLASH,


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:



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




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:



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




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:



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:




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.



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.




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:




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.




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.




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.


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:


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



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


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.


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


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.


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.


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:


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.


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:


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.


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.



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


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



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.

Filter Blog

By date:
By tag: