Constant array returns wrong value with variable index value

[levdev]

I'm having a problem returning the correct value from an array when accessing it with a variable index. A constant index returns the correct value. They both return the correct value up to the index 1014 and then at array position 1015 only the constant index returns the correct value. See sample code below:

[PCM programmer]

I tested your code with vs. 4.119 in MPLAB simulator and I got this:

[levdev]

Thanks for your reply. I moved the variable declaration, this has made the two values consistently the same, but still wrong when the array index goes over 1014.

[Ttelmah]

Wrote a 'bodge round' for the read:

[levdev]

Thanks for the fix. I had just been working on a similar fix myself, but haven't had time to test either yet.

The thing I don't understand is that for this function to work, the bytes of data must be stored consecutively in program memory. If they are stored consecutively then why is there an error retrieving the values directly from the array using the array index. Surely the compiled lookup code for this is similar to your function anyway, adding the array index*2 to the array memory start location.

In my real program, the array of calibration data is 3 dimensional, and much larger than this test program with about 5000 data points. As such I can't proceed with confidence at the moment that the correct data will be returned, which means the device might not give the correct result.

[Ttelmah]

Since it comes right at the page boundary, I'd guess that the code is just getting the 'carry' wrong when it reaches the boundary. The array access code is direct assembler, and probably optimised to be a little faster. Unfortunately, somewhere in this a bug has been introduced when dealing with large arrays that cross a page boundary.

Best Wishes

[levdev]

Is there anyway of forcing the array into the start of a page, so it doesn't have to cross the boundary?

[PCM programmer]

You can use #locate to set the starting RAM address of an array. Example:
http://www.ccsinfo.com/forum/viewtopic.php?t=19945&start=5

[levdev]

Can you use this for constant arrays stored in program memory? This array is too big for the RAm available on the PIC18f26k22.

[asmboy]

specifying the array as CONST should force it into program memory.
i recall my days with 8086 code where it was best practice to force an array
to start on an even byte. - simply rearranging WHERE in your program linear order - the array is encountered by the compiler might be of help.
Or so i thought until i tried THIS:
( warning do not TRY this code as i wrecked your table to make its location more visible in HEX !!!)

in the HEX file you can see a long line of hex 5555555555
where the printf "U" statement is located )

the changes in the table , 174876 repeated produce a long line of 44444444 so you can SEE what address the table is dumped to
and no matter WHERE the table is encountered in linear fashion -
the compiler blindly stuffs it at the head of the program memory

[PCM programmer]

You can use #org to place an array in ROM. Example:

[asmboy]

i just tried this and it compiled A-OK

[levdev]

After some more testing it seems that any constant array placed after memory location 0x0800 will not return the correct value. It's not so much the transition past 7FF, but just anything beyond this location. The data is put into memory correctly at compile time, but when the address is higher than 7FF It returns the LSB correctly but the MSB is always zero. This is even true with a small array as per the code below:

[asmboy]

i have a currently deliverable application using an 18F4620 that has 512 elements, to ten decimal places - saved as a const FLOAT table - a GRAND old memory hog - that has never done anything but perform as expected.

it was assembled under 4.085

this sort of problem is one more of the main reasons i hesitate to blindly
use a new version of CCS - on a complicated program.
at least not until i have done a lot of testing with old things that work already.

[levdev]

Actually scratch some of that, Ttelmah the function also doesn't work on data stored after memory location 0x7FF.