some ideas ...

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

could use a C or assembler macro if your logging routine is small enough (like with C's assert()).

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

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.

pick a start address for your log and stick with it throughout the lifecycle of the product (over different revisions).

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.

james