Error log design...

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

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.

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.

Terse version, "

".

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 "

".

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"

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.