Title

Product Design Considerations when Debugging with IEEE ISTO-5001Nexus

Abstract
When using a debugger in a real-time application on a target microprocessor equipped with IEEE ISTO-5001Nexus, a properly designed interface between the microprocessor and the debugger tool can result in a development system that has the capability approaching that of a logic state analyzer. Designers of Automotive Electronic Control Units (ECUs) have been using single chip microcontrollers in their designs for many years, but debug them in a special development system that is configured to run the microcontroller in an expanded mode. As microcontrollers become bigger and faster, a reliable method must be found to debug the software in these complicated devices while they are still in their single chip configuration. Creating a reliable debug environment involves more than just the selection of a suitable debugger tool. The designer of the target must also provide reliable, high frequency connections for the debug signals, and provisions for the debugger to interact not only the microcontroller, but also with the target power supply, Computer Operating Properly (COP) and Reset circuits.

Introduction to Nexus
In 1998, a study was initiated to look for new high-end microcontrollers that could provide more software throughput capability for our major Powertrain customers. Our goal was to find a single chip microcontroller with an enhanced debug interface so that software algorithms could be developed, debugged and calibrated while the microcontroller was still in a single chip, production configuration mode. A variety of technical challenges with the debug interface and the associated tools had to be overcome to achieve this goal. It was decided to solve these issues in an open, industry standards forum. The initial forum was created by several silicon and tool vendors, which then became known as the IEEE ISTO-5001Nexus Forum. In order to increase software throughput in these high-end microprocessors, clock rates were increased, internal bus structures widened, multi-bus architectures were used, and all memories had to be placed on-chip where they could be accessed at greater speeds (see below Figure 2). At the same time, new silicon processes have reduced the microcontroller bus signal voltage levels and also the bus drive strength. Microcontrollers with on-chip memories have been used in the past, and requesting that the silicon designers allow the microprocessor to run in an expanded mode had solved the software developers needs. By running in expanded mode, the address and data buses are exposed for physical probing by a Logic State Analysis (LSA) tool. Having the Central Processor Unit (CPU) write out internal accesses for tool use would also allow monitoring of internal resource activity, in Registers and RAM. Some silicon designers have referred to this feature as Show Cycles. In order to run the microcontroller in expanded mode during development however, the multifunction Input/Output (I/O) pins need to be reconfigured as address or data pins. The loss of these I/O pins in development needs to be compensated for in the initial design of the Electronic Control Unit (ECU). The design engineer has to make a decision to either refrain from using these pins for production configuration purposes or, if used, plan to design or procure a Port Replacement Unit (PRU) integrated circuit (IC) for the development ECU. As its name suggests, the PRU, provides substitute I/O for the ECU during the development phase; see below Figure 1. Page 1 of 14

FLASH

Debug Port

External Bus Module

Port Replacement Unit

I/O

Addr/Data
CPU Transparent Latch

Address

Data
RAM Timer/CoProcessor Peripherals

Figure 1 Single Chip Microcontroller running in Expanded Mode

Another way to provide the internal bus visibility needed during development is to create an emulation IC. This approach is not a favorite solution for most in the automotive industry for the following reasons: a) The emulation IC is not an accurate emulation of the production silicon because logic timing and analog characteristics can differ. b) It is economically difficult to ensure that the silicon revision of the emulation IC equals the silicon revision of the production IC, and silicon vendors can be reluctant to create new emulation versions, due to the associated high cost, unless there are differences that they, not their customers, deem as major issues. c) If an emulation IC is being used during development, then the production IC is not getting as much run-time exposure during the development cycle. Usually the emulation IC is suitable for bench environment but not in-vehicle use, therefore only a portion of the prototype ECUs will be built using the production IC and no tool interfaces. This means microcontroller errata or faulty software in the ECU may not be discovered until much later in the ECU lifecycle. Errors found later in the product design cycle are always more expensive to rectify. d) The emulation IC approach also does not offer the ability to diagnose defective production ECU hardware, and in particular defective microcontrollers. This prevents the thorough diagnosis of microcontrollers within their end application, which often prevents the recreation of the original problem and subsequently the proper defect resolution and future prevention. Without the ability to diagnose production units, it is unlikely that ECU suppliers will be able to maintain single digit PPM levels that they have worked so hard to achieve. Though microcontroller quality levels continue to improve, it is largely offset by the ever-increasing transistor count and complexity of the microcontroller. From the text above it is obvious that tool visibility to the single chip microcontroller has been a technical challenge in the past, and an expense to both the silicon vendor and the ECU designer. These past design strategies, however, cannot be applied to high-end microprocessors, as the off-chip memories can no longer be accessed at the same rate as the internal memories because of the internal bus structure of the microprocessor. Wide internal busses (64128 bits) cannot be sent outside of the chip, as too many I/O pins would be lost. Show-cycle functions in Harvard architecture or multi-bus microcontrollers now take up too much CPU throughput. Page 2 of 14

Some silicon designers have quoted numbers of in the range of 5% to 50% depending on the type of data being emitted to the external bus. The high clock frequency, low external bus voltage, and low external bus drive strength of the new microcontrollers also combine to make traditional, external bus access tool design difficult. A better solution had to be found which would allow access to the microcontroller by tools during development in a non-intrusive mode via a debug port that had a minimal number of dedicated pins assigned that are available during both the development and production phases of the ECU product.

FLASH

Debug Port

External Bus Module

FLASH

Debug Port

External Bus Module

CPU

CPU

X X X

RAM

Timer/CoProcessor

Peripherals

RAM

Timer/CoProcessor

Peripherals

Figure 2 von-Neumann and Harvard Architecture Microcontrollers

The IEEE ISTO-5001Nexus Forum published the first debug standard in 1999. This first standard is somewhat focused on the silicon debug solution and deals mainly with getting the necessary debug data messages in and out of the microcontroller. The implementation of this standard in various microcontrollers has now been available since 1999 and valuable experience has been gained in both the design of the silicon, the tools, and the application of them on the target ECUs. There is still work to be done in overcoming the issue that the automotive end user or developer needs an ECU that can be simultaneously attached to Rapid Algorithm Development (RAD), Calibration Development, and (Software/Hardware Integration) Debug tools. While being technically feasible, business issues have not yet allowed tool vendors to cooperate to develop one hardware solution that can be accessed by multiple software applications. This issue is being addressed, but the desired outcome is several months away. Applying these microcontrollers with IEEE ISTO-5001Nexus debug capability and their associated tools to an ECU design has required some additional learning experiences in the following areas for both the ECU designers and the tool vendors: a) Must design a reliable, high-speed electrical and mechanical interface between a Nexus microcontroller and a tool. b) Must consider the interaction of the tools when an ECU power supply is cycled through On, Off, On states, or when starting from an initial cold power-up. c) Must consider the reaction of tools when a target-initiated (microcontroller or peripheral) reset occurs, in order that they behave like a physical bus probing tool. That means the debugger should attempt to function in a passive manner similar to an LSA. d) Must consider and address the potential nature of tools in conditions where intrusive behavior can be dangerous or damaging. Page 3 of 14

e) Need the ability to capture additional I/O signals along with the code trace information, an essential feature for certain software algorithm verification needs and for hardware debug. Debugger vendors therefore needed to add this capability to their tool before it could be considered equivalent to a LSA. In the text below are examples of issues that were not captured within the IEEE ISTO5001Nexus specification but do impact the success or usefulness of a debug system when designing a target ECU with a Nexus-compliant microcontroller.

High Frequency Electrical and Mechanical Design

In automotive development environments that go beyond the lab bench, it is important that the ECU can be attached to the tools while in the in-vehicle environment, even in the underhood location. When choosing a connector it is therefore important to consider the rigorous mechanical and electrical requirements. When a tool is attached to the ECU, the connection system should provide a sealed, splash-proof interface between the development ECU and the tool. Standard automotive vibration requirements should be applied to the selection of the connector pins. The Nexus interface runs at either full microcontroller bus speeds or a small ratio of it. With current microcontroller offerings, this means running between 50150 MHz, so the connector pins must be selected to operate at these frequencies. Considerable research was done within the Nexus Forum to select a suitable connector, and a robust connector is recommended for automotive applications in appendix C of the standard. There are now multiple sources for this connector, which solves some of the initial concerns over price and order lead-time. This connector has a small footprint, however is a through-hole connector, which was initially met with some resistance from the circuit board designers but is still considered as the best choice.

Figure 3 Nexus Robust 51 Pin D with special twist insert for vibration performance

The following electrical considerations will assist in a successful design: a) On the ECU circuit board, locate the NEXUS connector as close to the microcontroller as possible with no trace longer than about 0.75". This is about half of the calculated critical trace length for FR4 circuit board material being used. b) Orientate the microcontroller IC so that all of the Nexus debug port signals have a straight path to the ECU tool connector. Page 4 of 14

c) Use the Nexus signal pull-ups and pull-downs resistors as recommended by the silicon vendor as starting point, then some additional changes may be required as driven by the tool vendors needs. It is recommended that AC termination circuits be placed on the MCKI and MCKO signals. d) The circuit board should have a solid ground plane and the power plane in the area around the microcontroller, memories, and Nexus connector. e) It is very important to surround the high frequency Nexus signals with guard traces to ensure signal integrity. f) Locate the power supply close to the microcontroller, and use low ESR ceramic capacitors for decoupling. g) Ask your tool vendors what passive components they have on each Nexus signal, so that your ECU design does not duplicate or counteract the pull-up / pull-down or filter components they have installed on the tool side. This exercise can also catch circuit components that cant be justified and could have a detrimental impact on your targets performance, such as capacitance on a reset line. h) Ensure your tool vendors are not drawing their power from your targets CPU core supply, which is the VREF signal pin defined on the Nexus connector. The tools should only use that pin as a reference voltage for the tools power supply circuits to monitor and track. This is spelled out in the Nexus specification, but there have been violations of this requirement. There are UBATT signals defined on the Nexus connector that are to be used as the prime power source for the tools interface buffer supply. i) Ask your tool vendors for a hardware design review of their tool, due to the critical high frequency interaction of tool and microcontroller. Though tool vendors may resist or refuse, there is a benefit to them since your company can provide them some deep design expertise or parts knowledge that may be lacking at a small tool vendor facility.
Nexus port orientated towards connector

Vehicle Connector

Serial ASICS

Power Supply
Short straight electrical path with guard traces

Serial ASICS Vehicle Connector

Microcontroller

Serial ASICS

(Optional) External Memories

Solid PWR plane Solid GND plane

Figure 4 Circuit Board layout for Nexus

Page 5 of 14

51 Pin Connector

NEXUS

General Nexus Debugging

The most important product design consideration when Debugging with IEEE ISTO5001Nexus is picking a microcontroller that has a suitable debug interface that meets your developers needs. The following sections deal with the fact that these features are not all functions of the debugger tools, but also rely heavily on the implementation of the Nexus debug port by the silicon vendor. The IEEE ISTO-5001Nexus specification allows for different levels of functionality to exist in the form of classes, with each class building on the previous class as follows. A Class 1 interface contains Run control with static or intrusive memory access, Class 2 adds Program trace, Class 3 adds Data trace with dynamic non-intrusive memory access, and finally Class 4 adds Port Replacement Unit capability and Ownership trace. To date there has been no hard line on industry claims of Nexus capability, as there is currently no ISTO certification test established to prove or disprove the validity of these claims. The IEEE ISTO5001Nexus Forum understands that certification is an important next step in the standards committee charter. The following text discusses some discoveries that impact the usefulness of a Nexus design in various areas of implementations.

Run Control
In previous ECU designs, the debug interface that provided run control features was not even made physically available on the in-vehicle development ECU. Halting a microcontroller that is operating a plant control system in a real-time environment can cause physical damage to the plant that it is controlling, and can also cause operator safety issues. The Nexus port is now the single point interface to the microcontroller for all tools and therefore must now physically exist on the development ECU. Since the Nexus port implementation allows for legacy static (or intrusive) memory access in addition to the new dynamic (or non-intrusive) memory access, the tool vendor must take care as to which method is used. An intrusive memory access on a bench by a debugger tool may have no apparent adverse effects, but a similar access by a calibration tool in an in-vehicle situation may cause disastrous effects for both plant and operator. To avoid problems in this area, it is recommended that the ECU designer or Tools engineer have a design review with the tool vendor to specifically investigate their implementation of these functions to avoid undesired operation when the tools are in use by a wider developer community. The authors have only had time to perform an in-depth review on two debugger vendor tool implementations. We believe that both the silicon vendor and tool vendors should cooperate on this safety critical area to ensure proper operation, or at least require that the tool operator makes a conscious decision as to what mode they are operating in. An example of this is the "Inhibit Intrusion" feature that was implemented by one debugger vendor at our request. When that feature is invoked, the debugger does the following: a) Clears all pre-existing breakpoints, and prevents future breakpoints from being set. b) Prevents any on-the-fly accesses to CPU registers or memory that would temporarily halt the micro. c) Disables any user buttons or commands that could break or halt the CPU. d) Informs the user of the above restrictions, if they attempt any of those actions. e) Exits this mode only if the user explicitly deselects this feature via a debugger GUI checkbox.

Page 6 of 14

Program Tracing
In order to discuss the concept of program tracing when using Nexus, it is important to first distinguish between the ability to trace execution of microcontroller instructions, or opcodes, with a traditional physical bus probing solution such as a LSA and what has now been termed Branch Tracing Messaging (BTM). The BTM method captures program flow discontinuities, which comprise of direct branches, indirect branches, interrupts, and exceptions. This method provides ample bandwidth for instruction tracing using a minimum number of microcontroller pins. The development tool then interpolates or reconstructs what transpires between the discontinuities. As a result, static code is easily traced, and even code that is relocated or self-modifying at run time can be traced if the user makes the tool aware of the relocation, or if the tool is told to fill in the trace using dynamic reads of the current target memory contents. It is however equally important to delve deeper into BTM implementations to see what capability you actually get with each silicon vendors implementation that claims to be Nexus-compliant. Due to bandwidth limitation issues on the debug port, not all implementations are equal in functionality, as the silicon vendor will have to make compromises on the number of I/O pins assigned to the debug port. This impacts the size of the internal Nexus message FIFO buffer and the number of program execution instruction types that causes the Program Counter (PC) register content to be emitted. The result of these compromises may require large buffers of trace data to be collected and displayed in order find the code section that needs to be reviewed. It may even be too difficult to capture the code section of interest being executed without first modifying the code to include instructions that will cause a trace discontinuity to occur before the code of interest so that it will appear in the debuggers trace data. Most silicon implementations allow for control of message bandwidth to be selected programmatically through register settings, allowing for different BTM messages to be emitted under control of user input via the debugger tool.

Ownership Trace
Task awareness via Ownership Trace Messages (OTM) provides visibility of which process ID or operating system task is activated. An ownership trace message is transmitted to indicate when a new process or task is activated; allowing development tools to trace process/task flow. The tool vendors have not yet developed this function, as it requires cooperation between the compiler and debugger vendors.

Data Tracing
Data trace via data write messaging (DWM) and data read messaging (DRM) are the functions that cause the highest bandwidth requirements for the Nexus port. These features cause the silicon designer to add additional Nexus message FIFO buffer space, and require more pins to be assigned to the debug port. DRM & DWM provide the capability for the development tools to trace reads or writes to selected internal or external memory resources. Data trace messages or dynamic data read/write messages also allow for variable acquisition for RAD and Calibration development tools. It is therefore important that the ECU designer keep these pins Page 7 of 14

available for debug use and avoid the temptation to use them for ECU I/O drive needs. In order to be flexible, most silicon vendors will multiplex the debug port pins with other functions. In order to reduce the message bandwidth, some silicon vendors provide multiple data trace windows with programmable address range and access attributes. Data trace windowing reduces the requirements on the auxiliary port bandwidth by constraining the number of trace locations that cause messages to be transmitted to the tools.

Power Moding and Run-Through-Power-Up-Reset Considerations

In the automotive sector, many ECUs run from switched power, typically from the Ignition key switch. This was not a problem for previous generation ECUs that used microcontrollers in expanded mode, since LSA tools were passive instruments on the external bus and did not interact with the target microcontroller or use target power. With a Nexuscompliant microcontroller and tools, switched power is an additional factor to be dealt with, since the on-chip debug port is running on switched power. This is not an element that commercial tool vendors had dealt with in the past, since their microcontroller emulator products were typically self-powered and intolerant of target-initiated resets and power cycles, and their non-automotive customers do not have switched power concerns. Since their emulator products are now utilizing on-chip Nexus resources within microcontrollers mounted on the target, they must now be reliant on and aware of the targets power and status. Work was done with the tool vendors to implement the ability for tools to handle target power cycles, primarily so that debugger tools could trace power-down and power-up code with minimal intrusion so that real time measurements of software events are not significantly altered. The following is a generic excerpt of a Run-Through-Power-up-Reset feature requirement for debugger tools: a) The debugger will have to sense the state of target power (Nexus VREF signal) and target reset (Nexus RESET signal) in order to achieve this functionality. b) When users enable this feature, the debugger can no longer assert the reset signal on its own in order to gain control of the target. It must synchronize itself with target-initiated resets. Though the debugger is allowed to extend that reset time to ensure it can accomplish its entire Nexus messaging (needed to configure the microcontroller for any user-selected tracing or breakpoints) that must be done while reset is active. c) Since some microcontrollers can not access all registers and memory while reset is active, it is acceptable that tools momentarily halt the microcontroller after reset has been released, in order to quickly configure the microcontroller for any user-selected tracing or breakpoints that were not possible to configure while reset was active. The microcontroller should be stopped for as little time as possible, so it does not significantly affect the target system's real-time performance. Our goal was less than 50 milliseconds. Times longer than that may be acceptable if the time is a known fixed period that can be subtracted from users real-time measurements, such as time from reset being released to the execution of a specific software event. See Figure 5 below for the above requirements depicted in a timing diagram.

Page 8 of 14

Nexus HW signals, unless noted otherwise

Target Power off

Target Power on

VREF (CPU VDD) From Target

RESET* (from target) From CPU (bidirectional) RESET* (from tool) From debugger (bidirectional) CPU internal activiity (not a H/W signal; High = CPU running) EVTI* From debugger

CPU halts & enters Debug mode out-of-reset

Debug mode

CPU exits Debug mode and starts execution

RSTI* From debugger

From CPU MDO signals

From debugger TDI or MDI signals CPU stops in Debug Mode immediately out-of-reset (due to DC register write while RST* active). Debugger then writes needed registers (breakpoints, etc.) as quickly as possible, then exits Debug mode so normal program execution starts. Note this step can be skipped if no breakpoints/watchpoints need to be configured.

When debugger detects that VREF has gone low and the target has asserted RESET*, debugger should then drive RESET* low (before target negates RESET*).

Once VREF comes back up, debugger can initialize NEXUS port by repeatedly pulsing RSTI* lo-to-hi until a valid Device-ID message is received on MDO signal lines.

Once a valid Device-ID message is received, debugger will program DC register to enter Debug mode out-of-reset, and turn on TM bit per user setting. EVTI* is then driven high and then RESET* is released (high) by debugger.

Figure 5 Run-Through-Power-Up-Reset Requirements

Future microcontroller designs could offload some of these burdensome requirements placed on the tools, and reduce or eliminate debugger intervention, if the microcontroller design had the following features: a) The ability to save the debug-related register settings for the trace and breakpoint resources when microcontroller main power was removed while Keep-Alive-Memory power was not removed. Page 9 of 14

b) The ability to restore those saved register settings upon subsequent target power-up, contingent on user-selectable bits within the Nexus port initialization message that the microcontroller receives while reset is asserted.

Run-Through-Warm-Reset Considerations
Related to the Run-Through-Power-Up-Reset requirement above is the need to properly handle running (i.e. warm) resets where target power remains constant and the cause of the reset is some type of fault. Typically this is microcontroller-generated since it has multiple sources that can cause reset, but it can also be a peripheral device (such as external COP watchdog). Unlike a power-up reset, however, a running reset is usually a relatively short event in the microsecond range. That is very challenging to most Nexus tools, as they will not be able to detect and react to those resets fast enough. This is because the tools usually poll the inputs on a periodic basis, typically in the hundreds of milliseconds range, which means it has little chance of catching the running reset while polling. Since the running reset will have came and went by the time the debugger polls again, the CPU will now be in a state unexpected by the debugger, typically halted in Debug mode out-of-reset (due to some DC register fields that are retained through a warm reset). The debugger will usually then inform the user of the CPU stopped status, and the user then has to restart CPU execution using debugger commands. This behavior where the CPU is halted out-of-reset is usually fine in a simulation environment, but does not suffice for performing real-time measurements of target reset recovery times, or for operating in a real-time environment (discussed later). Though the CPU will have to be halted momentarily out-of-reset in order for the debugger to configure breakpoints or watchpoints, this time should be brief or a known fixed delay value that can be subtracted from measurements, with the debugger using an approach identical to the Run-Through-Power-Up-Reset approach discussed earlier. For a debugger to accomplish this, it requires the ability to immediately (i.e. within several microseconds) detect the target-initiated reset and assert the RESET signal in parallel to the target-initiated reset. The debugger will then restore the desired Nexus debug settings in the same manner depicted in Figure 5 above. Though the same approach can be used by debuggers to handle both power-up resets and running resets, one significant difference is that if the debugger introduces a significant delay (relative to the application) while extending reset or having the CPU halted in Debug mode outof-reset, then the effect may be unacceptable when operating a plant control system in a real-time environment. It should not cause physical damage to the plant that it is controlling, since the delay will occur while the controller is in a safe reset state, but it could introduce some hesitation in the system operation that could cause operator safety issues. An example would be an automobile engine controller that has additional milliseconds of reset delay introduced by having a debugger attached while driving the vehicle on the road. If the delay is only several milliseconds, then the effect will be a slight engine stumble that is tolerable, but any delay longer than that may result in a pronounced engine stumble and vehicle slowdown that could put the vehicle and its passengers at risk in certain traffic conditions.

Page 10 of 14

Note that the handling of warm resets assumes that the Nexus RESET signal is bidirectional, in that it reflects the state of the CPU reset input, as well as the state of the CPU reset output. This is necessary so that CPU-generated resets (typically due to self-detected faults) are visible to a debugger, so it can quickly synchronize itself to the reset event and get the CPU running again with minimal delay. If the CPU lacks the ability to self-generate a reset, then the RESET signal does not have to be bidirectional and can simply be the CPU reset input signal. The Nexus specification only requires that the RESET signal will cause the target to enter its reset state, so it only has to be a CPU input as a minimum. Calibration and RAD tools also need visibility to CPU-generated resets, as their processes need to see reset and synchronize themselves with the target to perform their operations. If they are not able to, the effects are different than that for debuggers, as these tools do not program the CPU to stop in Debug mode out-of-reset. Therefore, these tools introduce no delay by extending the reset duration or momentarily stopping the CPU out-of-reset, but their respective operations will be lost after a running reset occurs that they cannot detect. For Calibration tools, the effect is minor since the target will run fine, as only the ability to calibrate is lost. For RAD tools, the effect can be more severe since the loss of the RAD process after a reset can result in a non-functional target, if the target code itself does not contain functional algorithms. If your chosen CPU can generate a reset but does not have a single bidirectional reset pin, and you can not create an artificial one using glue logic (to combine CPU Reset_In and Reset_Out signals) on your target, then you will not be able to use the Nexus RESET pin alone to get tool visibility. In those cases, you will have to work with your CPU and tool vendors to implement a Reset_Out signal somewhere on the Nexus connector. The Vendor_IO and Tool_IO signals are natural candidates for this. Be aware that some of these signals have started to take on informally standardized functions by the tool vendors, with formal standardization being sought in the near future. (See later Interoperation with other tools section for discussion of multi-tool arbitration scheme).

External COP Watchdog Circuits

Most automotive ECUs use a microcontroller with an internal COP watchdog capability, and often supplement that with an additional external watchdog circuit as well in safety-critical applications. Dealing with an internal COP feature is a standard issue for debugger tools, as they often give the user the choice of enabling or disabling them. Dealing with external watchdogs, however, is not possible since tools have no visibility or control of them. Therefore, users must make provisions in their ECU designs to properly handle external watchdogs so that they do not assert system or microcontroller resets unexpectedly. That typically happens when the microcontroller is temporarily halted by a debugger breakpoint, but the external watchdog is still free-running and no longer being serviced by the microcontroller, so the watchdog times out and generates a system or microcontroller reset. There are two methods that have been used to handle external watchdogs: FREEZE THE WATCHDOG This method temporarily halts or freezes the external watchdog whenever the microcontroller is halted, so that the external watchdog and the Page 11 of 14

microcontroller are stopped and started in lockstep. This preserves real-time operation of the watchdog relative to the microcontroller, so that the watchdog hardware and the software that services it can be debugged reliably and more importantly that the watchdog can be always enabled. (Product teams have been known to ship early prototype units with faulty watchdog functions that were masked by development environments that had internal or external watchdogs temporarily disabled). This method is seldom used, because it involves two elements that are rarely available: a) A microcontroller with pins that communicate the microcontrollers internal halted or Freeze status. These pins were largely present to support LSA tools, and their need has now diminished. b) An external watchdog circuit or IC that has an input that will freeze the watchdogs timer. Note that if a secondary microcontroller is used for the external watchdog, users may attempt to link the debuggers of the two microcontrollers so that one debugger can start and stop the other debugger in lockstep. This linking is either done through a hardware signal, or a software connection on the debuggers host PC. Though this linking works well for debugging software interaction between the two microcontrollers, it has not yet been found to be fast enough to preserve real-time operation of the watchdog. Typically the link response time is too slow compared to the watchdog timer period, so eventually the watchdog expires because the secondary microcontroller was not stopped and restarted in lockstep with the main microcontroller. DISABLE THE WATCHDOG This commonly used method disables the watchdog temporarily, usually by using a hardware jumper or switch for a user-selectable mode. If the watchdog is strictly hardware, then the disabling is relatively straightforward and just involves either disabling its ability to generate reset (typically by disconnecting its output from reset), or tying its input to a state equivalent to microcontroller servicing. If the watchdog is a secondary microcontroller, then it can get more complex. If the secondary microcontroller controls other ECU functions besides acting as a watchdog, or has a communication path to the main microcontroller besides its watchdog servicing link, then there is the possibility that the ECU will not fully function once the secondary microcontrollers watchdog function times out. Often times, the secondary microcontroller will disable other ECU functions when its watchdog times out, and sometimes the only way the secondary microcontroller can recover is through the system reset that is it attempting to assert, but is currently disabled. This prevents the ECU from operating in its normal manner. The preferred method to address this situation is through hardware means that mimic the secondary microcontroller acting as if its watchdog function has not timed out. The alternate method is to insert hooks within the secondary microcontroller software that read the state of the watchdog disable hardware signal, and then disable the watchdog function accordingly or at least skip its resultant actions. The software approach is less desirable because it is more prone to error, such as a software defect that results in the watchdog always being disabled regardless of hardware input state. Note that if the external watchdog needs to be re-enabled and tested or debugged with a tool connected, it can be done as long as the microcontroller is never halted by a breakpoint or a user action with a debugger. This limits the watchdog debugging to real-time tracing of code and real-time monitoring of software variables, but that is often sufficient.

Page 12 of 14

Interoperation with other tools

The automotive end user or developer requires an ECU that can be simultaneously attached to Rapid Algorithm Development (RAD), Calibration Development, and Debugger tools. For example, an algorithm that has been developed with a prototyping tool such as Simulink may not be executing correctly in the target ECU environment. The suspect code may be executing in the ECU hardware and also in the RAD tool, so the developer must therefore attach a debugger to the ECU/RAD target combination to investigate the problem. In a similar fashion, a newly developed control algorithm may need to be calibrated, creating the necessity to connect both the RAD and Calibration development tools simultaneously to the ECU. So far no vendor has offered a tool that supplies all three functions, and no vendor has cooperated enough to allow for all three separate tools to be attached simultaneously. However there are some vendors with non-competing tool markets who have came to an arrangement for arbitrating the Nexus port between different hardware tools. At this time a compromise has been reached to allow any combination of two of the three tools to be connected at any one time. The main technical contention is that each of these tools has differing bandwidth requirements. However, most work on the common principle of requiring reading or writing to memory in the target ECU, but some have additional requirements. A multi-tool arbitration scheme has been designed and the specification for this method and an accompanying Stateflow model has been submitted to the Nexus Forum for consideration to be published as part of the specification, or to be referenced as a companion document for successful tool design purposes.

Summary
Microcontrollers that contain an IEEE ISTO-5001 Nexus debug port, when used in a properly designed target product with associated Nexus tools, can solve the issue of developing control algorithms in real-time while operating in a single chip environment. One additional benefit to this approach is that the port is available throughout the life of the target, making it suitable for use when diagnosing production field returns. A Nexus Class 3 debug system can provide a rich debug environment for the software developer, providing run control, program and data tracing. Careful design of the target ECU and selection of appropriate tools also allows for debugging power cycle, initialization, and reset situations. This debug port is also suitable for use by additional tools that require reading and writing to memories in the ECU such as RAD and Calibration Development tools. The use of a reliable connection system with a hardware arbitration scheme can allow for the stacking of these tools for simultaneous operation as required by the end users.

Conclusion
Multiple silicon vendors, tool vendors, and end users have participated in the IEEE ISTO-5001Nexus Forum. Silicon is available from more that one vendor, and more than one family of microcontrollers use the Nexus debug interface. Rapid Algorithm Development, Calibration, and Debug tools are available from more than one vendor. More than one end user has put ECU products into production using Nexus silicon and tools. The Nexus-based tools are Page 13 of 14

significantly less expensive than traditional physical bus probe tools and ROM Emulation tools while retaining most, if not all, of the functionality. Based on past success, new generations of microcontrollers are already coming onto the market with faster and further enhanced Nexus ports. From an end users point of view, however, we do not yet have the optimal solution in place. So to the marketing managers of the silicon and tool vendors companies, there is a customer need to have microcontroller silicon that can be developed in the single chip environment. The new silicon requires a change to tool designs and there are customer needs to be satisfied. Tools must be developed that can either interoperate and share the Nexus bus, or one tool should be provided that allows for rapid algorithm development, calibration, and debug of control strategies. In order that the customer is aware of what functionality can be achieved, it is important to understand the different class of tools within the Nexus specification, and some method must be put in place to certify that designs truly meet these classifications.

Acknowledgments
The authors wish to thank the following members of the Delphi Electronics & Safety, Development Tools department: Larry Burkholder for his expertise in debugger technology, Mark McFarland for his contribution towards RAD tools and the multi-tool hardware arbitration method. Further thanks goes to John Baker, Delphi Electronics & Safety, Microelectronics Design Center for his expertise in microcontroller technology and his contribution towards the successful electrical design of the Nexus interface on target ECUs.

CONTACT
The author is a graduate of the Queens University of Belfast, N. Ireland, has a Masters Degree in Computer Science (1981) and a Bachelors Degree in Electrical Electronic Engineering (1978). He has worked as an EE design engineer in the Aerospace, and Electrical Power Distribution industries. The author joined Delphi Electronics & Safety, Development Tools Department in 1987 and has served in a number of positions within the development tools group where he is currently the Engineering Group Manager and can be contacted by email at william.james.allen@delphi.com. The co-author is a graduate of the Milwaukee School of Engineering, with a Bachelors Degree in Electrical Engineering Technology (1988). He has worked for Delphi Electronics & Safety since 1979, first as a technician in the Avionics division, then in a number of engineering positions (Test, Systems, and Software) within the Automotive division. He joined Delphis Development Tools group in 2001, where his primary role is the support of Nexus emulators & debuggers for Powertrain products. He can be contacted by email at john.e.siitari@delphi.com

Page 14 of 14