 |
 |
| View previous topic :: View next topic |
| Author |
Message |
AHCCS
Joined: 10 Nov 2016
Posts: 10
|
| Compiler issue: Wrong value in variable |
 Posted: Mon Nov 14, 2016 1:57 am |
 |
|
Facing a strange issue with variable definition. I have two global unsigned int 8 variables (lsbEnc1 and lsbEnc2) both have same values but one of them skips the last bit (lsbEnc2) i.e. if I store 71 it will have a value of 70 (last bit is always zero).
| Code: |
pseudo code
#include <33EP256MU806.h>
#fuses NOWDT, PR_PLL,FRC_DIV_BY_16 // Internal FAST RC oscillator with 16x PLL
#use delay(crystal=12M,clock=120M)
#define StartByte '$' // start byte of each serial frame
#define EndByte1 '\r' // 2nd last byte of each serial frame
#define EndByte2 '\n' // last byte of each return serial frame
//pins for UART
#pin_select U1TX=PIN_E7
#pin_select U1RX=PIN_F3
#define UART_HW UART1
#use rs232(baud=115200,parity=N, ERRORS,UART1,stream=SerialGame)
unsigned int8 lsbEnc1=0; // variable 1
unsigned int8 lsbEnc2=0; // variable 2
void SerialTransmitframe(void);
void main()
{
setup_timer4(TMR_INTERNAL |TMR_DIV_BY_256, 234); //interrupt every 1ms prescalar
enable_interrupts(INT_TIMER4);
enable_interrupts(INTR_GLOBAL);
while(TRUE)
{
SerialTransmitframe();
}
}
void SerialTransmitframe()
{
lsbEnc1=71;
lsbEnc2=71;
fprintf(SerialGame,"%cHM,",StartByte);
fprintf(SerialGame,"%c",lsbEnc1); // prints 71
fprintf(SerialGame,",%c",lsbEnc2); // prints 70 (Wrong value)
putc(EndByte1);
putc(EndByte2);
}
|
Output is $HM,GF
Hope my question makes sense. I feel its a compiler issue or I am missing something really stupid
_________________
Novice User |
|
 |
AHCCS
Joined: 10 Nov 2016
Posts: 10
|
|
| Posted: Mon Nov 14, 2016 2:09 am |
|
|
I just checked if I remove the function and place everything in main it works but still not sure why its not working in the function.
_________________
Novice User |
|
|
AHCCS
Joined: 10 Nov 2016
Posts: 10
|
|
| Posted: Mon Nov 14, 2016 3:00 am |
|
|
Ok just to keep on updating. Seems like after a while again in main as well I face the same issue. The variable doesn't seem to store the correct value.
My guess is its some memory issue or compiler issue. Please any info of this will be very helpful.
_________________
Novice User |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19546
|
|
| Posted: Mon Nov 14, 2016 4:12 am |
|
|
What is your actual clock?.
You have conflicting settings. Crystal, and internal RC.
What you are describing, may not be a variable problem at all, but a small timing error in the RS232. It's be the last bit sent that is wrong.
Your pseudo code we can't test, since there are other things needed (interrupt handler for timer4 etc..). |
|
|
AHCCS
Joined: 10 Nov 2016
Posts: 10
|
|
| Posted: Mon Nov 14, 2016 5:17 am |
|
|
For reference: I am using the the development board from DSP Analog Development Kit by CCS with the 12 MHz crystal. Below I have a more simplified code.
| Code: |
#include <33EP256MU806.h>
#fuses NOWDT, PR_PLL, FRC_DIV_BY_16 // Internal FAST RC oscillator with 16x PLL
#use delay(crystal=12M,clock=120M)
/********** Definition of serial Modes ***************/
#define StartByte '$' // start byte of each serial frame
#define EndByte1 '\r' // 2nd last byte of each serial frame
#define EndByte2 '\n' // last byte of each return serial frame
//pins for UART
#pin_select U1TX=PIN_E7
#pin_select U1RX=PIN_F3
#define UART_HW UART1
#use rs232(baud=115200,parity=N, ERRORS,UART1,stream=SerialGame)
/** Global Variables **/
unsigned int8 lsbEnc1=0;
unsigned int8 msbEnc1=0;
unsigned int8 lsbEnc2=0;
unsigned int8 msbEnc2=0;
signed int16 countR=0;
signed int16 countL=0;
void main()
{
while(TRUE)
{
countL=71; // fixed values for testing
countR=71;
msbEnc1=make8(countL,1);
lsbEnc1=make8(countL,0);
msbEnc2=make8(countR,1);
lsbEnc2=make8(countR,0);
fprintf(SerialGame,"%cHM,",StartByte); //%c,%c,%c,%c,%2d,%2d,%c%c",StartByte,msbEnc1,lsbEnc1,msbEnc2,lsbEnc2,countL,countR,EndByte1,EndByte2);
fprintf(SerialGame,"%u,",msbEnc1);
fprintf(SerialGame,"%u,",lsbEnc1);
fprintf(SerialGame,"%u,",msbEnc2);
fprintf(SerialGame,"%u,",lsbEnc2);
fprintf(SerialGame,"%c%c",EndByte1,EndByte2);
}
}
|
I checked countL has the value of 70 instead of 71. So not sure if its a serial issue.
_________________
Novice User |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19546
|
|
| Posted: Mon Nov 14, 2016 8:42 am |
|
|
The comment that you checked the value, implies some form of debugger attached?.
Try the simple expedient of reversing the declaration order of the variables. So:
signed int16 countL=0;
signed int16 countR=0;
If the problem moves to countR, then you have a RAM fault in the PIC. |
|
|
newguy
Joined: 24 Jun 2004
Posts: 1909
|
|
| Posted: Mon Nov 14, 2016 8:50 am |
|
|
| Since this is a dsPIC project, an obvious question is how much RAM are you setting aside for the stack? Is it the default? What happens if you increase it? |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19546
|
|
| Posted: Mon Nov 14, 2016 8:57 am |
|
|
With the current compiler, it doesn't overflow as posted (that is why I don't bother to mention this). However the default size was increased some time ago, so if using a older compiler, definitely worth checking.
Generally if there was maths inside the printf for example, this would be very likely.... |
|
|
AHCCS
Joined: 10 Nov 2016
Posts: 10
|
|
| Posted: Mon Nov 14, 2016 11:45 pm |
|
|
| Ttelmah wrote: | The comment that you checked the value, implies some form of debugger attached?.
Try the simple expedient of reversing the declaration order of the variables. So:
signed int16 countL=0;
signed int16 countR=0;
If the problem moves to countR, then you have a RAM fault in the PIC. |
This is indeed the case. If I invert the CountL works while the other gives the wrong value.
By RAM fault you mean I need to specify more and how should I do so? I dont have a lot of variables assigned so not sure how I run out of RAM so fast?
Lastly I have two boards and I have tried on both and it gives me the same issue.
_________________
Novice User |
|
|
AHCCS
Joined: 10 Nov 2016
Posts: 10
|
|
| Posted: Mon Nov 14, 2016 11:49 pm |
|
|
| newguy wrote: | | Since this is a dsPIC project, an obvious question is how much RAM are you setting aside for the stack? Is it the default? What happens if you increase it? |
It is default and I am not sure how much is it. I am using compiler v4.125. Any suggestions how to check it. Although when I compile it I can see that I am using 1% of RAM only.
Best
Asif
_________________
Novice User |
|
|
AHCCS
Joined: 10 Nov 2016
Posts: 10
|
|
|
newguy
Joined: 24 Jun 2004
Posts: 1909
|
|
| Posted: Tue Nov 15, 2016 7:22 am |
|
|
Look for the #BUILD stack line and increase the amount specified in that line. |
|
|
AHCCS
Joined: 10 Nov 2016
Posts: 10
|
|
| Posted: Tue Nov 15, 2016 10:03 pm |
|
|
| newguy wrote: |
Look for the #BUILD stack line and increase the amount specified in that line. |
Increased the stack but hardly changed anything.
| Code: | #include <33EP256MU806.h>
//#build(stack=0x1E00:0x1FFF)
#build(stack=0x300)
#use delay(crystal=12M,clock=120M)
#define StartByte '$' // start byte of each serial frame
#define EndByte1 '\r' // 2nd last byte of each serial frame
#define EndByte2 '\n' // last byte of each return serial frame |
_________________
Novice User |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19546
|
|
| Posted: Wed Nov 16, 2016 1:46 am |
|
|
The example code, didn't hit the stack limit, so I didn't expect this to help, however will become necessary as the code grows. I have to repeat my belief that this is a RAM fault. By this I mean _a faulty chip_. It does happen. Unless you have tried on at least two chips (and preferably from different batches), I have to say that this really is the most likely reason.
It might be being cause by your hardware though. How confident are you that the chip really is receiving a noise free, stable supply?. Does your circuit have the recommended decoupling close to the chip?. Does it behave the same without the debugger?. Are you sure there is nothing in the circuit that could result in unexpected voltages to pins?.
You can always prove that you don't have a stack error, by simply enabling INT_STACKERR, and having a handler for this. If the code arrives here, you have a stack error. Otherwise, this is not the problem. |
|
|
AHCCS
Joined: 10 Nov 2016
Posts: 10
|
|
| Posted: Wed Nov 16, 2016 4:05 am |
|
|
| Ttelmah wrote: | The example code, didn't hit the stack limit, so I didn't expect this to help, however will become necessary as the code grows. I have to repeat my belief that this is a RAM fault. By this I mean _a faulty chip_. It does happen. Unless you have tried on at least two chips (and preferably from different batches), I have to say that this really is the most likely reason.
It might be being cause by your hardware though. How confident are you that the chip really is receiving a noise free, stable supply?. Does your circuit have the recommended decoupling close to the chip?. Does it behave the same without the debugger?. Are you sure there is nothing in the circuit that could result in unexpected voltages to pins?.
You can always prove that you don't have a stack error, by simply enabling INT_STACKERR, and having a handler for this. If the code arrives here, you have a stack error. Otherwise, this is not the problem. |
I will check for the stack now. But for RAM issue I am using the embedded platform provided by CCS http://www.ccsinfo.com/product_info.php?products_id=dsPIC-analog-kit
And i have two of them both behave in a similar manner. So is the probability both are wrong?
Finally the only way I debug is by using serial ports somehow i cant debug as well using the software. But I am sure its not serial port issue because I verified it by using conditional statements.
_________________
Novice User |
|
|
|
|
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
