Tuesday, March 22, 2011


Realizing that defects are very common (and almost unavoidable) in software, I try to choose the most convenient debug environments. For example, if I have a choice between debugging code using Visual Studio's debugger or using print statements on the GP2X, I will choose the former every time. It is a lot more powerful and takes a lot less time to find problems.

Well, I failed to foresee a potential issue this morning. I "lugged" my STK600 and breadboard, along with my laptop, out to my garage and hooked it up to my Dragon's Lair. It was a few minutes later that I discovered that serial port communication from the STK600 and my "garage PC" was not working at all. So I fired up minicom and saw that the serial communication worked within minicom so I knew the serial port was good and the STK600 was working properly. That meant that the bug was in _my_ code somewhere. I started debugging, but it was so cold out in the garage that my fingers eventually froze up and refused to function.

So I had to make the disappointing journey back inside to debug this serial port issue in a warmer environment. I'll try the garage thing again tomorrow.

UPDATE: Looks like the problem was that I was doing this:

unsigned char baud_symbol = 0;
baud_symbol = B115200;

which was throwing this warning:

warning: large integer implicitly truncated to unsigned type

but I couldn't see the warning because I was running the entire build process using "make". It wasn't until I wrote a little test app that I saw the warning. I guess this is a lesson to make warnings fail the build :(

The fix was to change it to this:

unsigned int baud_symbol = 0;
baud_symbol = B115200;

No comments:

Post a Comment