Error Logging

Greetings,

I want to add error logging to a system. Due to space restrictions I can only log binary messages, say 1 byte for the error code and a variable number of bytes for the payload.

Is there an example out there of such a system? The messages need to be buffered as the log messages would come from time critical routines, and then read out by a low priority task & written to Flash.

TIA

Reply to
celephicus
Loading thread data ...

That's the way we do that in our RTOS. Any task could write a message to common FIFO list. Message coud be an object of any kind. When message is written to FIFO, task id and time stamp added to it automatically. Dedicated low priority task reads from FIFO and writes to log file. The file is clipped to max. length. The events of FIFO overflow are recorded also.

Vladimir Vassilevsky DSP and Mixed Signal Consultant

formatting link

Reply to
Vladimir Vassilevsky

n

nd

ile

Thanks Vladimir, at least I know that I am on the right track. The FIFO has to be able to handle overwrites in the occasional case where the reader ca nnot keep up with the data. I was thinking of including an auto-incrementin g sequence number with every message, so that if messages were dropped the fact would be apparent as there would be a jump in the sequence numbers.

Reply to
celephicus

Just as a suggestion, perhaps you should drop data instead of overwriting existing data when the FIFO is full.

I've found that recording the start of a set of errors instead of the end of a set of errors usually helps me identify the triggering event for the errors more easily.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP 
Microsoft: Bringing you 1980s technology to a 21st century world
Reply to
Simon Clubley

I've done something similar in the past to log input and output data for a particular task (that I was responsible for) within an embedded system. I had a small buffer that would be periodically flushed when reasonable, appending to a log in a filesystem (it wasn't until the advent of an onboard sort of general-purpose filesystem that this became feasible).

The end result logged days/weeks of data that until then were somewhat theoretical, and being able to record the progress of the system *in real-world use* was a real eye-opener. Whenever a problem was reported, I'd send instructions of how to enable the logging and get a log back in return that told me everything I needed to know. It reduced the ambiguity to zero, and cut the number of problems (typically misconfigurations by a given product team) that ended up shipping in the final product to a tiny fraction of what they were.

Fun times. Anyway...

I'd definitely second this for an error log. For other types of logging, perhaps not so much, but I've also found that it's often more instructive to see where an error began rather than to see the tail end of all the fallout.

It's also far simpler to just stop adding records to a buffer and record that an overrun occurred than to maintain a circular buffer and have to worry about overwriting records at the head of the list.

Besides, this is a last-ditch fail-safe operation. In reality, you'll probably end up selecting a buffer size that won't overflow under normal (or even most abnormal) circumstances.

--------------------------------------- Posted through

formatting link

Reply to
Smeghead

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.