NEWS Communication: The Key to Success. Panel Discussions. Expert Seminars CONTENTS. Committed to Standards

Transcription

1 NEWS 2010 DEBUGGER, REAL-TIME TRACE, LOGIC ANALYZER Stephan Lauterbach during a panel discussion at the IP/ESC in Grenoble, France Communication: The Key to Success Our success is due to building long term, solid relationships with our customers and partners. By keeping up-to-date with new technologies from our partners, and being proactive to the requirements of our customers, we are able to provide the right development tools at the right time. Successful communication requires active involvement, which will continue to be our philosophy in Expert Seminars To help expand our customers level of product use and understanding, we hosted our first, industry specific, TRACE32 expert forum, October 2009, at our new headquarters in Germany. The essential outline of this forum was to exchange information between the system users and our TRACE32 developers. Positive feedback has impelled us to plan more like events during Committed to Standards In addition to the ongoing dialogue with our embedded industry partners, our participation in standards committees represents a critical means of exchanging information and fostering contacts. Over the years, we have incorporated many of the results from these committees into our products. In this newsletter, we d like to provide you with more details regarding our involvement in this area. Panel Discussions Trade show panel discussions provide further opportunities to discuss current and future market requirements with customers and partners. In November 2009, for example, Stephan Lauterbach took part in a discussion at the IP/ESC in Grenoble, France. The discussion, initiated by ARM, focused on the future of debugging and trace technology. We are looking forward to talking with you at the upcoming ESC Silicon Valley in San Jose (booth# 1910). CONTENTS New TRACE32 Installer for Windows 7 2 Programming Serial Flash Devices 2 Intel Atom TM Debugger / Differential Loading 3 New Supported Processors 4 Debugging AMP and SMP Systems 5 The Latest on RTOS Debugging 7 Standardization Activities 8 Serial Trace for QorIQ 10 Support for cjtag 10 Tip More Read and Write Breakpoints 12

2 New TRACE32 Installer for Windows 7 The TRACE32 installer has been enhanced to simplify the installation of TRACE32 USB drivers on systems running Windows 7. This was necessary because Windows 7 only installs drivers automatically using the Windows Update Server or a pre-installed driver package. If you do not have a new DVD available, you can download the new TRACE32 USB driver installer for Windows XP/Vista/7 (32-bit and 64-bit) under the following link: With the new TRACE32 DVD from December 2009 (Build 20817/Release), Lauterbach provides official support for Windows 7. The handling as well as the look and feel of TRACE32 remains the same on systems running Windows 7. To provide even better support for the Windows security model and to make automatic installation easier, from December 2009, the executable TRACE32 files on the DVD are also signed. A signature has been used on the USB driver since Programming Serial Flash Devices TRACE32 support for serial flash devices includes programming as well as reading and displaying contents. The flash contents are displayed in a conventional hex dump, which enables you to check the program data quickly (see Figure 2). Fig. 1: Serial flash with SPI interface Embedded systems are increasingly being designed with serial flash memory devices. Lauterbach recognized this trend early and since mid- 2009, TRACE32 debuggers have supported the programming of serial flash devices. We will be increasing this support significantly during To find out if TRACE32 supports your serial flash, please check the following lists: Supported NAND/SERIAL FLASH Controllers Supported NOR/NAND/SERIAL FLASH Devices Low pin count, compact format, and reduced energy consumption make serial flash devices a cost-effective alternative to NOR/NAND flash devices. The concept behind serial flash design is simple: An interface controller is connected upstream of the NOR/NAND flash device, enabling you to program and read out the component over an SPI bus or MMC bus (see Figure 1). Fig. 2: A visual representation of serial flash content 2 NEWS 2010

3 Debuggers for Intel Atom Microarchitecture Since October 2009, Lauterbach has been offering development tools for Intel Atom. Linux debugging is already fully supported, and Windows CE support is planned for early Supported Derivatives Intel LA-3776 (Atom) D410 D510 N270 N280 N450 Z5XX Other derivatives are planned. Differential Loading Atom MIPS32 MIPS64 1 sec 2 sec 0,9 sec 4 sec 11 sec normal 20 sec differential Fig. 3: Differential loading makes it significantly faster to load a 4-MByte file. A typical debug cycle consists of the following steps: debug the program locate errors correct errors compile the program reload the program. Your tool chain has to be able to perform each individual step quickly and without any delays. Long waiting times will occur when downloading a large program to the target RAM via a slow JTAG interface. Differential loading can provide a remedy for this problem. If the newly compiled program differs only slightly from the previously loaded program, the loading times can be cut significantly. The basic concept behind differential loading is that the debugger holds a copy of the program that is already loaded. When loading the newly compiled version a differential file is created. The differential file contains all of the information, in compressed form, that is required to update the original file to the newly compiled version. The debugger then downloads only the differential file to the target system. Because the differential file is usually thirty to one hundred times smaller than the complete newly compiled program, the download is much faster. A load agent on the target system then decompresses the differential file and makes sure that the new compilation is stored in the target memory. The measurements in Figure 3 were performed for a test file in which one percent of the program had changed. 1. Atom architecture CPU: Z530P from Intel Processor frequency: 1.6 GHz JTAG frequency: 20 MHz Normal download: 204 KByte/s 2. MIPS32 architecture CPU: BCM7325 from Broadcom Processor frequency: 167 MHz JTAG frequency: 20 MHz Normal download in Turbo Mode: 370 KByte/s 3. MIPS64 architecture CPU: OCTEON Plus CN58XX from Cavium Processor frequency: 950 MHz JTAG frequency: 50 MHz Normal download in Turbo Mode: 1 MByte/s 3

4 New Supported Processors New Derivatives ARC LA-3750 (ARC) ARC 601 / ARC 630 ARM LA-7843 (Cortex-A / R) Cortex-A5 / Cortex-A5MPCore Cortex-A9 / Cortex-A9MPCore LA-7844 (Cortex-M) Cortex-M0 / Cortex-M1 ATMEL Broadcom CEVA Cavium Cortus Energy Micro Freescale Infineon LA-3779 (AVR32) AVR32 (Q2 / 2010) LA-7844 (Cortex-M) AT91SAM3U LA-7760 (MIPS32) BCM3380 BCM56xxx / 5836 BCM6362 / 6368 / 6550 BCM7401 / 7402 / 7403 LA-3711 (CEVA-X) CEVA-X1641 CEVA-XC (Q2 / 2010) LA-3774 (TeakLite-III) TeakLite-III LA-7761 (MIPS64) Octeon CN54xx / CN56xx Octeon CN63xx LA-7765 (ARM11) ECONA CNS3XXX LA-3778 (APS) APS-IP (Q2/2010) LA-7844 (Cortex-M) EFM32 LA-7736 (MCS12X) MC9S12G LA-7742 (ARM9) i.mx23 / i.mx25 LA-7732 (ColdFire) V1 ColdFire Core LA-7753 (MPC55xx) / LA-7630 (NEXUS MPC55xx) MPC5643L LA-7764 (PowerQUICC III) QorIQ P1013 / P1022 / P4080 LA-7756 (TriCore) TC1167 / TC1197 / TC1337 TC1367 / TC1387 / TC1387ED TC1782 / TC1782ED Infineon (Cont.) LSI Marvell MIPS NEC NXP ST Microelectronics Tensilica Texas Instruments LA-7759 (XC2000/ C166S V2) XC2000ED XC2200 / XC2300 / XC2700 XE166 / XGOLD110 LA-7834 (StarCore) StarPro25xx / 26xx LA-7742 (ARM9) 88AP128 / 162 / 166 / 168 MV76100 / / LA-7765 (ARM11) 88SV581X-V6 LA-7843 (Cortex-A/ R) 88SV581X-V7 LA-7762 (XScale) PXA93x / PXA950 LA-7760 (MIPS32) MIPS K / 1004KF MIPS K CPS MIPS32 M14K / M14Kc LA-3777 (78K0R) 78K0R / Fx3, 78K0R / Kx3 LA-7835 (V850) V850E2 / Px4 70F3502 / 70F3504 / 70F3506 LA-7844 (Cortex-M) LPC13xx LA-7742 (ARM9) LPC29xx LA-7753 (MPC55xx)/ LA-7630 (NEXUS MPC55xx) SPC56EL60 LA-7844 (Cortex-M) STM32F105 / STM32F107 LA-3760 (Xtensa) Xtensa 8 LA-7847 (TMS320C28X) TMS320F28232 TMS320F28234 / F28235 LA-7838 (TMS320C6400) TMS320TC6424 TMS320TCI6482 / I6488 LA-7843 (Cortex-A/ R) / LA-7838 (TMS320C6400) AM3505 / AM3517 (Sitara) OMAP4430 / OMAP4440 LA-7742 (ARM9)/ LA-7841 (TMS320C6700) OMAP-L137 / OMAP-L138 4 NEWS 2010

5 Debugging AMP and SMP Systems Many multi-core processors can be used as either AMP or SMP systems. Depending on the mode of operation, different debug and trace concepts are applicable. In the following article, we describe how these concepts can be applied using TRACE32 to debug an ARM Cortex-A9 MPCore. Debug Concepts In discussion with our customers, we realize again and again that there are many varying interpretations of the two terms: AMP asymmetrical multiprocessing SMP symmetrical multiprocessing Therefore we think it is worth taking the time to explain how these terms are used at Lauterbach and what effect they have on the configuration and usage of a TRACE32 debugger. As the term multiprocessing implies, multiple cores are working together in an embedded system. What is crucial for debugging is how the system tasks are distributed to the individual cores. Debug Concept for AMP Systems controller (usually RISC architecture) specialized accelerators (DSPs or customized cores) are frequently chosen. When debugging AMP systems, an individual TRACE32 instance is started for each core (see Figure 4). There are two reasons for this: 1. An AMP system can contain different core architectures. 2. Each core processes a separate part of the application. This means that the majority of the symbol and debug information is assigned exclusively to the corresponding core. However, because the cores do not work independently, but perform the application task together and in parallel, it must be possible to start and stop all cores simultaneously. This is the only way to test the interaction between the cores and to monitor and control the entire application. There are different ways to start and stop all cores simultaneously. Ideally, the multi-core processor will support this through internal synchronization logic. If this logic is missing, TRACE32 takes over the synchronization process. A special algorithm calculates JTAG command sequences to control all cores as promptly as possible. In AMP systems, each core is assigned a specific task. How the tasks are distributed is determined in the design phase of the system. In addition to a standard Fig. 4: When debugging AMP systems, an individual TRACE32 instance is started for each core. Fig. 5: When debugging SMP systems, a single TRACE32 instance is started for all cores. 5

6 Debug Concept for SMP Systems In contrast to AMP systems, where the tasks assigned to each core are predefined, the assignment in SMP systems is flexible. In an SMP system, the system designer no longer assigns tasks to cores. An SMP operating system does this instead. All cores must be the same type to enable tasks to be assigned freely to each core as required. Task assignment is performed dynamically, meaning that the assignment depends on the current system status. A task unit that can be assigned by an operating system is called a task or thread. In simple terms, a task that needs to be processed is assigned to a core that is currently free. For debugging SMP systems, only one TRACE32 instance is opened and all cores are controlled from this one point (see Figure 5 on the previous page). Because the developer is primarily concerned with debugging a single task, the TRACE32 user interface displays the state of the entire SMP system from the perspective of this single task or from the perspective of the core where the task is running. Of course the visualization can be switched to other tasks or cores if required. TRACE32 assumes a function that is similar to an SMP operating system. It organizes the debugging of all cores so that developers do not need to look into the details of the SMP system. For example, if a breakpoint that hits the breakpoint. If the program is restarted, all cores start running together. Debugging SMP systems with TRACE32 is easy. After a TRACE32 instance is started and configured for the SMP system, the developer essentially use it as if he were debugging only one core. Trace Concepts TRACE32 analyzes and displays trace information in different ways, depending on whether the trace data was generated by an AMP system or an SMP system. For AMP systems, trace analysis is largely performed on each core independently. The trace information for an SMP system, however, can be analyzed for a single task, a single core, or for the entire system, depending on the type of query. Trace Concept for AMP Systems Because debugging individual cores of an AMP system is performed over separate TRACE32 instances, trace information is also displayed on these individual user interfaces. AMP systems can consist of different types of cores, so different trace protocols might be used. As the individual trace streams are displayed in the separate user interfaces, they can be individually decoded and analyzed. is set, TRACE32 makes sure that the breakpoint is entered in all cores. This is necessary because at the time when the breakpoint is set, it s not yet clear which core will execute the program section with the breakpoint. If a core stops at a breakpoint, all other cores are also stopped automatically. The display in TRACE32 switches to the task or core Fig. 6: When tracing AMP systems, the trace information for each core is displayed on a separate user interface. Time synchronization of the user interfaces is possible. To test the interaction of the cores and to quickly locate complex system errors, it is possible to display the individual trace views and also their relationship to each other over time. To do this, TRACE32 PowerTrace provides a common time base. This allows the developer to select a point in time in the trace view on one user interface and see exactly 6 NEWS 2010

7 Fig. 8: The trace analysis shows which cores processed the individual program sections. Fig. 9: The trace analysis analyses the SMP system as a whole; which core processed which program section is unimportant. Fig. 7: When tracing SMP systems, the information for all cores is stored in a shared trace memory. which command was being executed by another core at approximately the same time (see Figure 6). Trace Concept for SMP Systems All information about the programs processed on an SMP system is stored in a shared trace memory for all cores (see Figure 7). One of the advantages of TRACE32 is that it provides different views of this information. To locate errors in a task or for task-specific runtime measurements, trace information can be displayed specifically for an individual task. If you want to know information such as Which cores processed my task? or What is the run-time load of my cores?, it can be useful to view the trace information for all cores at the same time. Figure 8 shows an example of this view. The core number (0 or 1) indicates the cores on which the individual program sections ran. In order to examine the SMP system as a whole, it is not necessarily to know which core processed which task or program section. TRACE32 also provides display options for this type of view of the SMP system (see Figure 9). During 2010, Lauterbach will continue to enhance the preparation and display of trace information from SMP systems. This will include new analysis functions based upon feedback from existing users and also new concepts currently in development. The Latest on RTOS Debugging New Supported RTOS FAMOS for ARM available Linux for Atom available SMP Linux for MIPS64 available OKL4 for ARM available OS21 for ARM available SMP Symbian OS for ARM available Windows CE for Atom Q1/2010 Updating for new RTOS versions LynxOS 5.0 for PowerPC MQX 3.x for ColdFire OSE 5.4 QNX 6.4 VxWorks 6.4 µc/os-iii Enhancements Partitions and MPU/MMU support for mc/os-ii Paged breakpoints for Symbian OS RTP support for VxWorks 7

8 Standards Committees AUTomotive Open System ARchitecture Many customers would like to see a higher level of standardization for debug and trace technologies. In order to take an active role in the development of suitable standards, Lauterbach has been participating in a number of international committees over many years. Our active participation makes it possible for us to include full support within TRACE32 for all new standards as soon as they are approved. ORTI Standard One of the first standards that Lauterbach actively helped to develop was the ORTI standard. This standard deals with a descriptive language that describes the structure and memory mapping of OSEK operating system objects for RTOS-aware debugging and stores it in a file. This standard was developed within the AUTOSAR consortium and has been applied since 2003 by all providers of OSEK operating systems, including ETAS Group and Vector. Working with an ORTI file can be described as follows: The OSEK System Builder creates the ORTI file from the user configuration of an OSEK operating system. Working group OSEK/VDX Debug Interface Working Group Standard OSEK Run Time Interface Version 2.2, Nov The ORTI file is then loaded in the TRACE32 debugger in order to provide OSEK-aware debugging (see Figure 10). TRACE32 can then offer the developer the following functions (presuming the OSEK System Builder has saved the required information in the ORTI file): Intuitive display of OSEK resources (Figure 11 shows the alarm list as an example) Task-specific breakpoints A task stack analysis A task context view Analysis of task runtimes (see Figure 13) Analysis of service runtimes Fig. 11: The alarm list of an OSEK operating system in TRACE32 NEXUS Standard Back in 1998, at the NEXUS 5001 Forum, a first step was taken toward standardizing a debug interface and a trace interface for embedded processors. The NEXUS standard was then approved in This includes: Fig. 10: The OSEK System Builder creates an ORTI file that enables OSEKaware debugging after the file is loaded in TRACE32. A JTAG interface, usually IEEE Mechanisms that enable a debugger to read and write to memory, while the program execution is running A message-based trace protocol (program flow as well as data trace) Debugging and tracing for multi-core processors A hardware layer Standard NEXUS connectors 8 NEWS 2010

9 Fig. 12: NEXUS messages for recording task switching Fig. 13: Analysis of task runtimes for an OSEK operating system Fig. 14: TRACE32 High-Speed Serial Trace for QorIQ Lauterbach has supported the NEXUS standard for various processor architectures since The latest and most important one is the MPC55xx/ MPC56xx family from Freescale and ST Microelectronics, which is widely used in the automotive industry. Figures 12 and 13 show how the NEXUS trace log is used to measure the runtimes of OSEK tasks. Because the NEXUS standard gives a high degree of freedom in the implementation, Lauterbach completely redesigned its NEXUS hardware in The new FPGA-based hardware is designed to be so flexible, that it can be adapted to all NEXUS implementations. New features include support for an optimized sampling point for trace signals as well as the new JTAG protocol IEEE More information about IEEE can be found on page 10. The 2003 NEXUS standard is currently being revised. Although the new version of the standard has not yet been approved, some processors from the MPC56xx family already implement this new standard. The new protocol is supported by TRACE32 by means of a software update available now. Nexus Standard Standard for a Global Embedded Processor Debug Interface Version 2, December Serial Trace for QorIQ Lauterbach will present its new QorIQ High-Speed Serial Trace (see Figure 14) at the ESC Silicon Valley April The trace technology of QorIQ P4xxx is based on a NEXUS protocol, an AURORAbased hardware layer, and a connector approved by a working group of the Power.org organization. The first processor to be supported will be the QorIQ P4080 from Freescale. The P4080 SoC features eight Power Architecture e500mc cores that can run in SMP or AMP configurations. Configurations that combine SMP and AMP groups are also possible. Detailed information about Debugging AMP and SMP Systems can be found on page 5 of this newsletter. Compared to parallel trace interfaces, serial trace interfaces have the following advantages: pin reduction through serial transfer and high data throughput using differential signals to transfer the data. The large volume of produced trace data naturally requires a correspondingly large trace memory buffer size. This is provided by the Lauterbach product PowerTrace II, which has a memory of up to 4 GByte. High-Speed Serial Trace for the QorIQ is designed for a maximum of four high-speed channels. The following transfer rates are supported: 6.25 GBit/s max. per channel for up to 3 channels GBit/s max. per channel for up to 4 channels Trace data is captured over a connector system supplied by Samtec. Lauterbach supplies adapters for different variants of the connector. 9

10 Power.org IEEE Standards Association Working group Common Debug Interface Technical Subcommittee Standard Power.org Standard for Physical Connection for High-Speed Serial Trace, July Power_CDI_Physical_Connection_for_HSST_ APPROVED_v1.0.pdf IEEE Also known as cjtag (compact JTAG), IEEE updates the familiar JTAG standard IEEE to meet the latest technical requirements. As the leading manufacturer of debuggers, Lauterbach has been heavily involved in the definition of this new 2-pin interface. According to IEEE , the entire communication between debugger and core can occur over the TCK and TMS pins. Compared to the standard debug communication, the new features can be described as follows: IEEE has only a two-pin connector on the outside. On the chip, the controller converts the communication back to standard JTAG (see Figure 15). Working group: Standard Official approval of the standard is planned for Q1/2010 Simply stated, the IEEE is serialized compared to the standard JTAG interface (see Figure 16). Because the TMS signal is a unidirectional signal in standard JTAG, Lauterbach had to adapt its debug cables to support bidirectional TMS: All debug cables for ARM/Cortex architectures were converted at the beginning of 2008 (Debug Cable V4). An updated version of the debug cable for the MPC55xx/MPC56xx architecture has been available since September 2009 (OnCE Debug Cable with serial JTAG). The new debug cables will of course continue to support the conventional standard. TRACE32 was successfully tested with cjtag in October However, it can only be released after the standard has been officially approved. Fig. 16: Simplified diagram of the protocol Fig. 15: The IEEE protocol is converted back to the standard JTAG protocol on the chip. 10 NEWS 2010

11 Open SoC Design Platform for Reuse and Integration of IPs Working group: Debug and Analysis Standard: Multi-Core Debug API v1.0, April MCD API The MCD API defines a C interface for debugging multi-core systems. It makes no difference whether the multi-core system consists of real hardware or a software simulation. Lauterbach currently sees two applications for the MCD API: 1. MCD API as the standard interface for TRACE32, as the new TRACE32 MCD Remote API 2. MCD API as the standard interface for virtual prototypes 1. Updated TRACE32 Remote API The Lauterbach Remote API allows an external application to control TRACE32. It enables for example the automation of regression tests. Over the years, our remote API has been subject to ongoing development driven by the many new requests from our customers. Currently, the increasing number of multi-core systems would have required many further comprehensive modifications. Instead of revising the current remote API, Lauterbach has decided to rebuild its remote API based on the MCD standard. It is highly probable that the MCD API does not cover all TRACE32 requirements, which means that functions specific to TRACE32 will be included (see Figure 17). Fig. 18: Debugging a virtual prototype takes place over the MCD-API. The release of the first version of the new TRACE32 MCD Remote API is scheduled for mid At this point in time, all development on the current Legacy Remote API has been put on ice. For our customers, this means that although we will continue to support the Legacy Remote API, we will not be implementing any new functionality. 2. Standard Interface for Virtual Prototypes For the past five years, TRACE32 has been capable of debugging virtual prototypes. Manufacturers of virtual prototypes typically provide their own debugging APIs for this purpose. The MCD API provides a standardized interface between debugger and virtual prototype (see Figure 18). This has the following advantages: Fast adaptation to new virtual prototypes Larger range of well-tested functions with higher performance Fig. 17: TRACE32 can be controlled by an external application over its Remote API. 11

12 Tip More Read and Write Breakpoints On-chip breakpoints are highly valuable debug resources that, on most processors, are only available in very limited numbers. For a long time it has been possible to set up two additional read/ write breakpoints on an ARM core, provided the core included an Embedded Trace Macrocell (ETM). Using these breakpoints, there are extra options to define the break conditions with great accuracy. Unfortunately, not many developers are aware of this useful option. Additional Read/Write Breakpoints ARM7/9/10/11 Cortex-A5/-A8/-R4 Ceva-X/TeakLite TMS320C extra read/write breakpoints with data values 2 extra read/write breakpoints with data values Up to 4 extra read/write breakpoints with data values Table 1: List of architectures for which additional breakpoints can be provided over the trace logic. For efficient debugging, it is often important to be able to halt the program when a given data value is written to a variable. It is a disadvantage that not all ARM or Cortex cores provide the required read/write breakpoints. For example, the breakpoints in the Processor Debug Logic for the Cortex-A8 do not support this capability. However, if the Cortex-A8 has an ETM logic, TRACE32 can provide this functionality by using two of the address and data comparators provided in the ETM. BRANCHES AROUND THE WORLD Germany France UK Italy USA China Japan Represented by experienced partners in all other countries These comparators are then no longer available for their original function of filtering trace information and generating triggers. However, this is normally not critical because this functionality remains largely unused during debugging. By setting the option ETM.ReadWriteBreak, the resource management of TRACE32 is reconfigured so that two address/data comparators of the ETM can be used as standard read/write breakpoints. These breakpoints provide superior functionality when compared to the standard breakpoints provided in the Processor Debug Logic of the Cortex-A8. As an example, the read/write breakpoints of the Processor Debug Logic only offer bit masks for marking address areas, with the ETM breakpoints the address areas can be defined exactly. Because of this, TRACE32 gives priority to using ETM-based breakpoints. Table 2 compares the functionality of both breakpoint types. Processor Debug Logic of Cortex-A8 1 to 16 read/write breakpoints Address area as bit mask No data values ETM-based Breakpoints of Cortex-A8 2 read/write breakpoints Exact address area Both breakpoints with exact data values Table 2: The additional ETM-based breakpoints offer enhanced functionality. Note that ETM breakpoints can also be used even if the debugger in use is only the TRACE32 JTAG debugger. This is because the ETM comparators can be configured over the standard JTAG interface. Similarly, as described for the Cortex-A8, trace logic features can be used in other architectures to provide additional breakpoints with enhanced functionality (see table 1). KEEP US INFORMED If your address has changed or if you no longer want to be on our mailing list, please send us an to info_us@lauterbach.com 12