| ??? 06/18/04 05:27 Read: times |
#72673 - RE: Error logging for purpose of Maintenance Responding to: ???'s previous message |
Dear James,
Hello, thank you very much for your reply indeed. There are many brilliant and informative answers in this thread including yours and I'm very sorry that I still don't have the right to vote :(. how about a circular queue, with timestamps only when necessary, to maximize depth of your error log? try to make the log as dense as possible. (it hurts when the error code you really want to see is just past the end of the log.) maybe two logs, one for high-priority stuff you want to keep as long as possible, the other for more detailed logs (that are going to get overwritten more often). Circular queues are great to find what exactly was the sequence of events but for my particular unit errors shouldn't happen too often ( or I certainly will be bankrupted:( ) and capturing the date of a particular failure should be enough ,I suppose. The most important information that such a log can give is the frequency of a particular error( it helps to find out what part of the unit has designed badly). It also gives an Idea what has happened to the unit before user brings it for service/repair(because it also captures the date). In the code I make it sure that it doesn't let the 2 bytes Error code counter to exceed 65000. if it has 65000 failure of a particular error code, it doesn't make any significant difference for example with 100000 or 1000000 failure anyway, it points out that there is a serious problem out there(just capturing the last error date is enough, I suppose). could use a C or assembler macro if your logging routine is small enough (like with C's assert()). Of course, defining a macro is a very good idea. and maybe two engineering units while developing; one with a large amount of RAM to hold detailed logs, the other matching the configuration to be released. or if the RAM is onboard the chip maybe you could just switch CPUs. nonvolatile log and nonvolatile timestamps preferred but make the unit more expensive (maybe reserve for the souped-up engineering unit and/or for some of the beta test units, if you don't consider that it will be too different from the final product). I don't understand what advantage using RAM may have over flash even in development phase? Why not using flash ? log the firmware version when booting. log a different log code on boot depending on if the log is empty or full, and another log code when boot is completed Very good idea in development phase. pick a start address for your log and stick with it throughout the lifecycle of the product (over different revisions). Excellent idea! To avoid misinterpretation of logging data in different versions. if you have a resident monitor you can use that to dump the error log as hex. users (beta testers if you want them to use a monitor and the target market is non-technical) provide the hex file and you make a tool to parse the hex. you can use shell scripts like gawk to parse the log (if using unix), or write a small C routine if not. this is separate from diagnostics reported to the user. if you have text output to the user (LCD screen, etc.), you can give them as much as you like. but targeted to the user, more info for beta testers, much less for market. and/or allow the user to toggle verbose output. Very Good ideas! (not applicable for this particular unit maybe but too valuable to forget!) Thank you very much indeed. |
