 |
 |
| View previous topic :: View next topic |
| Author |
Message |
russk2txb
Joined: 30 Mar 2008
Posts: 109
Location: New Jersey
|
| compiler woes |
 Posted: Wed Feb 17, 2010 12:20 pm |
 |
|
These tools are slowly driving me nuts! It seems that every time I try to do something even slightly advanced, either the compiler or the debugger or both cannot cope with it. Today it was this:
| Code: |
int CI [5][3];
int i, *ci;
memset (CI, 0xff, sizeof (CI));
ci = &CI [0];
for (i=0; i < 3; ++i)
ci [i] = 0;
|
The above fails miserably. First off, I use the memset so I can look at ram and figure out where CI is, because using eval to show &CI shows a completely bogus address. Note that CI is a global variable, but i and ci are local.
So then I can look at ram and see if the zeros got put in memory at the right place. Nope. I have no idea where the compiler is writing to. If I do:
| Code: |
char buf [64];
fprintf (buf, "%x, %x, %x", ci [0], ci [1], ci [2]);
|
buf will show completely random values. If I ask for eval of CI[0][0] it says "too many subscripts", huh?
Here is another problem:
| Code: |
typedef struct {
int Wcr [4];
int Reg [4];
} PotData;
PotData ePot [4];
PotData *Pd;
Pd = &ePot [0];
|
The debugger cannot show me the values or addresses of ePot or one of it's subscripts, and it cannot show me the values of the elements that Pd is pointing to. It tries, but the values and addresses are always wrong. Mouse-over evaluation also fails. However in this case the compiler actually gets it right and the code does work. But when the debugger fails it causes me to waste unbelievable amounts of time trying to figure out what is wrong when fixing a simple bug.
I hate to complain but I have been buying new compiler subscriptions periodically for years and I would think the tools would be mature by now. My subscription is now expired and I am not sure it is worth my money to renew it to get the latest compiler and then be disappointed again. My compiler version is 4.083.
Russ |
|
 |
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Wed Feb 17, 2010 12:27 pm |
|
|
What's your PIC ?
Are you using CCS debugger and IDE, or are you using Microchip tools ? |
|
|
russk2txb
Joined: 30 Mar 2008
Posts: 109
Location: New Jersey
|
| compiler woes |
| Posted: Wed Feb 17, 2010 1:39 pm |
|
|
Sorry, I am using the CCS compiler and debugger (PCWH) with ICD-U. The chip is the 18F6723.
Russ |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Wed Feb 17, 2010 2:33 pm |
|
|
| Quote: | | First off, I use the memset so I can look at ram and figure out where CI |
You can do that by looking at the .SYM file.
Or use a printf statement.
| Code: | | printf("%lx \r", CI); |
or load it into a temp variable and look at the temp:
| Code: |
int16 temp;
temp = CI;
|
or you can #locate it, so you know its address:
| Code: |
int8 CI[5][3];
#locate CI = 0x200
|
|
|
|
Wayne_
Joined: 10 Oct 2007
Posts: 681
|
|
| Posted: Thu Feb 18, 2010 2:34 am |
|
|
From the help:-
| Code: |
Compilation mode selection-
The #device directive supports compilation mode selection. The valid keywords are CCS2, CCS3, CCS4 and ANSI. The default mode is CCS4. For the CCS4 and ANSI mode, the compiler uses the default fuse settings NOLVP, PUT for chips with these fuses. The NOWDT fuse is default if no call is made to restart_wdt().
CCS4
This is the default compilation mode. The pointer size in this mode for PCM and PCH is set to *=16 if the part has RAM over 0FF.
ANSI
Default data type is SIGNED all other modes default is UNSIGNED. Compilation is case sensitive, all other modes are case insensitive. Pointer size is set to *=16 if the part has RAM over 0FF.
CCS2 CCS3
var16 = NegConst8 is compiled as: var16 = NegConst8 & 0xff (no sign extension)Pointer size is set to *=8 for PCM and PCH and *=5 for PCB. The overload keyword is required.
CCS2 only
The default #device ADC is set to the resolution of the part, all other modes default to 8.
onebit = eightbits is compiled as onebit = (eightbits != 0)
All other modes compile as: onebit = (eightbits & 1)
|
Note, the compiler is NOT case sensitive unles you specify #device ANSI.
As you have not shown this in your code I will assume you have not so CI is the same as ci. |
|
|
russk2txb
Joined: 30 Mar 2008
Posts: 109
Location: New Jersey
|
|
| Posted: Thu Feb 18, 2010 5:49 pm |
|
|
Thanks, I was beginning to realize that. I have always known that you can use upper as well as lower case for system functions, but for some reason I was blind to the fact that the same would be true for user functions and variables. DUH! Probably it is because I very rarely use variables with same name and different case.
Anyway I did change to using different names and it did clear up some of the issues. In fact the code does work now, but the debugger still has many issues with the constructs I use. I stopped trying to use the two dimensional array and instead did this:
| Code: | typedef struct {
int adr;
int cmd;
int dat;
int bNew;
} MsgData;
MsgData Msgs [5];
|
Now if I declare a pointer to MsgData I can use the pointer to address an individual element of the array:
| Code: |
MsgData *pMsg;
pMsg = &Msgs [0];
pMsg->adr = 0;
|
But the debugger has no clue. It cannot show me the contents of pMsg, or even pMsg->adr. This makes it hard to debug. There are lots of other issues with the debugger. For instance if I happen to put the cursor over a word that is part of a comment, often the debugger will attempt to show me the value of the word. Then, sometimes, an error message will pop up, telling me that it was unable to read memory. Sometimes the debugger and the whole GIU will simply close, or start exhibiting strange behaviour.
If there is a bug in my program that causes it to stop responding to serial comm, I can tell the debugger to stop (break). But usually it does not show me the location of the code that was being executed - rather the cursor is placed at the top of the source page and nothing but a reset will get the program started again.
Here's another thing:
| Code: |
enum DacChannels { CH1_GAIN, CH2_TCOMP, CH3_PHASE, CH4_MAG, CH_MAX };
|
If I place the cursor over any enumeration the debugger attempts to show me the value. In this example I get 108, 10, 0, 0, and 0 !!!
I could go on and on, but I am wondering; Are there any better tools available for this kind of development?
Thanks, Russ |
|
|
Wayne_
Joined: 10 Oct 2007
Posts: 681
|
|
| Posted: Fri Feb 19, 2010 2:43 am |
|
|
You have to be aware of some of the debugger issues, one you mave mentioned is that if you stop the code the debugger doesnt show the correct code.
This is because you have stopped in a built in library function (printf etc) which there is no source code for. You need to switch to ASM mode and step through it or figure out where the call was made in your c via the call stack and place a break point. You can then run your code and it will stop at a more appropriate location. |
|
|
russk2txb
Joined: 30 Mar 2008
Posts: 109
Location: New Jersey
|
|
| Posted: Fri Feb 19, 2010 7:33 am |
|
|
Ok, I will try that. But the debugger should be able to automatically switch to assembly mode and show me my current PC location as well as a list of calls that were made to get there from my own code. At the very least it should show me the location of the call that I made to get into the system function. Showing the program counter as at the top of the source file is totally uninformative.
I hope that CCS personnel are reading this and taking notes. I have tried sending them bug reports in their official channel before with very poor results. Usually they say they are reviewing my submission and then I never hear from them again. I have even emailed them back to ask why no response but never received a reply from my email.
Russ |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
