Code Debugging Tips

g3cwi

At the moment I am coding using the Propellor Tool. That's quite basic but mostly work (it does crash sometimes). I have been using PST or the "Simple Debug" Object. I find these a little annoying in that the serial terminal seems to need to be started manually each time. The whole debugging support seems a bit ad-hoc and the Propellor Tool is not a very comprehensive "IDE" unless I am using it incorrectly.

What tools do the gathered experts recommend for debugging code: important note - I am new to this! I am aware of BST and Viewport but have not used either in anger.

Regards

Richard

Leon

SPAD works quite well for debugging assembler programs. I do miss a proper debugger like those available with other MCUs.

ratronic

g3cwi in the Spin tool after you hit F10/F11 and the program finishes loading you can hit F12 to start the Parallax serial terminal.

Phil Pilgrim (PhiPi)

And after you hit F10/F11 and F12, hit Enter right away. That will Enable the PST screen before the load is complete. If you're using the Parallax Serial Terminal" object to output your debug data, it will clear the screen first, so you don't have to do that manually or insert code to do it.

My command sequence for rapid code testing is: F10 F12 Enter. Oh, and don't close the PST screen. Just leave it open. Also, if you've loaded your program into EEPROM, you can reboot just by checking, then unchecking the DTR box. (It'd be nice if there were a "Reset" button in PST that performed this sequence automatically.)

-Phil

SRLM

I program on Linux using a standard text editor (Gedit, with a custom language highlighting for Spin/PASM), and then a custom script.

The script will try to compile the code, and if successful download it to the Propeller, and if successful automatically start up a serial terminal. If at any point it can't do something it aborts with an error. All this, with a single key stroke.

#!/bin/bash

#(c)2012 Anzhelka Project
#This script will compile, download, and open a terminal
#If any errors are encountered then it will stop at the appropriate point.

#Meant to be run from the /spin directory, aka
#  $> tool/template.sh

echo
echo

bstc.linux -f -p0 -L lib  src/template.spin > output.txt
cat output.txt

grep -q "Error" output.txt
if [ $? -eq 0 ]; then
   echo Found Error!
else
   echo ----------------------------------------------------------
   echo No compiler errors...
   
   grep -q "No Propeller detected on" output.txt
   if [ $? -eq 0 ]; then
      echo Could not find Propeller chip...
   else
   
      echo
      echo
      echo To exit picocom, type C-A the C-X
      echo
   
      picocom -b 115200 /dev/ttyUSB0
   fi
fi

rm output.txt

For the most part, I've found terminal debugging to be sufficient. I've done development of C++ and Java on a workstation before, and usually find myself being able to debug better using a terminal anyway than doing things like breakpoints and profiling. Terminal debugging usually gives a better picture of program flow than stepping through a program IMHO.

You can also do debugging through LEDs attached to IO pins (especially useful for PASM). I've used Ariba's PASD debugger before and I like it (except for not cross platform!), and there's also Jazzed's debugger.

As a side note, if you use BST (cross platform IDE for Propeller) it will automatically manage the serial port so you don't have to worry about multiple things hanging on the COM port.

SRLM

Note that you can also use hardware debuggers here. Some form of signal reader is usually appropriate, either an oscilliscope or one of those fancy USB devices that will automatically parse a protocol live over a wire. I'd like to get the Salae Logic16 sometime when I can afford it. It has an FPGA inside! You can also try your hand at an open source FPGA based logic analyzer (like this one).