Debugging using memory prints

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.

Thanks
- Nived	   
					
---------------------------------------		
Posted through http://www.EmbeddedRelated.com

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

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.

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.

>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

"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

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

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.

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.

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)