DOCSLIB.ORG

IAR Embedded Workbench C-SPY Debugging Guide for V850

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
IAR Embedded Workbench C-SPY Debugging Guide for V850 IAR Embedded Workbench® C-SPY® Debugging Guide for the Renesas V850 Microcontroller Family UCSV850-2 COPYRIGHT NOTICE © 2011–2015 IAR Systems AB. No part of this document may be reproduced without the prior written consent of IAR Systems AB. The software described in this document is furnished under a license and may only be used or copied in accordance with the terms of such a license. DISCLAIMER The information in this document is subject to change without notice and does not represent a commitment on any part of IAR Systems. While the information contained herein is assumed to be accurate, IAR Systems assumes no responsibility for any errors or omissions. In no event shall IAR Systems, its employees, its contractors, or the authors of this document be liable for special, direct, indirect, or consequential damage, losses, costs, charges, claims, demands, claim for lost profits, fees, or expenses of any nature or kind. TRADEMARKS IAR Systems, IAR Embedded Workbench, C-SPY, C-RUN, C-STAT, visualSTATE, Focus on Your Code, IAR KickStart Kit, IAR Experiment!, I-jet, I-jet Trace, I-scope, IAR Academy, IAR, and the logotype of IAR Systems are trademarks or registered trademarks owned by IAR Systems AB. Microsoft and Windows are registered trademarks of Microsoft Corporation. Renesas is a registered trademark of Renesas Electronics Corporation. V850 is a trademark of Renesas Electronics Corporation. Adobe and Acrobat Reader are registered trademarks of Adobe Systems Incorporated. All other product names are trademarks or registered trademarks of their respective owners. EDITION NOTICE Second edition: October 2015 Part number: UCSV850-2 This guide applies to version 4.x of IAR Embedded Workbench® for the Renesas V850 microcontroller family. The C-SPY® Debugging Guide for V850 replaces all debugging information in the IAR Embedded Workbench IDE User Guide for V850 and the hardware debugger guides for V850. Internal reference: M18, Hom7.2, IJOA. C-SPY® Debugging Guide 2 for V850 AFE1_AFE2-1:1 Brief contents Tables ...................................................................................................................... 19 Preface .................................................................................................................... 21 Part 1. Basic debugging ................................................................ 27 The IAR C-SPY Debugger ........................................................................... 29 Getting started using C-SPY ....................................................................... 39 Executing your application ........................................................................... 69 Variables and expressions ............................................................................ 87 Breakpoints ........................................................................................................ 123 Memory and registers .................................................................................. 149 Part 2. Analyzing your application ................................ 185 Trace ...................................................................................................................... 187 Profiling ................................................................................................................ 217 Code coverage ................................................................................................. 227 Part 3. Advanced debugging ................................................. 231 Interrupts ............................................................................................................ 233 C-SPY macros ................................................................................................. 253 The C-SPY command line utility—cspybat ....................................... 307 Part 4. Additional reference information ............. 321 Debugger options ........................................................................................... 323 Additional information on C-SPY drivers .......................................... 331 3 AFE1_AFE2-1:1 Using the MINICUBE2 emulator ............................................................ 351 Index ..................................................................................................................... 357 4 AFE1_AFE2-1:1 Contents Tables ...................................................................................................................... 19 Preface .................................................................................................................... 21 Who should read this guide ............................................................... 21 Required knowledge .......................................................................... 21 How to use this guide ........................................................................... 21 What this guide contains ..................................................................... 22 Part 1. Basic debugging ..................................................................... 22 Part 2. Analyzing your application .................................................... 22 Part 3. Advanced debugging .............................................................. 23 Part 4. Additional reference information ........................................... 23 Other documentation ........................................................................... 23 User and reference guides .................................................................. 23 The online help system ...................................................................... 24 Web sites ............................................................................................ 24 Document conventions ........................................................................ 25 Typographic conventions ................................................................... 25 Naming conventions .......................................................................... 26 Part 1. Basic debugging ................................................................ 27 The IAR C-SPY Debugger ........................................................................... 29 Introduction to C-SPY .......................................................................... 29 An integrated environment ................................................................. 29 General C-SPY debugger features ..................................................... 30 RTOS awareness ................................................................................ 31 Debugger concepts ................................................................................ 31 C-SPY and target systems .................................................................. 32 The debugger ...................................................................................... 32 The target system ............................................................................... 32 The application ................................................................................... 33 C-SPY debugger systems ................................................................... 33 5 AFE1_AFE2-1:1 The ROM-monitor program ............................................................... 33 Third-party debuggers ........................................................................ 33 C-SPY plugin modules ....................................................................... 33 C-SPY drivers overview ....................................................................... 34 Differences between the C-SPY drivers ........................................... 35 The IAR C-SPY Simulator .................................................................. 35 The C-SPY hardware debugger drivers ........................................ 36 Communication overview .................................................................. 36 Installing the EXEC interface drivers ................................................ 37 Getting started using C-SPY ....................................................................... 39 Setting up C-SPY .................................................................................... 39 Setting up for debugging .................................................................... 39 Executing from reset .......................................................................... 40 Using a setup macro file ..................................................................... 40 Selecting a device description file ..................................................... 41 Loading plugin modules ..................................................................... 41 Starting C-SPY ......................................................................................... 41 Starting a debug session ..................................................................... 42 Loading executable files built outside of the IDE .............................. 42 Starting a debug session with source files missing ............................ 42 Loading multiple images ................................................................... 43 Adapting for target hardware ........................................................... 44 Modifying a device description file ................................................... 44 Initializing target hardware before C-SPY starts ............................... 45 Running example projects .................................................................
Load more

Recommended publications
  • Hardware Realization of an FPGA Processor – Operating System Call Offload and Experiences
    Downloaded from orbit.dtu.dk on: Oct 02, 2021 Hardware Realization of an FPGA Processor – Operating System Call Offload and Experiences Hindborg, Andreas Erik; Schleuniger, Pascal; Jensen, Nicklas Bo; Karlsson, Sven Published in: Proceedings of the 2014 Conference on Design and Architectures for Signal and Image Processing (DASIP) Publication date: 2014 Link back to DTU Orbit Citation (APA): Hindborg, A. E., Schleuniger, P., Jensen, N. B., & Karlsson, S. (2014). Hardware Realization of an FPGA Processor – Operating System Call Offload and Experiences. In A. Morawiec, & J. Hinderscheit (Eds.), Proceedings of the 2014 Conference on Design and Architectures for Signal and Image Processing (DASIP) IEEE. General rights Copyright and moral rights for the publications made accessible in the public portal are retained by the authors and/or other copyright owners and it is a condition of accessing publications that users recognise and abide by the legal requirements associated with these rights. Users may download and print one copy of any publication from the public portal for the purpose of private study or research. You may not further distribute the material or use it for any profit-making activity or commercial gain You may freely distribute the URL identifying the publication in the public portal If you believe that this document breaches copyright please contact us providing details, and we will remove access to the work immediately and investigate your claim. Hardware Realization of an FPGA Processor – Operating System Call Offload and Experiences Andreas Erik Hindborg, Pascal Schleuniger Nicklas Bo Jensen, Sven Karlsson DTU Compute – Technical University of Denmark fahin,pass,nboa,[email protected] Abstract—Field-programmable gate arrays, FPGAs, are at- speedup of up to 64% over a Xilinx MicroBlaze based baseline tractive implementation platforms for low-volume signal and system.
    [Show full text]
  • Endian: from the Ground up a Coordinated Approach
    WHITEPAPER Endian: From the Ground Up A Coordinated Approach By Kevin Johnston Senior Staff Engineer, Verilab July 2008 © 2008 Verilab, Inc. 7320 N MOPAC Expressway | Suite 203 | Austin, TX 78731-2309 | 512.372.8367 | www.verilab.com WHITEPAPER INTRODUCTION WHat DOES ENDIAN MEAN? Data in Imagine XYZ Corp finally receives first silicon for the main Endian relates the significance order of symbols to the computers chip for its new camera phone. All initial testing proceeds position order of symbols in any representation of any flawlessly until they try an image capture. The display is kind of data, if significance is position-dependent in that regularly completely garbled. representation. undergoes Of course there are many possible causes, and the debug Let’s take a specific type of data, and a specific form of dozens if not team analyzes code traces, packet traces, memory dumps. representation that possesses position-dependent signifi- There is no problem with the code. There is no problem cance: A digit sequence representing a numeric value, like hundreds of with data transport. The problem is eventually tracked “5896”. Each digit position has significance relative to all down to the data format. other digit positions. transformations The development team ran many, many pre-silicon simula- I’m using the word “digit” in the generalized sense of an between tions of the system to check datapath integrity, bandwidth, arbitrary radix, not necessarily decimal. Decimal and a few producer and error correction. The verification effort checked that all other specific radixes happen to be particularly useful for the data submitted at the camera port eventually emerged illustration simply due to their familiarity, but all of the consumer.
    [Show full text]
  • Stackwalkerapi Programmer's Guide
    Paradyn Parallel Performance Tools StackwalkerAPI Programmer’s Guide 9.2 Release June 2016 Computer Sciences Department University of Wisconsin–Madison Madison, WI 53706 Computer Science Department University of Maryland College Park, MD 20742 Email [email protected] Web www.dyninst.org Contents 1 Introduction 3 2 Abstractions 4 2.1 Stackwalking Interface . .5 2.2 Callback Interface . .5 3 API Reference 6 3.1 Definitions and Basic Types . .6 3.1.1 Definitions . .6 3.1.2 Basic Types . .9 3.2 Namespace StackwalkerAPI . 10 3.3 Stackwalking Interface . 10 3.3.1 Class Walker . 10 3.3.2 Class Frame . 14 3.4 Accessing Local Variables . 18 3.5 Callback Interface . 19 3.5.1 Default Implementations . 19 3.5.2 Class FrameStepper . 19 3.5.3 Class StepperGroup . 22 3.5.4 Class ProcessState . 24 3.5.5 Class SymbolLookup . 27 4 Callback Interface Default Implementations 27 4.1 Debugger Interface . 28 4.1.1 Class ProcDebug . 29 4.2 FrameSteppers . 31 4.2.1 Class FrameFuncStepper . 31 4.2.2 Class SigHandlerStepper . 32 4.2.3 Class DebugStepper . 33 1 4.2.4 Class AnalysisStepper . 33 4.2.5 Class StepperWanderer . 33 4.2.6 Class BottomOfStackStepper . 33 2 1 Introduction This document describes StackwalkerAPI, an API and library for walking a call stack. The call stack (also known as the run-time stack) is a stack found in a process that contains the currently active stack frames. Each stack frame is a record of an executing function (or function-like object such as a signal handler or system call).
    [Show full text]
  • IAR Systems Brings Functional Safety Tools to RISC-V with Certification for IEC 61508 and ISO 26262
    Press release Date: October 20, 2020 IAR Systems brings functional safety tools to RISC-V with certification for IEC 61508 and ISO 26262 Stockholm, Sweden—October 20, 2020— IAR Systems®, the future-proof supplier of software tools and services for embedded development, further extends its strong tools offering for RISC-V by announcing a certified version of its development tools. The functional safety edition of IAR Embedded Workbench® for RISC-V will be certified by TÜV SÜD according to the requirements of IEC 61508, the international umbrella standard for functional safety, as well as ISO 26262, which is used for automotive safety-related systems. In addition, the certification covers the international standard IEC 62304, which specifies life cycle requirements for the development of medical software and software within medical devices, and the European railway standards EN 50128 and EN 50657. “We are seeing RISC-V becoming an important architecture not only in broad designs, but specifically in automotive applications,” said Stefan Skarin, CEO, IAR Systems. “By providing our development tools with certification according to ISO 26262, we enable the RISC-V community to further expand and more rapidly bring functional safety designs to the market. As a commercial tools vendor, we are able to provide global technical support as well as invest in keeping our products robust, maintained and qualified. Our certified tools will enable our customers to speed up the path to using RISC-V in safety-critical applications within automotive and other areas.” “We see a strong demand for RISC-V with safety among our customers, and the certification of IAR Embedded Workbench for RISC-V aligns perfectly with that demand,” said Frankwell Lin, President, Andes Technology.
    [Show full text]
  • Procedures & the Stack
    Procedures & The Stack Spring 2016 Procedures & The Stack Announcements ¢ Lab 1 graded § Late days § Extra credit ¢ HW 2 out ¢ Lab 2 prep in section tomorrow § Bring laptops! ¢ Slides HTTP://XKCD.COM/1270/ 1 Procedures & The Stack Spring 2016 Memory & data Roadmap Integers & floats C: Java: Machine code & C x86 assembly car *c = malloc(sizeof(car)); Car c = new Car(); Procedures & stacks c->miles = 100; c.setMiles(100); Arrays & structs c->gals = 17; c.setGals(17); float mpg = get_mpg(c); float mpg = Memory & caches free(c); c.getMPG(); Processes Virtual memory Assembly get_mpg: Memory allocation pushq %rbp Java vs. C language: movq %rsp, %rbp ... popq %rbp ret OS: Machine 0111010000011000 100011010000010000000010 code: 1000100111000010 110000011111101000011111 Computer system: 2 Procedures & The Stack Spring 2016 Mechanisms required for procedures ¢ Passing control P(…) { § To beginning oF procedure code • • § Back to return point y = Q(x); print(y) ¢ Passing data • § Procedure arguments } § Return value ¢ Memory management int Q(int i) § Allocate during procedure execution { § Deallocate upon return int t = 3*i; int v[10]; ¢ All implemented with machine • instructions • § An x86-64 procedure uses only those return v[t]; mechanisms required For that procedure } 3 Procedures & The Stack Spring 2016 Questions to answer about procedures ¢ How do I pass arguments to a procedure? ¢ How do I get a return value from a procedure? ¢ Where do I put local variables? ¢ When a function returns, how does it know where to return? ¢ To answer some of
    [Show full text]
  • IAR Systems Supports New Amazon Web Services Iot Microcontroller Operating System Amazon Freertos at Launch
    Press release Date: November 30, 2017 IAR Systems supports new Amazon Web Services IoT Microcontroller Operating System Amazon FreeRTOS at Launch Amazon FreeRTOS will be supported by the leading embedded development toolchain IAR Embedded Workbench Uppsala, Sweden—November 30, 2017—IAR Systems®, a leading supplier of software tools and services for embedded development, announces support for newly launched Internet of Things (IoT) Microcontroller Operating System, Amazon FreeRTOS. Together with Amazon Web Services (AWS), IAR Systems provides developers with easy access to high-performance, pre-integrated development tools for developing and debugging embedded and IoT-connected applications based on Amazon FreeRTOS. Amazon FreeRTOS provides tools that developers need to quickly and easily deploy a microcontroller- based connected device and develop an embedded or IoT application without having to worry about the complexity of scaling across millions of devices. Based on the FreeRTOS kernel, Amazon FreeRTOS includes software libraries which make it easy to securely connect devices locally to AWS Greengrass, directly to the cloud, and update them remotely. For new devices, developers can choose to build their embedded and IoT application on a variety of qualified microcontrollers from companies collaborating with AWS and IAR Systems, including Microchip, NXP, STMicroelectronics and Texas Instruments. Since 1983, IAR Systems’ solutions have ensured quality, reliability and efficiency in the development of over one million embedded applications. Now available for Amazon FreeRTOS users, development tools from IAR Systems deliver leading code optimizations and extensive debugging functionality. The technology is coupled with professional technical support offered globally. “AWS is pleased to be teamed with IAR Systems to provide developers with access to a high performance, pre-integrated set of development tools for developing and debugging connected applications,” says Richard Barry, Principal Engineer, Amazon Web Services, Inc.
    [Show full text]
  • MIPS Calling Convention
    MIPS Calling Convention CS 64: Computer Organization and Design Logic Lecture #9 Fall 2018 Ziad Matni, Ph.D. Dept. of Computer Science, UCSB Administrative • Lab #5 this week – due on Friday • Grades will be up on GauchoSpace today by noon! – If you want to review your exams, see your TAs: LAST NAMES A thru Q See Bay-Yuan (Th. 12:30 – 2:30 pm) LAST NAMES R thru Z See Harmeet (Th. 9:30 – 11:30 am) • Mid-quarter evaluations for T.As – Links on the last slide and will put up on Piazza too – Optional to do, but very appreciated by us all! 11/5/2018 Matni, CS64, Fa18 2 CS 64, Fall 18, Midterm Exam Average = 86.9% Median = 87% 26 22 8 5 3 11/5/2018 Matni, CS64, Fa18 3 Lecture Outline • MIPS Calling Convention – Functions calling functions – Recursive functions 11/5/2018 Matni, CS64, Fa18 4 Function Calls Within Functions… Given what we’ve said so far… • What about this code makes our previously discussed setup break? – You would need multiple copies of $ra • You’d have to copy the value of $ra to another register (or to mem) before calling another function • Danger: You could run out of registers! 11/5/2018 Matni, CS64, Fa18 5 Another Example… What about this code makes this setup break? • Can’t fit all variables in registers at the same time! • How do I know which registers are even usable without looking at the code? 11/5/2018 Matni, CS64, Fa18 6 Solution??!! • Store certain information in memory only at certain times • Ultimately, this is where the call stack comes from • So what (registers/memory) save what??? 11/5/2018 Matni, CS64, Fa18
    [Show full text]
  • MSP430 Family Object Format Converter Description 10-1 Topics
    MSP430 Family Object Format Converter Description Topics 10 Object Format Converter Description 10-3 10.1 Object Format Converter Development Flow 10-4 10.2 Extended Tektronix Hex Object Format 10-5 10.3 Intel Hex Object Format 10-6 10.4 TI–Tagged Object Format 10-7 10.5 Motorola S Format 10-8 10.6 Invoking the Object Format Converter 10-9 10.7 Object Format Converter Examples 10-10 10.8 Halt Conditions 10-11 Figures Fig. Title Page 10.1 Object Format Converter Development Flow 10-4 10.2 Extended Tektronix Hex Object Format 10-5 10.3 Intel Hex Object Format 10-6 10.4 TI–Tagged Object Format 10-7 10.5 Motorola S Format 10-8 10-1 Object Format Converter Description MSP430 Family 10-2 MSP430 Family Object Format Converter Description 10 Object Format Converter Description Most EPROM programmers do not accept COFF object files as input. The object format converter converts a COFF object file into one of four object formats that most EPROM programmers accept as input: Extended Tektronix hex object format supports 32–bit addresses. Intel hex object format supports 16–bit addresses. Motorola S format supports 16–bit addresses. TI–tagged object format supports 16–bit addresses. 10-3 Object Format Converter Description MSP430 Family 10.1 Object Format Converter Development Flow The figure illustrates the object format converter's role in the assembly language development process. Macro Assembler Source Files Source Archiver Assembler Macro Library COFF Object Files Linker Archiver Library of Executable Object Files COFF Objekt Files Object Format Converter EPROM Absolute Software Evaluation In-Circuit MSP430 Programmer Lister Emulator Module Emulator Figure 10.1: Object Format Converter Development Flow 10-4 MSP430 Family Object Format Converter Description 10.2 Extended Tektronix Hex Object Format The Extended Tektronix hex object format supports 32–bit addresses and has three types of records: data, symbol, and termination records.
    [Show full text]
  • UNDERSTANDING STACK ALIGNMENT in 64-BIT CALLING CONVENTIONS for X86-64 Assembly Programmers
    UNDERSTANDING STACK ALIGNMENT IN 64-BIT CALLING CONVENTIONS For x86-64 Assembly Programmers This article is part of CPU2.0 presentation Soffian Abdul Rasad Date : Oct 2nd, 2017 Updated: 2019 Note: This article is released in conjunction with CPU2.0 to enable users to use CPU2.0 correctly in regards to stack alignment. It does not present full stack programming materials. MS 64-bit Application Binary Interface (ABI) defines an x86_64 software calling convention known as the fastcall. System V also introduces similar software calling convention known as AMD64 calling convention. These calling conventions specify the standards and the requirements of the 64-bit APIs to enable codes to access and use them in a standardized and uniform fashion. This is the standard convention being employed by Win64 APIs and Linux64 respectively. While the two are radically different, they share similar stack alignment policy – the stack must be well-aligned to 16-byte boundaries prior to calling a 64-bit API. A memory address is said to be aligned to 16 if it is evenly divisible by 16, or if the last digit is 0, in hexadecimal notation. Please note that to simplify discussions, we ignore the requirement for shadow space or red zone when calling the 64-bit APIs for now. But still with or without the shadow space, the discussion below applies. Also note that the CPU honors no calling convention. Align 16 Ecosystem This requirement specifies that for the 64-bit APIs to function correctly it must work in an ecosystem or runtime environment in which the stack memory is always aligned to 16-byte boundaries.
    [Show full text]
  • Sqtp File Format Specification
    SQTP FILE FORMAT SPECIFICATION SQTPSM File Format Specification INTRODUCTION This document shows how a Serial Quick Turn Programming (SQTPSM) file is produced and used by MPLAB® IPE Integrated Programming Environment. Engineers can use this information to generate their own SQTP file. • Overview • Example SQTP File • Intel HEX File Format • MPLAB IPE SQTP File Generation • Customer Generated SQTP Files • Programming of Devices • Understanding Usage of RETLW in SQTP File for Midrange and Baseline Devices • Examples of SQTP Files for Various Memory Regions • Differences in SQTP File Behavior Between MPLAB IPE v2.35 (and Before) and MPLAB IPE v2.40 (and Later) • Differences in the SQTP Feature Between MPLAB IDE v8.xx and MPLAB IPE for the Flash Data Memory Region OVERVIEW Serialization is a method of programming microcontrollers whereby each chip is pro- grammed with a slightly different code. Typically, all locations are programmed with the same basic code, except for a few contiguous bytes. Those bytes are programmed with a different number (referred to as “key” or “ID number” or “serial number”) in a program region. Typical applications for such programming are where each unit must have a different access code, as in the Internet of Things (IoT), car alarms or garage door openers. An SQTP file (.num) contains the serial numbers to be used as each device is programmed. Microchip devices require that the serial number must reside in contiguous locations, with up to 256 locations. The minimum number of bytes in a line of SQTP should be the Word size of the memory. It can be a multiple of the Word size, up to 256 bytes.
    [Show full text]
  • Bringing Virtualization to the X86 Architecture with the Original Vmware Workstation
    12 Bringing Virtualization to the x86 Architecture with the Original VMware Workstation EDOUARD BUGNION, Stanford University SCOTT DEVINE, VMware Inc. MENDEL ROSENBLUM, Stanford University JEREMY SUGERMAN, Talaria Technologies, Inc. EDWARD Y. WANG, Cumulus Networks, Inc. This article describes the historical context, technical challenges, and main implementation techniques used by VMware Workstation to bring virtualization to the x86 architecture in 1999. Although virtual machine monitors (VMMs) had been around for decades, they were traditionally designed as part of monolithic, single-vendor architectures with explicit support for virtualization. In contrast, the x86 architecture lacked virtualization support, and the industry around it had disaggregated into an ecosystem, with different ven- dors controlling the computers, CPUs, peripherals, operating systems, and applications, none of them asking for virtualization. We chose to build our solution independently of these vendors. As a result, VMware Workstation had to deal with new challenges associated with (i) the lack of virtual- ization support in the x86 architecture, (ii) the daunting complexity of the architecture itself, (iii) the need to support a broad combination of peripherals, and (iv) the need to offer a simple user experience within existing environments. These new challenges led us to a novel combination of well-known virtualization techniques, techniques from other domains, and new techniques. VMware Workstation combined a hosted architecture with a VMM. The hosted architecture enabled a simple user experience and offered broad hardware compatibility. Rather than exposing I/O diversity to the virtual machines, VMware Workstation also relied on software emulation of I/O devices. The VMM combined a trap-and-emulate direct execution engine with a system-level dynamic binary translator to ef- ficiently virtualize the x86 architecture and support most commodity operating systems.
    [Show full text]
  • IAR Embedded Workbench® for ARM
    IAR Embedded Workbench® for ARM IAR Embedded Workbench is a set of highly sophisticated • Binary compatibility with other EABI compliant tools and easy-to-use development tools for embedded applica- • Automatic checking of MISRA C rules (MISRA C:2004) tions. It integrates the IAR C/C++ Compiler™, assembler, • Language extensions for embedded applications with linker, librarian, text editor, project manager, and C-SPY® target-speciic support Debugger in an integrated development environment • Advanced inline assembler • Support for ARM, Thumb1 and Thumb-2 processor modes (IDE). With its built-in chip-specific code optimizer, IAR • Support for the VFP9-S loating-point co-processor Embedded Workbench generates very efficient and reliable • Support for 4 Gbyte applications in all processor modes code for ARM devices. In addition to this solid technology, • Support for 64-bit long long IAR Systems also provides professional worldwide technical • 32- and 64-bit loating-point types in standard IEEE format support. • Reentrant code • Position Independent Code and Data (PIC/PID) MODULAR AND EXTENSIBLE IDE • Multiple levels of optimizations on code size and execution • A seamlessly integrated environment for building and speed allowing different transformations enabled, such as debugging embedded applications function inlining, loop unrolling etc. • Powerful project management allowing multiple projects in one workspace STATE-OF-THE-ART C-SPY® DEBUGGER • Build integration with IAR visualSTATE • Complex code and data breakpoints • Hierarchical project
    [Show full text]