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