Here at Tech Support we get plenty of emails from customers asking for assistance with debugging their software. Although we do not have the resources to go through thousands of lines of code, we do try our best to help when possible. So, for this Ask Larry column, I thought I would impart some suggestions to help smooth out the development process.
Below are some suggestions to keep in mind during the software development process.
- Design your code well and test it often.
In developing your code you want to start with well-designed and well-commented code. Test any boundary conditions and special cases. Keep your functions as simple as possible and test them well. A good thing to have in your debugging arsenal is a suite of tests that you can use on subsequent code modifications. The more effort you put into this phase of software development the fewer problems you will have later on. - When a problem does arise, do not assume it is only hardware-related or only software-related. Keep your options open.
We have had customers who thought something was wrong with their code and it ended up being a custom power supply with a slow rise time or an issue with their motherboard or even noise on their inputs. You never know. - Use ALL your debugging tools.
When you do have a problem with your code, Dynamic C has a suite of debugging tools to help you isolate the issue. Some of these are: software/hardware breakpoints, single stepping, watch expressions, etc. See Chapter 6 of the DC User Manual (http://www.rabbit.com/products/dc/docs.shtml) for a full list of the debugging features of Dynamic C.
These are not your only tools, though. Printf() statements at strategic points in your code can pinpoint problems. You can attempt to isolate the issue by commenting out parts of your code. Dynamic C also has 10 virtual watchdogs which you can use in your code to help in debugging. For more information on virtual watchdogs see your DC User Manual at the above link.
Okay, I’ve written my code and now I have this intermittent problem. I don’t know what to do. My memory appears to be corrupted after a day...week...month!
Intermittent bugs that may or may not cause memory corruption are hard to find. Here are some tips when writing your code:
- Make sure your loops have the correct conditions when implemented, i.e. if you are using i = 0 to i < NUM(NUM is 50), and you are using this loop to initialize an array of 30 characters, this will cause trouble.
- Check return codes. Add error-checking statements in general, for instance:
rc = udp_send(socket, &n, sizeof(n));
if (rc < 0)
{
printf("Failed to send request to %s.\n", server_hosts[i]);
}
udp_send() returns -1 upon failure. The above code is checking for this. - Uninitialized pointers are a catastrophe waiting to happen! Here is a link to a previous Ask Larry article on pointers
http://www.rabbit.com/support/ask_larry/2008/0625.shtml. - Make sure you are not stuffing the wrong number of bits into a data type that can’t accept them. For instance, if your code is adding 0xFFFF to 0xFFFF and putting it into an int you will get bad results. In Dynamic C an integer is 16 bits. The result of the addition is 0x1FFFE, 17 bits. Make sure you are declaring your data type to be signed or unsigned as appropriate.
- For memory corruption errors specifically, you should be checking for uninitialized or incorrectly initialized pointers, buffer overflow, and/or stack overflow/underflow, but also check for environmental conditions that could affect the hardware, i.e. brownouts, faulty power supplies, etc.
Help, I still have a problem!
If all else fails, do not hesitate to contact our Tech Support personnel at support@rabbit.com.
- Larry C.
Larry Cicchinelli is Rabbit’s Technical Support Manager. He has 30 years of embedded experience, and is considered one of the foremost authorities on Rabbit products. Larry and his staff offer comprehensive technical support to Rabbit customers.
Submit your questions for Larry via email at AskLarry@rabbit.com
Read more Ask Larry Answers