Capturing and Debugging System Crashes
Scenario #2: When the system clock keeps running after the system crashes
In this scenario there is a need to be more creative and set up more complex triggers to capture the events leading up to the crash. Waiting until someone hits the 'stop' button after the system crashes is no longer a viable solution even for state mode, and the system clock can no longer be used as a timing mode trigger to capture the crash.
Frequently, the most difficult part of setting up a complex trigger is breaking down the problem. In general, when setting up a complex logic analyzer trigger do the following:
Step #1. Break down the problem into events that don't happen simultaneously. These correspond to the sequence levels in the logic analyzer trigger.
Step #2.. Scan the list of trigger functions to try to find some that match each event identified in the first step. Setting up logic analyzer triggers can be greatly simplified by using pre-defined trigger functions (macros).
Step #3.. If an event doesn't correspond to a predefined trigger macro, break it down into Boolean expressions and corresponding actions to each expression. Each Boolean expression or action pair corresponds to a separate branch within a sequence level.
Boolean expressions result in true or false, for example: PatternA = FFF is either true or false depending on the value of PatternA when it is comparedeye to FFF.
One approach to triggering on system crashes when the clock continues to run is to figure out a signal that happens regularly or within a specified time, and set up a trigger that times out when the event doesn't happen within a time limit.
This could be a signal from a bus specification, an interrupt, a signal that can be injected using a bus exerciser, or any signal or pattern expected on a system running a specific test.
Example: Let's consider an embedded system with DDR2 memory. Refresh is a command made up of three individual signals and is valid only when a chip select line is low (CS0#).
A refresh must occur at regular intervals to keep the data in memory valid. The static refresh for DDR2 (and previous DRAM technologies) is 64ms. This means that every cell must be refreshed at least every 64ms, or data corruption may occur.
Therefore, a trigger watching for intervals greater than 64ms between valid refresh commands is valid to capture system crashes on systems with DDR2 memory. See Figure 3 below.
 |
| Figure 3 An example trigger from a 16950B Logic Analyzer for capturing a DDR2 system crash by watching for too much time between refresh commands. |
The use of a symbol table for the 'command' label makes selection of auto refresh/self refresh simple. This concept/algorithm can work for state or timing modes. Comments help to follow the trigger flow and make it easier to modify triggers for similar situations.
If the time to capture the system failure is tightened, for the DDR2, the average amount of time between each auto refresh command is 7.81 microseconds.
Taking a trace of a healthy system and looking for the normal rate of refresh cycles in a system helps determine a shorter time to use as a time out indicating a failure for a specific system.
If the logic analyzer is sampling at regular intervals, a counter can be used in place of a timer, which can be simulated by counting the number of samples acquired. For example, if the logic analyzer acquires a new sample every 2.5 ns (200MHz clock sampling on both rising and falling edges) then 25,600 samples represents 64ms.
In this case, a logic analyzer may already have a state mode trigger macro ready for the user to fill in the number of states and signal names. See example in Figure 4 below. Similarly, in timing mode the trigger macro 'pattern absent for >t time' can be selected.
 |
| Figure 4: Too many states between refresh commands, and the the qualification of CS0# = low was added to indicate a valid command for this example on a 16950B Logic Analyzer module. |
Another option is to inject a known pattern or signal that can be easily recognized using a software routine, pattern generator, or bus exerciser. (Many logic analysis systems have built-in pattern generators. In systems with a PCI or PCI express exerciser, commands can be injected to create known data patterns on the PCI/PCI express bus, processor bus, or memory bus.)
Loading comments... Write a comment