View previous topic :: View next topic |
Author |
Message |
koenbielen
Joined: 23 Apr 2009 Posts: 42
|
pic18F25K22 variable goes crazy |
Posted: Mon Apr 07, 2014 8:15 am |
|
|
Hello,
I have a strange problem with variables.
The variable gets value not expected.
normal working is that if i press on a button a counter increases.
That works half... at a certain point this printf gives -123
This is not a correct value.
Variable is global and can be accessed in subroutines...
first time I encounter this problem in 5 years of using this compiler.
Version is 5.xxx
Has anyone a clue what im doing wrong.
Code: |
unsigned int8 nControlPanelMode = 1;
// interrupt routines
#INT_TIMER1
void Trigger()
{
if (input(button)){nControlPanelMode++;delay_ms(1000)}
}
void main void
{
printf("<nr : %d>",nControlPanelMode );
}
|
|
|
|
temtronic
Joined: 01 Jul 2010 Posts: 9240 Location: Greensville,Ontario
|
|
Posted: Mon Apr 07, 2014 8:26 am |
|
|
off the top
1)It is never, ever a good idea to have any delay in an ISR, especially a delay of 1000 ms !!!
2) 'button' will need/must have 'debouncing'. Either hardware( r-c nextwork, chip,etc.) or software(delay based on hardware used).
hth
jay |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19535
|
|
Posted: Mon Apr 07, 2014 8:51 am |
|
|
add the third one.
%d is the printf format specifier for a _signed_ decimal integer. %u is what is needed for an unsigned value. |
|
|
koenbielen
Joined: 23 Apr 2009 Posts: 42
|
|
Posted: Mon Apr 07, 2014 9:22 am |
|
|
Hi,
thanks for comments
Yes you are correct on delays in isr. it was just a sample i wanted to explain.
Strange thing is now that it is also happening on a 2nd variable
These variables are read out from eeprom at startup. and when i want to change this variable at a certain point they go to a value and stay there.
So no + or - operation works.
printf format has been changed from %d to %u to %ld %lu ... together with the appropriate declaration of the variable int... signed int ... unsigned int16 ....
So problem is expanding now |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19535
|
|
Posted: Mon Apr 07, 2014 10:33 am |
|
|
Array overflow.
Classic I'm afraid.
You are almost certainly writing beyond the end of an array. Remember (for instance), that an array declared as array[10] allows 9 as the maximum index, and that strings use one more character than they seem to need, for the null terminator character. I'd bet that the affected variables are one after the other in memory, and the problem has gone a bit further, so is walking over another variable now.
Look at the .sym file, and what is the variable immediately below the problem ones in memory. |
|
|
Mike Walne
Joined: 19 Feb 2004 Posts: 1785 Location: Boston Spa UK
|
|
Posted: Mon Apr 07, 2014 3:43 pm |
|
|
To get a more definitive answer you need to post the shortest possible, complete, compilable code which illustrates the problem.
At this stage we are all having to second guess.
Mike |
|
|
koenbielen
Joined: 23 Apr 2009 Posts: 42
|
|
Posted: Tue Apr 08, 2014 12:15 am |
|
|
Problem seems to be solved:
Placing my function calls above the declaration of the variables seems to remove the problem.
This gives a problem with the variable called in different subroutines:
Code: |
int nCounter;
void increasecounter(void);
|
and this solves the problem:
Code: |
void increasecounter(void);
int nCounter;
|
Intresting .... |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19535
|
|
Posted: Tue Apr 08, 2014 2:40 am |
|
|
Not really.
It just means one of your other functions is using a variable of the same name, and hence it is getting changed in this.
Remember a variable declared outside a function, is global.
A global variable can be changed by any routine. |
|
|
koenbielen
Joined: 23 Apr 2009 Posts: 42
|
|
Posted: Tue Apr 08, 2014 11:50 pm |
|
|
I have added a printf to a serial port on all parts where the variable has been changed.
The problem still remains....
Once i put the function calls on top of the program....
problem gone...
So this is strange.
I will check further into code... its 3000 lines, so easy to overlook something.
Thanks for your comment. |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19535
|
|
Posted: Wed Apr 09, 2014 12:51 am |
|
|
I'd still go back to every pointer and array access you make.
Re-organising the calls, changes the order that variables are allocated in memory, so changes what gets modified....
Look at the .sym file with the functions declared at the top, and the .sym file with them declared lower. My guess is that you will find the local variables in the function are now declared higher up the memory area, so are 'above' what is causing the problem.
Key thing to understand, is that the PIC has no hardware memory management. It is up to you as the programmer to ensure that an array index is never outside the area allocated for the array (and the same for pointers). Look at every array index you use, what generates it, and even consider adding your own 'bounds checking' to the accesses. Then look at everywhere you do any arithmetic on pointers. |
|
|
koenbielen
Joined: 23 Apr 2009 Posts: 42
|
|
Posted: Tue Apr 15, 2014 12:47 am |
|
|
it was a array error.
pointer out of scope...
So that was the issue |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19535
|
|
Posted: Tue Apr 15, 2014 1:03 am |
|
|
It did rather 'scream' that....
Glad you have traced it.
Best Wishes |
|
|
|