Error log design...

Discussion in 'C Programming' started by s.subbarayan, Jan 4, 2005.

  1. s.subbarayan

    s.subbarayan Guest

    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
     
    s.subbarayan, Jan 4, 2005
    #1
    1. Advertising

  2. s.subbarayan

    Neo Guest

    "s.subbarayan" <> wrote in message
    news:...
    > 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
     
    Neo, Jan 4, 2005
    #2
    1. Advertising

  3. s.subbarayan

    Richard H. Guest

    "s.subbarayan" wrote:
    > 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.)
     
    Richard H., Jan 4, 2005
    #3
  4. Richard H. wrote:
    > "s.subbarayan" wrote:
    >
    >> 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.)


    Can't see it - can you express that in Z.
     
    Stephen Maudsley, Jan 4, 2005
    #4
  5. s.subbarayan

    Richard H. Guest

    Stephen Maudsley wrote:
    > 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.
     
    Richard H., Jan 4, 2005
    #5
  6. > Stephen Maudsley wrote:

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


    On 4 Jan 2005, wrote:

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

    --
    It's Not What You Know That Matters... It's Knowing What You Don't. -
    Hannu Poropudas.

    vxWorks FAQ, "http://www.xs4all.nl/~borkhuis/vxworks/vxworks.html"
     
    Bill Pringlemeir, Jan 4, 2005
    #6
  7. Richard H. wrote:

    > "s.subbarayan" wrote:
    >
    >> 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.


    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.


    > 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.)
     
    Gerald Bonnstetter, Jan 5, 2005
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Henrik_the_boss
    Replies:
    0
    Views:
    2,712
    Henrik_the_boss
    Nov 5, 2003
  2. Amratash
    Replies:
    0
    Views:
    559
    Amratash
    Apr 13, 2004
  3. =?Utf-8?B?VG9tIFdpbmdlcnQ=?=

    My.Log.Writeexception not writing to Application Event Log.

    =?Utf-8?B?VG9tIFdpbmdlcnQ=?=, Jan 20, 2006, in forum: ASP .Net
    Replies:
    0
    Views:
    2,413
    =?Utf-8?B?VG9tIFdpbmdlcnQ=?=
    Jan 20, 2006
  4. unomystEz
    Replies:
    0
    Views:
    585
    unomystEz
    Nov 19, 2006
  5. vj
    Replies:
    0
    Views:
    706
Loading...

Share This Page