Debugging using memory prints

For some types of debugging information and for some types of memory, yes of course.

For your specific case, with your specific debugging requirements and specific memory configuration? Not sure. Our psychic mind-reader has stepped out to lunch.

Of course you can write diagnostic log information into memory rather than dumping it out a port immediately.

That would be a definite maybe/depends. I have used some memory emulators that have the ability to examine their contents in real time, so you could set up a fixed buffer location and do the equivalent of sprintf() to the buffer. I'm not advocating any particular tool, but I have used/still use the older version of this :

am

and

memory.

We are trying to make changes to a USB Driver on an intelmote2 device. This has about 32MB of flash, 32 MB of SRAM. The problem is while using JTAG/OpenOCD to debug for some reason after the usb initialization, the debugger stops.

i was thinking, if i could write a printf function which could write to locations in memory. which i can then trace through, it might be helpful.

i am looking for more of a software solution to this problem.

Is this possible ? Could i write this with simple assembly language ? Or if there is a better solution to this problem, i am all ears.

Thanks Nived

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

Having been round this loop it is possible, but difficult.

Flash is a problem because if the HW crashes before the write is completed the data will be corrupt and useless.

Memory is OK provided that you can assess it after a crash. Often the characteristics of the hardware will mean that ram is cleared at a crash so any data that you've saved will be lost.

And even if you do save it, IME debussing a program using crash data is dozens of times harder than other technique, so really is a last resort. Can you not debug another way?

tim

nived skrev:

Is this not an excellent application for a logic analyzer? Instead of writing trace data to memory. you write to one or more fixed memory locations, which triggers the analyzer.

Is the debugger stopping, but the system is still running? If the debugger is stopped, how would you trace through the memory? How granular can you write the flash, and how fast? MAYBE, you could set up a static, uninitalized, buffer in RAM and after the debugger locks up, do a manual reset, not a power cycle, and look at the memory then. The contents should be intact, IF you aren't suffering from some errant code that is trashing them RAM.

is

if

Yes, the old fashion way: serial port.

Op Mon, 13 Sep 2010 20:18:27 +0200 schreef nived :

Perhaps the USB init changes the core clock rate, causing the emulator to lose the JTAG connection? If your emulator supports hot attach, you can try attaching after USB init. Otherwise get a proper emulator that doesn't "stop".

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