pic18F25K22 variable goes crazy

[koenbielen]

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.

[temtronic]

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]

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]

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]

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]

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]

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:

[Ttelmah]

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]

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]

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]

it was a array error.
pointer out of scope...

So that was the issue

[Ttelmah]

It did rather 'scream' that....

Glad you have traced it.

Best Wishes