What is your favorite Open AT application debug way ?


#1

Hi all,

Please leave us some comment on the way you like to debug and fine tune your Open AT application.
Feel free to add comments to motivate your position.
This is an open forum to debate this aspect with you.

Debug way:
- Embedded Debugging: Using the firmware GDB agent and managing Start/Stop/Breakpoint
- Debug Traces: used to return specific values of variables at runtime
- RTE: Old fashion remote mode, Open AT Application is executed on the development environment (PC)
- JTAG Probe: currently available on WMP Series only
- Others: Please comments and/or provide suggestion

Christophe


#2

Voted “Others” in the means of terminal program. Dev studio had some annoying behavior of never keeping the last console used and constantly switching to something else so I had to make some terminal with xmodem capabilities and use it for all but compile. I have no idea if this got fixed recently, last I tried was 2.1. Otherwise my vote goes to traces as second option, given the async nature of the OS as a whole breakpoints are of little use, as you can’t really properly follow the program flow, maybe check what very small piece of code is doing, but thats all.


#3

Voted for “Others”, too.
Because I need be able to see debug output with standard terminal tools over serial or USB connection where no Developer Studio is isntalled.


#4

Would be nice with JTAG probe debugging on more products, but right now I’m using plain old custom serial debug output.
Occasionally also debug output through GPRS for cases where using UART or USB is not possible for various reasons.


#5

Hi,

Thanks for the open feedback, i appreciate the detailed comments, this is helpful.

Christophe


#6

Source level debugging is by far the most appreciated way of debugging, as apposed to serial debug printouts, led flashing with gpio’s etc. However, the embedded GDB server over USB does only work properly for small programs. When your code grows, and it eventually will, my experience is that the embedded GDB server fails, the target restarts and your debugging session is lost. Then its back to basic and the good old serial line again. Its really not what you’d expect when the calendar shows 2012 and the JTAG has been around since 1985.

I my (not) so humble opinion, this is a major design flaw in the Q and SL chips, and subsequently the FXT and GL series, that they don’t support JTAG debugging. Debugging is a tedious and time consuming task, and using serial printouts even more, and is fair to ask why Sierra have so little respect for the customers time and money since our do not facilitate what should have been the obvious choice of debugging.


#7

Well, I consider source level debugging preferable everywhere but SW modems, even if it worked reliable (which it didn’t when I tried it some time ago). For some reason the OS itself is designed to be painful to work with/debug - a simple logic - to execute several commands, check result and process the data that should take several lines of code actually span on pages of state machine type of code with callbacks all over the place. Debugging that with breakpoints is next to impossible, will need 10 of these for a simplest thing, so be 2012 or 2112, with the current implementation of the OS, traces or serial port output is the best bet.