Error log design...

Dear all, I am currently working on a project where we are asked to display the error logs on the hyperterminal on the press of the key.Typically the log should collect all the error messages and if and only if the user presses a key on my H/W I will display it on the hyper terminal.Note that file system is not available to me,so writing to a file and printing it in a delayed manner is not possible in my case.

I need some inputs on how this log could be designed?what should be best data structure to store error logs?Typically the error logs collect info about corrupted memory regions when I run a memory test application over the memory chips like nvram,sdram,flash.

Having a linked list which will collect data was in my mind,but only fear for me is,having a linked list will occupy more memory,and in the worst case if I consider the entire range of memory to be corrupted and I need to display all the memory address along with some debug messages,my memory will bloat and I dont have enough memory for this.

So I need some inputs what could be the best design available for such an application?Note that I use C language and Vxworks OS.My test application runs from the boot code so none of the OS features are available to me,else I would have gone for vxworks LogMsg() call...

Advanced thanks for all your replys, Regards, s.subbarayan

Reply to
Loading thread data ...

Well, you can dedicate some region of memory for error log, if your processor has onchip memory that would be a better choice. Note - its based on the assumption that memory region is correct. While booting first perform memory tests like Program Memory Test, Data Memory Test (except the region reserved) and other integrity tests log the errors found. As far was data structures concerned for storing information, you can use simple fixed blocks for storing addresses like :

0x00001EFA 0x0012AFEB ..... each word will store address of faulty location. For diagnostics messages null terminated ASCII strings can be used. How you want to log faulty location, depends on your requirements like is it required to log each faulty locations address or the only the first location found bad and log_error() and abort().

#define PROGRAM_MEMORY 1 #define DATA_MEMORY 2

main() { ... initialization processor n other devices perform_program_memory_test(); perform_data_memory_test(); perform_flash_memory_test(); ... }

perform_program_memory_test() { .... perform memory test here if(error) { log_error(address, PROGRAM_MEMORY); }


log_error(UINT16 address, UINT16 region) { switch(region) { case PROGRAM_MEMORY: ..... write adderss and diagnostic string into fixed memory region. } abort(); }

abort() { while(1) { key = readkey(); if (key) { send_log_to_serial_port(); halt(); } watchdog_tick(); } }

Hope! you got an idea of how to implement it. But actual implentation depends on your processor, types of memories available etc. I do have implemented the same thing on my board but with slight variations to this scheme. As i have to redirect log messages to system controller module over HDLC channel rather than console.


Reply to

It seems the first problem is in the specs. I'd suggest that logging "all the errors" is not a valid requirement - there must be a finite limit, especially if the RAM you're testing must also be used for the log buffer. So, set this limit to a reasonable number of log entries, possibly with an option for full detail on-the-fly.

Perhaps... a) Capture a limited number of errors in buffer (assuming that beyond a point may be a "critical failure" anyway) b) Output the limited buffer when button is pressed c) Offer a "verbose" diag mode that generates the hyperterminal output on-the-fly as your tests are running, with all the detail you'd care to include. (For example, if button is held down when diags start; or button is pressed in the first 3 seconds after power-up, etc.)

Reply to
Richard H.

Can't see it - can you express that in Z.

Reply to
Stephen Maudsley


diags_start: if(button is depressed now) set verbose=1 while(diag running) if(error) if(buffer not full) write to buffer if(verbose) output error to serial port pace operation to prevent overrunning output buffer

later: event(button pressed) output buffer to serial port if(buffer full) notify user that NN errors were not logged

There are 2 problems to be addressed here, so solve them separately. If one assumes the buffer can be overrun regardless of its structure / size / efficiency (e.g., because all detail must be captured), then solve that problem first (above).

Once that problem is solved, it may simplify the second problem - how big the buffer should be, and how much effort should be spent to make it efficient.

Reply to
Richard H.

Terse version, "

formatting link

Apparently they wanted a formal definition. I wonder if anyone ever writes code in such a language. Z has been around for some time... I just found it yesterday when I was looking at Tendra "

formatting link

Fwiw, Bill Pringlemeir.

It's Not What You Know That Matters... It's Knowing What You Don't.  -
Hannu Poropudas.
 Click to see the full signature
Reply to
Bill Pringlemeir

I like the idea of a limit. He/she might also include a count of all the errors found, even the ones not saved.

I would also remove all the redundant text from the messages and replace it with an error code number. That code number would only need to be a byte or two long. And the error code would tell you how much data follows.

So "Single bit error at 0x004562" could store as 0x01 0x00 0x45 0x62 and "Multi bit errors form 0x001365 to 0x002366" could be 0x02 0x00 0x13

0x65 0x00 0x23 0x66. And so on... This data would be saved in your linked list or whatever you are using.

If you have more complex messages you may need to adjust the format used for message storage.

Reply to
Gerald Bonnstetter

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.