|
Software developers will sometimes notice a variable has an unbelievable value. In a debugging situation, the value is checked right after it is written, and the value is good. If every place it is written is checked, then it appears as though somehow the variable value is changing not as a result of intentional C code. This application note covers some basic techniques to locate the problem.
1. The first step is to open the .SYM file and locate the variable in question. This memory map shows where the variable sits in relation to other variables. The compiler will share the same memory location between variables that should not be active at the same time. For example, the main program calls function A and it calls function B. The A function has a local variable called LA and B has a local called LB. Because function A and function B are not running at the same time, the compiler might put LA and LB in the same memory location.
Check the other variables in the same memory location and confirm those variables are not active at the same time. Remember that local variables that are not marked static may have garbage in them each time the function starts. In the rare case the compiler places two variables that could be active at the same time in the same memory location report it to CCS Support.
2. Check nearby variables, especially arrays. An index out of range could cause accessing the array to overwrite another variable. If re-arranging your variables or otherwise changing the code makes a problem come and go, then look at how your problem variable moves in the memory map.
3. Look at the wrong data and see if you recognize it as belonging somewhere else. A bad pointer could place good data in the wrong location.
4. If this is a multi-byte data item and it is accessed inside and outside a interrupt function, then make sure your code logic has protection against the variable being partially updated when an interrupt happens.
5. Check the chip errata. Sometimes chips have bad behavior at certain voltages, temperatures or clock speeds.
6. Check to see if your chip allows for data breakpoints. If so, and your application is debugger capable, you should be able to find the problem using the debugger. Set a data breakpoint at the location of the problem variable. Run the program and each time it breaks, check the variable value. When it is bad, look to see where in the code you are. If you see something like the following:
buffer[bptr] = c;
Then it would seem bptr is out of range. Remember that in C, a ten byte array can not have an index over 9.
7. If none of the above solves the problem, you will need to roll up your sleeves and debug the problem more manually. To start, you need some way to identify the variable as being bad. Say the variable is temp and for now the expected value is over 68. When it is bad, it seems to be 0.
A. Write a function something like this:
char diag_tag=' ';
void check(char tag) {
if(temp<68)
if(diag_tag!=' ')
diag_tag=tag;
B. Add throughout your code in places where temp should be valid (the start of main would probably not be such a place unless you init temp to say 68) the following:
check('A');
In each place change the letter (B, C,...) so each call is unique.
C. Run the code and after the variable goes bad check diag_tag to find out where it was first discovered. You will need some way to output diag_tag if you are not using the debugger.
When the location of first error is found, look back in the code execution path to find where check() was previously called (a good call). Then add more check calls between those two points.
D. Repeat step C until you locate the line that causes the variable corruption.
Like us on Facebook. Follow us on Twitter.
About CCS:
CCS is a leading worldwide supplier of embedded software development tools that enable companies to develop premium products based on Microchip PIC® MCU and dsPIC® DSC devices. Complete proven tool chains from CCS include a code optimizing C compiler, application specific hardware platforms and software development kits. CCS' products accelerate development of energy saving industrial automation, wireless and wired communication, automotive, medical device and consumer product applications. Established in 1992, CCS is a Microchip Premier 3rd Party Partner. For more information, please visit https://www.ccsinfo.com.
PIC® MCU, MPLAB® IDE, MPLAB® ICD2, MPLAB® ICD3 and dsPIC® are registered trademarks of Microchip Technology Inc. in the U.S. and other countries.
|
