Wireless application debugging sessions are prone to analyzer capture buffer overruns and mountainous serial-based protocol unraveling.
Often this leaves engineers with the troublesome and time-consuming task of manually stitching together and decoding elaborate back-to-back captures to analyze the inner workings of a single user event. This article details how to simplify debugging and documenting wireless applications utilizing PC-based tools.
Wireless system-level interactions-based debugging captures often exceed the fixed length capture buffer capacities of traditional test equipment even for a seemingly simple application such as a wireless desktop mouse design.
Debugging even the most rudimentary functions—such as pairing two wireless devices initiated by a person pressing a button on the first device followed by pressing a button on the second device—can render traditional analyzers useless.
Inadequate sizing of an analyzer's capture buffer forces wireless engineers to take on the tedious task of manually stitching together back-to-back debugging captures. PC-based analyzers that can continuously stream capture buffer data into a PC's memory do more than simplify the mundane task of capturing data. They also greatly reduce the time required for post-processing and analyzing the data by eliminating undesirable stitching.
First-time viewers of lengthy streamed capture buffer sessions are often surprised to discover previously unobserved system-level interactions-based events that they had not been privy to with traditional test equipment.
Even when an entire debugging session can be captured in a continuous buffer, developers are still left with the tedious task of decoding mountains of serial-based protocol data. Decoding bit-for-bit and byte-for-byte, left as a human exercise, is error-prone and excessively time-consuming. Additionally, given the high speed of wireless interactions, the desired debugging events are typically buried somewhere in a long debugging data capture with huge voids of unrelated data between them.
Traditional wireless application debugging strategies such as selectively sprinkling printf debug statements throughout application code can ease some of these pains. However, they achieve this at the expense of incurring unwanted side-effects such as code bloat, code execution inconsistencies, and code obfuscation, as well as requiring additional hardware resources.
PC-based analyzers armed with flexible bus-level decoding facilities can greatly reduce cycle-to-cycle debugging time by effortlessly unraveling and accurately displaying large chunks of capture buffer data at the click of a mouse button. Figure 1 shows a typical PC debugging screen.
Click here for Figure 1
Figure 1: PCs have flexible bus-level decoding capabilities that can greatly reduce cycle-to-cycle debugging time.
Automating bus-level decoding is fast, efficient, and speeds resolution of complex system-level interactions-based wireless application bugs by allowing engineers to step away from what would otherwise be the boring task of bit-level decoding into event and results-driven debugging sessions. And, since all the details are readily available, debugging results can be explained in detail and clearly documented.
Traditional test equipment offers engineers a scanty supply of Save As facilities for post-processing and analyzing captured data. Routinely, these analyzers save their capture buffer data in proprietary formats, often resulting in the lost of vital debug information.
Habitually, engineers have been forced to spend many hours converting their saved capture buffer data into ASCII formats and imported into PC-based software for final post-processing and analysis.
PC-based analyzers natively save capture buffer data directly onto a computer's hard drive, easing the importation of information into spreadsheets such as Microsoft Excel for post-processing and data manipulation while maintaining the ability for anyone to access captured data in its original format using PC-based virtual instrumentation software.
This ease of transferring and transform data into different formats is quite useful since wireless application subject matter experts are often split across varying engineering disciplines—and location sites—and need to evaluate data in different ways.
Reducing analyzer-based captured data post-processing time also has the benefit of increasing the amount of time engineers can spend viewing and analyzing captured data.
Having the capability for anyone to play back known good system-level interactions-based capture buffer data and comparing its behavior to that of the debugging system's capture buffer data is an invaluable wireless application debugging tool.
Play back can also be used as a simple training tool for better understanding and documenting various wireless application interactions and dependencies that typically only occur in the field.
Debugging wireless applications in the field challenges even the brightest of engineers. Lugging bulky test equipment through the world's airports and shuttles burns life's most miserable set of memories onto one's brain.
Additionally, the ritual of having to reorganize one's test bench to accommodate the latest "debugging effort of the week" often exceeds the time it takes to actually capture the data.
PC-based analyzers designed to take advantage of a multitude of a PC's available resources are often small enough to use on an airplane's tray table, making it so that when debugging data offline, the sky really isn't the limit.
About the author
Troy Gentry is a Principal Applications Engineer for the Human Interface Devices group at Cypress Semiconductor. He can be reached at tge@cypress.com.
