Error log design...

[s.subbarayan]

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

 

[Neo]

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

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.
-Neo

 

[Richard H.]

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.

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.)

 

[Stephen Maudsley]

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.)

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

 

[Richard H.]

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

Z??

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.

 

[Bill Pringlemeir]

Z??

Terse version, "http://www.afm.sbu.ac.uk/z/".

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
"http://www.tendra.org/".

Fwiw,
Bill Pringlemeir.

 

[Gerald Bonnstetter]

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.

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.