Consider the benefit of having the data from every SFR direct data write visible in the trace. The Special Function Registers represent the core functionality of the 8051 architecture, including Accumulator, B Register, Program Status Word, Stack Pointer, Data Pointer, Port Registers 0 through 3, Interrupt Priority and Interrupt Enable Registers, Timer Counter Registers, Serial Channel Control Registers, and Power Control Register. These registers are vital to every 8051 application, because the 8051's operation is controlled through the appropriate use of these registers. It is critical for the designer to be aware of any change in the status of these registers. 

With MetaLink's new emulator feature, any time an instruction performs a direct data write to any one of these SFR's, that data will be recorded in the trace frame. The engineer can trace the instruction-by-instruction changes in these vital registers. For example, the instruction MOV P1, R3 will move the contents of register R3 to the Port 1 latch. MetaLink's emulator trace display will show the data of R3 as it is being written to the port's latch. MetaLink's new emulation feature will make it easy and quick to check this critical SFR information, which is collected from the application non-intrusively and in real-time.

• Visibility of SP, IE, and DPTR in the Status Window, and

• Visibility of SP, IE, and DPTR in the Trace

MetaLink monitors certain key parameters in real time as emulation proceeds, displaying them in certain status windows. Examples are Execution Time, Program Counter, Break Address, and Pass Count. MetaLink will add the SP, IE, and DPTR to these attributes, making them easily visible to the engineer during emulation.

MetaLink's new execution trace memory feature will regularly display the SP, IE, and DPTR. The contents of these registers are collected in real time and displayed every 8 frames in the trace memory, giving the engineer a history of these important registers. Why is this visibility important to the 8051 system design engineer?

The stack and Stack Pointer are critical to modern programming methods, which incorporate modularity and reusability through the use of many subroutines. The stack is used to store the return address for the completed subroutine. The Stack Pointer is an SFR that keeps track of the location of the top of the stack. Many situations require a large stack, but the available memory space in most 8051 derivatives is quite limited, so the stack must be closely managed to avoid overflowing. Besides storing the return addresses for program control, the stack can be used to save the 'context' of the current environment, such as the Data Pointer (DPTR) register and other registers, so they do not have to be recreated by the main program upon return from the subroutine. Interrupt-driven applications abound in embedded control, of course, and interrupts necessarily involve the stack. The 8051 acknowledges an interrupt request by executing a hardware-generated LCALL to the appropriate servicing routine, a vector address that depends on the source of the interrupt. The LCALL pushes the contents of the Program Counter onto the stack and reloads the PC with the vector address.

It is obvious that the condition of the Stack Pointer at any time is vital information for the designer. As mentioned above, stack space overflow is a continual concern and can be difficult to debug when it does occur. MetaLink's new emulator feature gives the designer the visibility he needs--the SP is collected in real time and displayed every 8 frames in the trace.

The Interrupt Enable register is a key part of most designs. The 8051 is a great embedded controller, which requires monitoring external events and reacting appropriately. The 8 bits of the Interrupt Enable SFR control the status of the 5 (or more) interrupt sources. A quick look at IE tells the engineer which interrupts are enabled and which are not. MetaLink's new emulator features put the IE on display for the designer. During emulation, it is shown in a status window. Selecting the trace memory window displays the IE as it was collected in real-time.

The Data Pointer (DPTR) is a two-byte register that points to a location to facilitate reading and writing from data memory. Many modern routines manipulate the DPTR often, and it is important for the designer to keep track of the DPTR. MetaLink's new emulator feature puts the DPTR in an emulation status window and in the execution trace memory to make it easy for the engineer to monitor the next read/write location. Some 8051's contain an alternate DPTR-MetaLink will always display the one that is currently selected.

Many things can and do wrong when a new hardware system is being brought up for the first time with new software. For instance, the program may mistakenly create an uncontrolled chain of subroutine calls. In another case, an engineer may need to add a feature to an existing application. If he is not aware of the maximum level of the SP at that point in the program, he may not know for sure if there are enough resources on the chip for the new feature.

In these cases, a limit breakpoint becomes an ideal feature. For instance, the engineer may utilize a warning if the stack, which initializes at 07H at a reset, ever exceeds 17H. The engineer could set a stack limit breakpoint at 17H, and the emulator would break if the SP ever exceeded that address.

Similarly, many bugs result from misuse of the Data Pointer register(s). Dual data pointer systems are very useful for block moves in external RAM, for use with a frequently called interrupt routine, for tree structure manipulation, for creating an external stack, and many other situations. Once they are properly set up, they are great for optimizing the execution time and resources of the application. However, during initial programming, it is very possible to load the DPTR with an inappropriate value. For instance, uncontrolled incrementing or alteration of the data pointer can cause an attempt to write to a memory location that doesn't exist in the application. MetaLink's new emulator feature allows the designer to set a breakpoint at a reasonable limit for DPTR. Any DPTR MOVX or MOVC access that exceeds the limit causes the program to break, and the engineer is alerted to a possible problem.