Baffled with this problem

snock · Joined: 10 Oct 2011 Posts: 24

The following code does not set the values to the the data structure zone. MAXZONE is equal to 6. The i (int8) variable is printed to the LCD and works correctly. zone[0].off_t when printed shows uninitialized data. If I use zone[0].off_t in the loop it works. Looks like a CCS bug but I wanted to confirm it. I'm running 4.127.

Ttelmah · Joined: 11 Mar 2010 Posts: 19515

It sounds as if you are using a debugger of some sort?.
How is zone declared?.
A variable has a value once declared, even if nothing has been written to it. Normally all binary 1's. The message suggests the debugger doesn't understand the code that CCS generates to access an offset variable. If you use a fixed index, a direct access to memory will be performed (which the debugger presumably understands), but using a variable it'll be done using indirect access.
Try printing the variables with printf, rather than the debugger.

Best Wishes

snock · Joined: 10 Oct 2011 Posts: 24

I should have said so, but I am indeed using printf (to the LCD) to print out the data. I am not using a debugger but rather loading the code with the ICD-U64 to a PIC24FJ64GB106. I don't use the ICD for anything other than program loading at this point. I also have tried using a literal, ie zone[0].off_t, rather than the i variable. It works using the literal but of course I would like to use the for loop to stuff in the default data. The i variable is not used globally either not to mention I tried using different variable names with no success.

Ttelmah · Joined: 11 Mar 2010 Posts: 19515

OK.
Still the question of how zone is declared, and where?.

Best Wishes

snock · Joined: 10 Oct 2011 Posts: 24

It's declared before main() so it's global.

FvM · Joined: 27 Aug 2008 Posts: 2337 Location: Germany

As with every problem of this kind, can you reproduce it in a compact example application? If so, please show it.

andrewg · Posted: Thu Dec 08, 2011 9:25 pm

While I think the code as given should work (as in, I don't see anything wrong with it), I'd still do it a little differently:

RF_Developer · Joined: 07 Feb 2011 Posts: 839

I don't know if this is the cause, but there are/have been some issues with structures and arrays of structures that are greater than 256 bytes long.

In your case a single instance of a structure is 45 bytes: 11 int32s @ 4 bytes each plus an int8. These may be aligned to 4 byte boundaries, or possibly 2 byte on a PIC24, so effectively in an array of them they may look like 48/46 bytes each: 45 bytes with 3 or 1 padding bytes. That's more likely on other processors, such as ARMs, and certainly on PCs. Your array is 6 of these, so its either 270 bytes or 288 if its padded. Either way one of the structures crosses a 256 byte boundary. The trouble may be related to indexing finding the offset of a structure correctly, but then individual members are not correctly addressed due to indexing limitations... or something.

I detect a hint of a "coding standard" in your code. One that assumes all variables will be 32 bit unless otherwise stated. Do all these variable really NEED to be 32 bit, or is it just a "standard"? If not, then careful sizing may solve the problem, and will certainly reduce RAM requirements and improve performance if nothing else.

You are also using descriptive suffixes which confused me. I see time_t and automatically assume it means time type, as is the conventional. Reading on, I see it must mean its a variable holding a time, _c meaning holding a count and so on. I am sure you know what it means, its just that it clashes with other more widely used conventions, which makes your code difficult to read. This tends to make me think you are working to some style guide that proscribes this stuff, and maybe the int 32s too....

RF Developer.