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

Op Mon, 13 Sep 2010 20:18:27 +0200 schreef nived  
<nivedks@n_o_s_p_a_m.gmail.com>:
>> In article <RY-dnd_Fs8EK3RPRnZ2dnUVZ_tmdnZ2d@giganews.com>,
>> nivedks@n_o_s_p_a_m.gmail.com says...
>>> I am faced with a problem of not being able to effectively debug what i
>>> am doing.
>>>
>
> 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.

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



-- 
Gemaakt met Opera's revolutionaire e-mailprogramma:  
http://www.opera.com/mail/
(remove the obvious prefix to reply by mail)

On Sep 13, 11:18=A0am, "nived" <nivedks@n_o_s_p_a_m.gmail.com> wrote:
> >In article <RY-dnd_Fs8EK3RPRnZ2dnUVZ_tmdn...@giganews.com>,
> >nivedks@n_o_s_p_a_m.gmail.com says...
> >> Hi,
>
> >> 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.
>
> >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. =A0
> >I'm not advocating any particular tool, but I have used/still use the
> >older version of this :
> >http://www.tech-tools.com/fr3.htm
> >and have done pretty much what you want to do.
>
> We are trying to make changes to a USB Driver on an intelmote2 device. Th=
is
> 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.

Yes, the old fashion way: serial port.

In article <-_6dnY_8NKZu9xPRnZ2dnUVZ_t2dnZ2d@giganews.com>, 
nivedks@n_o_s_p_a_m.gmail.com says...
> >In article <RY-dnd_Fs8EK3RPRnZ2dnUVZ_tmdnZ2d@giganews.com>, 
> >nivedks@n_o_s_p_a_m.gmail.com says...
> >> Hi,
> >> 
> >> 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.
> >
> >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 :
> >http://www.tech-tools.com/fr3.htm
> >and have done pretty much what you want to do.
> >
> >
> 
> 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. 

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.

nived skrev:
>> In article <RY-dnd_Fs8EK3RPRnZ2dnUVZ_tmdnZ2d@giganews.com>, 
>> nivedks@n_o_s_p_a_m.gmail.com says...
>>> Hi,
>>>
>>> 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.
>> 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 :
>> http://www.tech-tools.com/fr3.htm
>> and have done pretty much what you want to do.
>>
>>
> 
> 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 http://www.EmbeddedRelated.com

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.


-- 
Best Regards
Ulf Samuelsson
These are my own personal opinions, which may
or may not be shared by my employer Atmel Nordic AB

"nived" <nivedks@n_o_s_p_a_m.gmail.com> wrote in message 
news:RY-dnd_Fs8EK3RPRnZ2dnUVZ_tmdnZ2d@giganews.com...
> Hi,
>
> 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 ?

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

>In article <RY-dnd_Fs8EK3RPRnZ2dnUVZ_tmdnZ2d@giganews.com>, 
>nivedks@n_o_s_p_a_m.gmail.com says...
>> Hi,
>> 
>> 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.
>
>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 :
>http://www.tech-tools.com/fr3.htm
>and have done pretty much what you want to do.
>
>

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 http://www.EmbeddedRelated.com

In article <RY-dnd_Fs8EK3RPRnZ2dnUVZ_tmdnZ2d@giganews.com>, 
nivedks@n_o_s_p_a_m.gmail.com says...
> Hi,
> 
> 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.

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 :
http://www.tech-tools.com/fr3.htm
and have done pretty much what you want to do.

On Sep 13, 11:17=A0am, "nived" <nivedks@n_o_s_p_a_m.gmail.com> wrote:

> Is it possible to save debug information at locations in memory/flash and
> then examine them later ?

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

On Mon, 13 Sep 2010 10:17:43 -0500, "nived"
<nivedks@n_o_s_p_a_m.gmail.com> wrote:

>Hi,
>
>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.

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.

-- 
Rich Webb     Norfolk, VA