Demonstrating Software Debug and Calibration Tools Utilizing the Nexus 5001 Standard
Nexus 5001 is an IEEE-ISTO industry standard for a global embedded processor debug interface. It was originally designed to support the debug and calibration needs of the automotive industry. Since its original 1999 publishing date, the industry standard has been enhanced and improved to address the instrumentation needs of diverse systems in telecom, networking and related domains and features.
Nexus 5001 provides a vendor independent protocol, infrastructure, and interface standard that is scalable to address a wide variety of digital measurement, calibration, and analysis features and capabilities. It retains compatibility with other industry standards while supporting high bandwidth interfaces needed for extensive trace and analysis of complex systems with real time reporting. Nexus 5001 applications are supported by leading tool vendors in the traditional automotive space and the ever growing embedded space.
This 90 minute webinar replay includes the following:
- Live Nexus 5001 tool demonstrations featuring SW debugging, SW trace, high speed measurement, real time calibration, SW function bypass, and multi tool use
- Use Case for the demonstrated tools
- Overview of current IC’s supporting the Nexus 5001 standard
- Q & A Session
Effective tools and capabilities for debug, calibration and performance analysis are widely recognized as key elements in ensuring quality products. This webinar is recommended for hardware and software developers and managers everywhere who are involved in embedded systems design and product release.
Norm D’Amico, GM – Norm D’Amico is a Staff Engineer at General Motors working as a Team Leader in Global Powertrain ECU Development Tools for the past 5 years. Norm works with the Tier-1 ECU suppliers and the Tier-2 tool suppliers to insure that GM’s requirements are implemented properly on development ECUs. Norm has also worked in tool development and software integration roles while at GM. Prior to GM, Norm held several positions at ERIM (since acquired by General Dynamics) in the development of electronic hardware and software for synthetic aperture radar (SAR) systems. Norm received his B.S. in Electrical Engineering from Wayne State University in 1986, and has been involved in embedded electronic systems his entire career.
Randy Dees, Freescale – Randy Dees is a Senior Member of the Technical Staff at Freescale Semiconductor, working in the 32-bit Automotive Microcontroller Applications group supporting highly integrated advanced MCUs with embedded Flash memory. He graduated from the University of Houston in December 1980 and began his working at Motorola Semiconductor in January 1981. Motorola later spun the semiconductor group off as Freescale. He has worked in both Product Engineering and Application supporting 8- to 32-bit microprocessors, integrated circuits for telecommunications, and 32-bit microcontrollers.
He has been working with Nexus-based MCUs since 1999 and has been either the co-chairman or the chairman of the IEEE-ISTO 5001 Nexus Consortium’s technical subcommittee since 2000.
Steve Rosenthal, ETAS – Steve Rosenthal is a senior software engineer at ETAS, where he has been involved in vehicle diagnostic solutions, MC tool (INCA) development and integration, and Rapid Prototyping software (EHOOKS). Prior to joining ETAS, Steve worked at Hewlett-Packard for a number of years as a software engineer and consultant.
Steve received his BS degree in Mathematics/Computer Science from Lawrence Technological University, Southfield, MI in 1987.
Udo Zoettler, Lauterbach – Udo has been a Sales/Marketing Manager for the last 17 years. Udo’s work is focused on sales and customer acquisition as well as providing training classes to end customers for Lauterbach debugger products used in automotive and embedded systems software development. Prior to Lauterbach, Inc., Udo held a sales/marketing manager position at Krohn & Stiller.
Udo received his MSE from the Technical University Ilmenau, Germany, in 1989.
Jane Celusak, IEEE – Jane Celusak is a program manager supporting industry consortia on behalf of IEEE-ISTO including Nexus 5001 Forum. Jane works closely with the industry consortia leadership to develop new initiatives to support the strategic directions of organizations and acts as a liaison between programs and other IEEE Standards Association support functions.
Jane has over 15 years’ experience in business and organizational development and external, customer and foundation relationship management. Prior to joining IEEE, Jane was the Director of External and Foundation Relations at a national non-profit health care provider. Additionally, she has held various board positions including Vice President of Organizational Development for a state level professional association. She has a MA in Public Policy and International Affairs.
Q & A
Is the code coverage analysis available with older Nexus versions too or only the Nexus Aurora?
Code coverage is based on the debugger reconstruction from the Nexus messages. It is independent of the transport mechanism. The same trace information is available via the serial Nexus Aurora Trace information or the Nexus parallel trace ports. The Nexus Aurora just packs the parallel data into a serial stream.
What’s the advantage of Nexus if I don’t have access to source code?
Nexus can still do some reconstruction of trace information, however, it will not include the types of information normally available from the source code such as the symbol names or other labels. This information is available in the ELF file, if the elf file is available. If the source code or elf file is not available, then most debuggers will reconstruct the code (based on the assembly
instructions that it can read for the MCU memory space). This still allows reconstruction, but is much harder to read and interpret.
I believe the standard does not have the source address mandatory for data trace msgs DTM). That is who is writing on an address. Does/Will Freescale support this?
Normally, a data trace sync message does include the address of the data access. Subsequent messages then use a calculated address based on the last message. Sync messages are sent every 255 data trace messages. In systems with multiple masters that can trace through a single Nexus client, there is the optional MAP/MASTER field that can be used to indicate which bus maters generated the access.
What happens if the Nexus interface is not fast enough to transfer all data off-chip? Is the system halted or is the data lost?
The standard has two mechanisms to address this. Defined in the standard is an option that allows the Nexus client to stall a processor if the on-chip trace buffers are in danger of overflowing the internal buffers. This is an optional feature that may not be supported by all devices. Of course the size of the on-chip buffers may need to be sized appropriately depending on the client generating the messages to insure that nothing is lost in normal operations. In some types of applications, however, the stall feature cannot be used since it would impact the performance of the system and its real-time capabilities. An example is that if an MCU is completely controlling an automotive engine, stopping that MCU may have detrimental impact on the system (hardware has momentum and does stop, just because the control has stopped). In cases where a stall mechanism is not feasible, there are methods to deal with an overflow condition. On Freescale processors if an over-run of the internal buffers reach a predetermined level. Once there is room in the buffers , an error message is put into the message stream with information on the types of messages that were discarded (this is defined in the standard). After the error message, a program trace sync message is generated based on the CPUs current instruction address (or data trace address, if data trace is enabled. Tools can then re-synchronize to the new messages.