Strange misbehaving array

[Remco]

Good day chaps,

I recently came across a strange problem when testing my software. I develop the firmware with CCS C compiler version 5.042. The firmware will run on a dsPIC30F6014A. The problem is as follows:

I declared a few one dimensional arrays to store different values for multiple calculations. At some point the value of a segment in the array is affected without any code that does so. aka the number in a array random changes. For an example I used TEMPERATURE_SETPOINT and test1. The declaration for the array is as follows:

[asmboy]

i would bet that what is is going on is that
the previous VAR in your program :
TEMPERATURE_VALUE []
is accidentally being written to with an index of 2
and thus flowing into the var you mention being altered.

accidental mis-indexing is the common cause of what you see
happening.

[Remco]

[asmboy]

[Remco]

In every routine where I access the variables I check the index. If incorrect it goes out of the routine. After a test, the problem still occurs. I also outputted the index value and every time it is either 0 or 1. So it a strange problem.

The first time I came across this problem I automatically did what you said. Its my first thing to do because I know that would explain it. so another check gave the same result.

[alan]

To test what asmboy is hinting at. Put the declaration of test1 above the TEMPERATURE_SETPOINT. If it an out of bounds array then test1 will also be corrupted, or if it was the 1st element in the TEMPERATURE_SETPOINT array it will move to the 2nd.

Regards

[Ttelmah]

1) Global variables will never be re-used.
2) Though it doesn't matter, the static declarations do nothing. The only difference between a global static, and a global, is that the global static is 'warranted' to be initialised to zero, if it not explicitly initialised.
3) Beware of things like pointer arithmetic. Though the most 'common' cause is something directly beneath or above the variable in memory 'walking' outside it's allowed indexes, the second most common reason is something like pointer arithmetic a long way away....
4) Are any of the variables used/updated in interrupts?. Beware that variables larger than a byte (for PIC16/18), or a word (For PIC24 & up), do not guarantee that writes will be 'uninterrupted'. You need to handle this yourself.
5) I've never found #priority to work properly on the PIC24/30. Instead explicitly allocate the individual interrupts to the interrupt level you want.
6) Personally I'd have a 'temperature' structure, containing the settings for a single channel, and then declare an array of these. Generally avoid using ALL CAPITALS. Normally this is used as an 'indicator' in C, that the value is a #define. Using it for variables removes this (useful) guidance.
So:

[Remco]

Thank you for your reaction. Following your statements:

1) I know that's the case, but I read it can happen. Most likely not but it can.
2) Always good to know if a variable is definitely initialized to a know number (to be sure).
3) I do not use any pointer arithmetic or pointers in general in this case. It would make sense if that was the problem but if there is none it couldn't be the problem.
4) I do not change any variables with which I have problems with in my interrupt routine. I only set a 'flag' to indicate that a code must be executed in the main program. So no variables a changed in the interrupt routine.
5) Most likely, but it is more like a trial to see if something happened (not seen yet).
6) I tried the structure but it gave the same problems. But an array is in this case for me more useful.

I already plough through the entire code before I made this post, because it's a problem. And to make sure it isn't a silly programming fault made by me.
The only thing I'm sure of is that it happens on a specific memory location. I searched through the ASM code to look if a reference it made without using the variable at that memory location. But there is none. So most likely is must be the pointer problem, but I cant find it because I specific don't use any pointer code. That's is why I find it so strange. And every indexing is checked to make sure a defined array is accessed. So its must be something very sully.

[Ttelmah]

You are using pointers. In C, arrays and pointers are basically the same thing.

Classic 'hidden error' would be something in another array, that uses a variable for index, which accidentally gets taken 'below zero'. Becomes -1 (even on an unsigned), so if int8, 0xFF. This then results in talking effectively to entry 255, times the element size in the array, could be almost anywhere in memory. Ugh....

The structure is an array. hence the [0].

Instead of ten? separate arrays, it is a single array containing all the elements together as one entity.

[Remco]

I probably have found the problem. I was also using sprintf. Apparently the array at which the string must be stored was too small. And there, as you said, it was writing to the memory after his declaration. At some point the memory of the affected variables was overwritten. Increasing the array width solved it. It was a static declaration, so I would expect at least a warning to indicate this. But apparently sprintf doesn't do any checking, according to the manual. Bummer .

But it's true that C is full of pointers, and that you are using them even when you doing expect it. But I meant that I wasn't specific using pointer. Pointers that are made by programmers are most likely the fault which you meant. Pointers in code provided by de compiler or standard library's are most of the time proven so that would rule them out.

Thank you for you help.

-On to solving the next problems

[Ttelmah]

At least you have found it...

It is key to understand that this is 'inherent' in C.

In C, and 'array' is just a pointer, with a compile time initialisation, and does not contain a 'size' as an element. In many other languages that have an 'array' type, they do. So things accessing a C array/pointer, have no knowledge inherently of how much space they actually point 'to', and can access beyond the end... :(
Now, in chips with hardware memory management, there is still no direct check, but if you access 'outside' the page allocated in the memory management, then a hardware warning can be generated. The PIC has no such system.
You could declare your own 'bounded' type, which you initialise with a pointer to an area of memory, and the bounds in this to be used, then overload all the string functions, with versions that test the address they are being called with, against the bounds. Problem is of course, a lot of code, and a lot of actual work....

[jeremiah]

This is one of the reasons I wish CCS had an snprintf() alternative. I made a quick and dirty one that I posted in the code library (for version 5 compilers), but at some point I need to go back and make myself a more efficient and proper one.

An snprintf() wouldn't completely prevent problems like this (you can put in whatever max size you want technically), but at least for me it would reduce the chances of this happening as I am pretty OCD about specifying lengths whenever I pass a pointer intended to be an array.

[Ttelmah]

Agreed wholeheartedly.

Have you actually asked CCS?. Point out it's advantages, and it would not involve that much extra coding onto their existing sprintf library.

[jeremiah]

I have not. I guess I haven't gotten into the mindset that I can also send feature requests to the support email. I tend to only do bugs out of habit I guess. I'll have to toss them an email on this.

EDIT: sent one this morning. Also mentioned there may be other methods like strcpy (strncpy) that could benefit from this but that sprintf/snprintf would probably the more heavily used. We'll see what the response is.

[Remco]

We will see. It would make even a better compiler then it already is.