On Wed, Dec 1, 2010 at 4:43 AM, wasif masood <[email protected]> wrote:
> > > Thanks Eric for this detailed reply. What I figure out using Printf for > debugging is that, its not that straight forward. One can use printf to get > an idea where the code get stucked but in some cases, since printf uses > buffer it might be possible that the code gets through a particular break > point but one cant see anything on console since the buffer is not yet > flushed(even if you use printfflush() with every printf). > That is correct. There is pretty significant time skew using printf. You might be better served using tracing (you'll have to design it) and then dumping the trace buffer. I use jtag and stop the machine so I can poke around. eric > Thanks. > > > On Wed, Dec 1, 2010 at 1:58 AM, Eric Decker <[email protected]> wrote: > >> >> >> On Tue, Nov 30, 2010 at 3:04 PM, wasif masood <[email protected]> wrote: >> >>> >>> any other way to check what is going on in my telosb RAM / ROM without >>> using JTAG? >>> >> >> Not really. >> >> Here is a brief review of the options.... >> >> Context: Motes are embeded systems. As such they don't have many of >> the resources and interfaces that we have come to expect from more capable >> computers. So debugging the computer programs that are embedded in these >> devices is something of a challenge. >> >> Basically we are trying to obtain some kind of state information from the >> device to get visibility into the function of the program. >> >> 1) If the h/w provides a signal of some kind (like the leds on the telosb) >> then you can put strategic code at various places to change the state of the >> LEDs. >> >> 2) If the h/w provides a serial port, then one can implement printf and >> spew debugging information out that port. There is significant timing skew >> when doing this because serial ports typically run significantly slower than >> the processor or other h/w bits. >> >> 3) one can implement some form of logging. That is one instruments the >> function of the code by writing information into ram or some other kind of >> storage that one can then look at after running the code for some amount of >> time. >> >> 4) in circuit emulation. That lets you stop stuff and look around. >> This stops the h/w. This is implemented on the MSP430 by the JTAG which is >> actually a h/w interface mechanism for scan chains which got invented as we >> kept shinking integrated circuits. We used to use really kick ass logic >> analyzers but alas no longer. There are remote mechanisms for interfacing >> the JTAG h/w to GDB so one can do source level debugging remotely. It's >> pretty nice. But you need a JTAG and all the interconnect has to work to >> allow gdb running on the development system to talk to the device down on >> the embedded system. >> >> In other words.... "Not really" >> >> TANSTAAFL... There Ain't No Such Thing As A Free Lunch. >> >> >> eric >> >> >> >>> >>> On Tue, Nov 30, 2010 at 11:54 PM, Eric Decker <[email protected]> wrote: >>> >>>> >>>> >>>> On Tue, Nov 30, 2010 at 2:09 PM, wasif masood <[email protected]>wrote: >>>> >>>>> >>>>> Actually, I am using Printfs everywhere but the thing is that sometimes >>>>> my code reaches to a particular Printf and sometimes it just don't (may be >>>>> halt somewhere). Printf is what I think, also a hit an trial approach, I >>>>> know by that I can narrow down the problem but it might take some time, I >>>>> was kind of thinking is there any appropriate way to do that. >>>>> I once raised the similar question sometime ago on this forum, got the >>>>> recommendation of using gdb. >>>>> >>>> >>>> Not sure what the context was for this recommendation. >>>> >>>> >>>>> I am not that familiar with linux tools, so my question is that: can I >>>>> use gdb to debug my necC generated code for telosb on my PC(as I dont have >>>>> any JTAG device)? >>>>> >>>> >>>> I don't know what kind of development environment you are using. I'm >>>> using the gnu mspgcc toolchain running on Linux. In that >>>> environment I have to use msp430-gdb to debug my msp430 code compiled >>>> using msp430-gcc (nesc invokes the appropriate compiler). >>>> >>>> If you invoke "gdb main.exe" it will use the native gdb to try to debug >>>> a msp430 main.exe. Doesn't work very well. >>>> >>>> And if you are using msp430-gdb you pretty much need to have a jtag for >>>> accessing the actual running code. >>>> >>>> >>>> >>>>> >>>>> What I am doing now is just compile the code with make telosb and then >>>>> run it using gdb as : >>>>> gdb main.exe >>>>> >run >>>>> but I got this error: >>>>> Starting program: /opt/tinyos-2.1.0/apps/Blink/build/telosb/main.exe >>>>> /bin/bash: /opt/tinyos-2.1.0/apps/Blink/build/telosb/main.exe: cannot >>>>> execute binary file >>>>> /bin/bash: /opt/tinyos-2.1.0/apps/Blink/build/telosb/main.exe: Success >>>>> During startup program exited with code 1. >>>>> >>>>> Is there a way out of that? >>>>> >>>>> >>>>> On Tue, Nov 30, 2010 at 9:59 PM, Eric Decker <[email protected]>wrote: >>>>> >>>>>> You mention using gdb... Are you trying to make use of a jtag pod >>>>>> to actually debug the code? >>>>>> >>>>>> If so I can help you get that running.... >>>>>> >>>>>> eric >>>>>> >>>>>> >>>>>> On Tue, Nov 30, 2010 at 7:10 AM, wasif masood <[email protected]>wrote: >>>>>> >>>>>>> >>>>>>> I am trying to use gdb, but when I compile using make telosb debug, >>>>>>> it give me vector overwrite error since my code is too big to fit with >>>>>>> debug >>>>>>> flag enable. Can anyone please give me a hint what else can be done. >>>>>>> >>>>>>> >>>>>>> On Tue, Nov 30, 2010 at 1:47 PM, wasif masood <[email protected]>wrote: >>>>>>> >>>>>>>> >>>>>>>> Hi All, >>>>>>>> >>>>>>>> Is there any way I can debug my actual telosb install file on my PC. >>>>>>>> I have written a code which is showing very strange behaviour, it >>>>>>>> seems that >>>>>>>> at some point during execution, the code just crashes. What could be >>>>>>>> the >>>>>>>> best option to check at which point my code gets corrupted. >>>>>>>> >>>>>>>> BR >>>>>>>> Wasif Masood >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Wasif Masood >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Tinyos-help mailing list >>>>>>> [email protected] >>>>>>> >>>>>>> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Eric B. Decker >>>>>> Senior (over 50 :-) Researcher >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Wasif Masood >>>>> >>>>> >>>>> _______________________________________________ >>>>> Tinyos-help mailing list >>>>> [email protected] >>>>> >>>>> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help >>>>> >>>> >>>> >>>> >>>> -- >>>> Eric B. Decker >>>> Senior (over 50 :-) Researcher >>>> >>>> >>>> >>> >>> >>> -- >>> Wasif Masood >>> >>> >>> _______________________________________________ >>> Tinyos-help mailing list >>> [email protected] >>> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help >>> >> >> >> >> -- >> Eric B. Decker >> Senior (over 50 :-) Researcher >> >> >> > > > -- > Wasif Masood > > > _______________________________________________ > Tinyos-help mailing list > [email protected] > https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help > -- Eric B. Decker Senior (over 50 :-) Researcher
_______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
