Debugging using memory prints

Hi Nived,

nived wrote:
> I am faced with a problem of not being able to effectively debug what i am
> doing.
> 
> Is it possible to save debug information at locations in memory/flash and
> then examine them later ?
> 
> Instead of say printing to the console, printing to locations in memory.

Yes.

I implement a "Black Box" function in most of my designs
(so named after the notorious "black box flight recorders").

The API is simple -- just push bytes *into* it (via a printf,
cdevsw entry, etc.) as it is a true WOM from the application's
perspective.

To the application, this looks like /dev/null -- fast write times,
infinite capacity, etc.

In practice, it can take many forms.  In your case, malloc() a
block of memory and treat it as a FIFO "wired" to a printf(),
cdevsw entry, etc.  (i.e., something that will source bytes to it).
You can adjust the size of the FIFO (you will, sooner or later,
complain that it isn't "deep enough" so you want to be able to
easily enlarge it) as your needs vary (i.e., in production
code, you can set the size of the FIFO to '0' and leave the
function calls in situ).

The simple API is a win as you can embed it in your various
libraries and just tweak the implementation of the *actual* BB
(e.g., in some cases, I wire the BB to a network port so the
data just streams out to an external logger).

Think about the interaction of the BB with the rest of your
system, though.  E.g., if your system can *crash* (e.g., "HALT")
then you want to change the *implementation* of the BB so that
it ensures the most recent (and potentially most *important*)
information is actually "preserved" somewhere before the BB write
returns to its caller.  (of course, if something *else* can
asynchronously crash the system while the BB is performing its
function, then you're still screwed).

You can also change the implementation of the BB so that it
just pushes the data out to some pins that you can hang a
scope probe (or logic analyzer pod) on.  Decades ago, we used
such "scope loops" to debug embedded systems without encumbering
them with superfluous I/O.

The key issue is to use a simple API that you can hide implementation
details behind so you don't hesitate to *freely* use it in your
design -- then cut its cost "in production" by simply changing the
implementation (without having to rewrite a bunch of code, etc.).

Do yourself a favor and support multiple BB's so you can selectively
decide what you want to examine.

Also, think about anything that you consider pertinent to *every*
BB access.  E.g., I log the ID of the "task" invoking it, the
current system time, the address from which the access was made, etc.
You can embed all of this overhead *inside* the BB interface so
your "application" doesn't need to bother with it -- and so *you*
don't have to remember to *supply* it in each invocation!

--don