Go to ColdFire Development Suite order page

The Crossware ColdFire Simulator creates a virtual ColdFire microprocessor that runs on your PC. It allows you to run your ColdFire program without any ColdFire hardware and watch your code execute in the graphic environment of Windows 9x, Windows NT 4.0, Windows 2000 and Windows XP.

• Full source-level debugging
• Simulates all Series 2 and Series 3 ColdFire chips including MAC unit
• Simulates on-chip timers and UARTs
• Simulates Series 4 ColdFire chips, including branch acceleration cache and hardware stack
• Seamless integration with the Embedded Development Studio
• Dockable windows
• Multiple watch windows and tooltips for local and global C variables and assembler symbols
• Views of all memory areas, registers and disassembled program (mixed with source code where available)
• State capture to capture and restore the complete internal state of the microcontroller
• Complex hierarchical breakpoints built by drag-and-drop
• Source code profiling
• Code and data coverage analysis
• Multiple cycle counters

Seamless Integration with the Embedded Development Studio

The Embedded Development Studio forms an integrated environment that binds together the various Crossware tools. It automatically detects the presence of the Simulator and loads it to create a single unified application. The text windows that you see as you single-step through your program are exactly the same as those you use to create and edit your source code. If you set a breakpoint as you edit your code, this is where execution will stop when you instruct the Simulator to Go.

When the simulator is used stand-alone, the Embedded Development Studio provides a customisable interface to your tool set. You therefore can edit and keep your project up to date using all of the sophisticated features of the Embedded Development Studio using your existing compiler, assembler and linker.

Full Source-Level Debugging

The IEEE695 records generated by the Crossware C compiler and assembler contain full debugging information. These debug records are used by the Simulator to provide comprehensive source-level debugging. You can single-step and trace through your C source code files, you can single step and trace through your assembler source code files, and you can set breakpoints at the source code level to control the execution of the Simulator. Alternatively, if your program does not contain any debugging information, or if you want to step through your C source at the assembly level, the disassembly window supports your needs.

Multiple Watch Windows for Local and Global Variables

You can open up to five watch windows to display the values of your C variables. One of these watch windows automatically will display local variables and be updated automatically as variables move in and out of scope. The other four windows can display global and local variables of your choice. You can freeze the contents of a watch window to prevent it from being updated by the simulator. This feature allows you to compare historic and current values of your variables.

Call Stack

The call stack allows you to follow the progress of your program through the layers of function calls. The call stack window shows the name of each active function, and the values of the program counter, stack pointer and the source code line number reached in each function. You can navigate through the functions in the call stack; double-clicking on the function name in the call stack window will take you to the location in your source code reached in that function.

Views of Memory Areas

You can open multiple views and watch all memory areas, setting breakpoints when memory locations are written, read or both. Coloured highlighting shows you which locations are changing and optionally you can enable data coverage so that you can see clearly which memory locations have been accessed and which have not. You can edit any memory location in hexadecimal or ASCII format.

View Named Registers

You can open a view to display and edit named registers.

Exception Simulation and Views

You can either trap or simulate exceptions. You can choose which exceptions to trap and which to simulate on an individual basis. Exceptions that are being simulated can be triggered either by a condition that occurs in your program (e.g. address error or trap) or from a tree view that displays the exception being simulated.

State Capture

The state capture facility allows you to store the complete internal state of the simulated microcontroller. You can capture the internal state any number of times and select and view them at a later stage. When you select and view a captured state, all of the memory views are updated to show the captured state. You can fully restore a captured state. Then, when you next run the simulator, it will start with all conditions, memory, cycle counters, program counter, etc. restored to the values current at the moment you captured the state. You can use this feature to run a small segment of your code repeatedly.

Views of Timers

You can open an activity view for each timer and immediatelysee how your program has configured it. You can watch the countervalue as it changes during program execution.

Views of UARTs

You can open an activity view for each UART.There are two views to choose between. Oneshows you how your program has configuredthe UART; the other displays the UARToperating as your program executes.

Variable Tooltips

Tooltips allow the type, value and location of a variable or symbol to be viewedwithout a watch window. If the mouse cursor remains stationaryfor more than half a second over a variable or symbol in asource code window, a small window pops up to display thisinformation.

Complex Hierarchical Breakpoints

Simple PC and data source-level breakpoints can be built into complex break conditionsusing drag-and-drop. A tree view displays the breakpoints, and one breakpointcan be made dependent on another simply by dragging the other breakpointonto it. One breakpoint becomes the child of the other. A breakpoint can havemultiple children, and these can be combined using AND and OR logic so theparent will not be triggered until either all or any one of its children have been triggered.Child breakpoints can have their own children, so it is possible to buildextremely complex breakpoints with a minimum of effort. As each breakpoint isencountered by the executing program, its count is decrementedand displayed. When the count reaches zero, the breakpoint is triggeredand its indicator changes from red to green. Thus it iseasy to follow the progress of the breakpoint hierarchy as the breakpointsare encountered and triggered. Execution halts when thetopmost parent is triggered.

Source-Level Data Breakpoints

Breakpoints can be set on C and assembler variables to halt execution when thevariables are accessed or when they match a value or range of values. Multiple data and PCbreakpoints can be combined with each other using drag-and-drop in the breakpoint tree asdescribed above.

Source Code Profiling

As the simulator runs your program, it optionally can capture information about the execution history. It can use this information to produce an execution profile of your source code. This will tell you how much time your program spent executing in the different parts of your code. The profile results are listed in a text window sorted in accordance with your selected criteria. A doubleclick on a listed item will take you to the relevant line of your source code.

Code and Data Coverage

The information captured during execution can be used also to provide a coverage analysis. Code coverage will show you which parts of your code have been executed and which have not. Data coverage will show you which memory locations have been accessed during execution.

Multiple Cycle Counters

The status line contains three cycle counters. One of these displays the number of cycles executed since the start of the program; another displays the number cycles executed since the last command was issued (such as Step, Trace or Go). The third is a trip counter, and displays the number of cycles executed since you last reset it to zero.

Memory

The simulator allocates memory in 64k blocks as required by your program. The maximum memory is therefore limited only by the amount of memory on your PC.

Program File Formats

The file formats supported for the ColdFire program code are Motorola S-records, IEEE695, Intel hex and Binary.

Host System Requirements

IBM compatible PC with an Intel 80486 or above running under Windows 9x, Windows NT 4.0, Windows 2000 and Windows XP.

Go to ColdFire Development Suite order page