Looks like CW V9 is the only reasonable game in town. With older CW or PalmDebugger you need a serial cable with a universal connector. Do not use a Y cable with both USB and serial connectors. The Y cable works for hot sync, but really confuses any debugging traffic. If you have to reset the Tungsten, the Y cable serial connector causes it to hang. The serial (only) cable works fine.
At the assembly level with PalmDebugger, there is a bizarre error such that the second instruction following a JSR or TRAP is skipped over by the debugger. The instruction is executed, but you can't single step into or breakpoint on it. So single stepping has these holes in the trace. What I've done for my own code is to add assembler NOP instructions in the skipped areas so I don't have to think about the invisible areas. For code you don't control, just be aware of what is happening and do lots of disassembly after skipping over a JSR/BSR/TRAP. At the C/C++ level with CW before V9, I'll bet it just blows on past any breakpoints that happen to end up on the second machine instruction past a JSR/BSR/TRAP. As Ben says, the problem is in the debugger nub on the Tungsten. The effect will show up with CW debugger, PalmDebugger, GDB, or any other debugger that communicates with the Tungsten debugger nub. -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
