Global Sources
EE Times-Asia
Stay in touch with EE Times Asia
?
EE Times-Asia > Networks
?
?
Networks??

How to catch elusive bugs without using debugger

Posted: 16 Sep 2014 ?? ?Print Version ?Bookmark and Share

Keywords:software bugs? hardware debugger? Debugging? wireless sensor networks? GCC compiler?

An application disassembly listing is also required to recover the symbolic names and corresponding addresses of the functions. A disassembly listing can be obtained using the avr-objdump utility:

avr-objdump -d WSNDemo.elf > WSNDemo.txt

Now run the stack reversal script, providing disassembly listing and stack dump in either raw or Intel HEX format.

python avrstackrev.py -b -l WSNDemo.txt -s WSNDemo.dump

The output of this command should look like this:

0x0000cf: call to main() from .do_clear_bss_start()
0x000f8b: call to SYS_TaskHandler() from main()
0x0009c7: call to PHY_TaskHandler() from SYS_TaskHandler()
0x000207: call to PHY_DataInd() from PHY_TaskHandler()
0x0005b2: call to nwkFrameAlloc() from PHY_DataInd()

Each line of the output contains return address and information about decoded function calls. The first line corresponds to the first called function. Normally it will always be a call to main() from the low level initialisation code, and output that shows otherwise might be an indication of a corrupt or incomplete stack dump.

From this output we can see that execution has stopped in the function nwkFrameAlloc(), which gives enough information for close examination of this function by hand.

Problems whose nature is different from the implicit infinite loop can also be effectively debugged using a technique presented here. For example, let's consider an event driven system, where execution of the next step depends on the confirmation returned from the previous step. If confirmation is lost for some reason, the application itself will appear to be running as normal and will reset the watchdog timer periodically, which means that the problem will not be indicated by the presented method.

An application timer may be used to diagnose problems like this. The timer must be started at the time of requests and stopped in the confirmation handler. If the timer is not stopped in time, then the timer event handler should trigger the watchdog intentionally. The place where the watchdog timer was triggered will indicate the problem.

About the author
Alex Taradov is an applications engineer at Atmel Corporation working on low-power and low-data rate wireless networks software. Thanks to his father, he started learning about electronics at the age of six, eventually transforming his passion from electronics into programming. Alex is proficient in a variety of programming languages including Basic, Pascal, C, and Python. He graduated with an MSc from Bauman Moscow State Technical University in 2007, and since has written a variety of languages for a variety of systems, ranging from the tiniest microcontroller to desktop systems.

To download the PDF version of this article, click here.


?First Page?Previous Page 1???2???3



Article Comments - How to catch elusive bugs without us...
Comments:??
*? You can enter [0] more charecters.
*Verify code:
?
?
Webinars

Seminars

Visit Asia Webinars to learn about the latest in technology and get practical design tips.

?
?
Back to Top