Embedded Systems Design - Europe - August/September 2007 - (Page 32)

software Listing 1 A simple capture library interface. TDR_BufferInit (module_ID, num_entries, process_ str) Creates and initializes buffer TDR_ThreadAddIndentity (thread_str) Indentiﬁes a thread of execution using buffer TDR_ThreadRemoveIdentity () Removes thread identiﬁcation information from buffer TDR_Store(module_ID, event_id, data_p) Stores trace information TDR_BufferDestroy () Destroys trace buffer The “data_p” argument to TDR_store() points to: typedef union { unsigned char data_byte[TDR_BYTES_PER_ENTRY]; unsigned int data_word[TDR_WORDS_PER_ENTRY]; }TDR_data_t; centralized through the system’s logging subsystem. The logging subsystem must allow developers to assign a severity to each message the software logs. The severity indicates the importance of the message. Popular severities include Info, Warning, Error, and Fatal. When software reports a Fatal message, it means that a catastrophic error has occurred and the system is going to reboot. Before this occurs, the logging subsystem triggers a TDR dump. Another method to trigger a dump is to add code to any panic or exception handler the operating system provides. If the operating system crashes, the panic handler triggers a TDR dump. This method may require the TDR dump code to run in kernel space. The TDR may also need to access the non- volatile memory using different drivers than are used during normal operation. Linking the dump to the panic handler is particularly valuable if the system has a signiﬁcant amount of kernel-level code that can cause crashes. THE CAPTURE LIBRARY The TDR library provides functions that other subsystems call to preserve data about their execution. The data is time-tagged by the library and placed into circular capture buffers. Listing 1 shows an example API for a capture library. Software subsystems use TDR_ BufferInit() to create and initialize a capture buffer. In an RTOS that provides lightweight tasking, the buffer may be dynamically allocated from the heap. For an operating system that institutes heavyweight tasking, the buffer can be created in shared memory or memory mapped to a device driver. The TDR_BufferInit() function also “registers” the buffer with the dump agent so that it’ll be included in the next dump. The buffer is marked with a module_ID to indicate the subsystem that created it and a string to help identify the speciﬁc trace buffer in the dump. The module_ID can also be used to group and selectively dump buffers in more complex implementations of TDR. The number of entries argument indicates the number of ﬁxed-sized data entries the circular buffer holds. This amount is tuned according to the rate that data is placed into the buffer. In this way, developers control how much history the buffer stores. The TDR_ThreadAddIdentity() and TDR_ThreadRemoveIdentity() functions are used in a heavyweight tasking environment, such as Linux. In this case, multiple threads in a process may share the same capture buffer. These functions allow each thread to associate a string with the entries it makes. The TDR_Store() function is used to store the data into the circular buffer. The module_ID indicates the component of the software that stores the data. The entry_ID uniquely identiﬁes the format of the data placed into the buffer. The data itself is a ﬁxed-size entry that the caller formats as desired. The entry_ID is used by software tools to parse the entry when encountered in a dump. The implementation of the TDR_ Store() function is critical. The application software must call the TDR library as part of normal execution so that the data is always available if a problem occurs. As a result, TDR_Store() is called many hundreds of times per second. Because it’s called so often, the function must execute quickly. Ideally, it should execute in fast, constant time and not make any system calls that can block the caller’s execution. In addition, the library should avoid mutual exclusion primitives that can cause unrelated execution contexts to serialize as they 32 AUGUST – SEPTEMBER 2007 | embedded systems design europe | www.embedded.com/europe 030-031-032-033-034-035_ESDE.ind32 32 5/09/07 12:31:37 http://www.embedded.com/europe

Table of Contents Feed for the Digital Edition of Embedded Systems Design - Europe - August/September 2007

Contents News Cover Feature: Annual Study Uncovers the Embedded Market DSP Serves the Convergence Needs of Small Business Embedded Test Offers Unique Value for Serial I/O The Software Detective: First-Fault Data Capture Boards May Shrink But Performance Doesn't New Products Advertising Contacts

Embedded Systems Design - Europe - August/September 2007

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.