Array Problem?

[ric355 0]

I have the following fragment of code, which is being executed as part of the interrupt routine;

 

rd[digitindex]++;
if (rd[digitindex] > 9)
{
  rd[digitindex] = 0;
}

rd is global and defined as:

 

char rd[4];

 

So each digit in the array goes from 0-9 and then wraps around to zero again. digitindex is always in the range 0-3.

The code generated by the above is as follows:

 

				rd[digitindex]++;
2AC2  0E00		  MOVLW	HIGH(gbl_rd)

2AC4  6EEA		  MOVWF	FSR0H
2AC6  0E48		  MOVLW LOW(gbl_rd+D'0')
2AC8  6EE9		  MOVWF FSR0L
2ACA  5065		  MOVF gbl_digitindex, W
2ACC  26E9		  ADDWF FSR0L, F
2ACE  2AEF		  INCF INDF0, F

			if (rd[digitindex] > 9)
2AD0  0E00		  MOVLW	HIGH(gbl_rd)

2AD2  6EEA		  MOVWF	FSR0H
2AD4  0E48		  MOVLW LOW(gbl_rd+D'0')
2AD6  6EE9		  MOVWF FSR0L
2AD8  5065		  MOVF gbl_digitindex, W
2ADA  26E9		  ADDWF FSR0L, F
2ADC  0E09		  MOVLW 0x09
2ADE  64EF		  CPFSGT INDF0
2AE0  D008		  BRA	label268439142
2AF2			label268439142

			{
				rd[digitindex] = 0;
2AE2  0E00		  MOVLW	HIGH(gbl_rd)

2AE4  6EEA		  MOVWF	FSR0H
2AE6  0E48		  MOVLW LOW(gbl_rd+D'0')
2AE8  6EE9		  MOVWF FSR0L
2AEA  5065		  MOVF gbl_digitindex, W
2AEC  26E9		  ADDWF FSR0L, F
2AEE  0E00		  MOVLW 0x00
2AF0  6EEF		  MOVWF INDF0

			}

 

I have code in the main loop which displays the 4 digits on an LCD display. When the above code executes, the values do not change. However, if I explicitly change the value of one of the digits by putting something like rd[1] = 6; into the code just after the non working section, this value is shown on the display.

 

I'm not sure if this is a genuine compiler issue, or whether I've done something stupid, but if I replace the original code with the following explicit code, then it all works correctly;

 

int i;

   if (digitindex==0)
			i = rd[0];
   else
if (digitindex==1)
	i = rd[1];
else
if (digitindex==2)
	i = rd[2];
else
if (digitindex==3)
	i = rd[3];

i++;
if (digitindex==0)
	rd[0] = i;
else
if (digitindex==1)
	rd[1] = i;
else
if (digitindex==2)
	rd[2] = i;
else
if (digitindex==3)
	rd[3] = i;

if (i > 9)
{
if (digitindex==0)
		   rd[0] = 0;
else
if (digitindex==1)
	rd[1] = 0;
else
if (digitindex==2)
	rd[2] = 0;
else
if (digitindex==3)
	rd[3] = 0;
}

 

Using version 6.70 but also tried with version 6.81 and the result was the same. I'm back with 6.70 at the moment (and is the version used to generate the code above). I noticed a recently reported bank issue lower down the forum index - is this possibly the same problem? I'm not very familiar with the instruction set but I noted that the high and low parts of the address are loaded, but when it adds the digitindex value to FSR0L in order to get the memory address of the correct array subscript, it doesn't seem to take account of whether there will be any wraparound of FSR0L. Is this being done by the PIC?

 

Device target is 18f4420.

 

Help appreciated - been trying to find this for the last few days and I'm finally beginning to think it's a compiler problem.

 

Ric.

[Dave 0]

ric355,

Device target is 18f4420.

 

Help appreciated - been trying to find this for the last few days and I'm finally beginning to think it's a compiler problem.

 

Ric.

Can you supply a small but complete program that demonstrates the problem, preferably one that will run under the SourceBoost Debugger/simulator.

 

Regards

Dave

[ric355 0]

ric355,

Device target is 18f4420.

 

Help appreciated - been trying to find this for the last few days and I'm finally beginning to think it's a compiler problem.

 

Ric.

Can you supply a small but complete program that demonstrates the problem, preferably one that will run under the SourceBoost Debugger/simulator.

 

Regards

Dave

 

Will post back later with something hopefully.

[flyco 0]

Actually no, at least I think so, just a small comprehensive plan running一下sourceboost debugger / simulator, can do

[ric355 0]

I finally got to the bottom of this problem. I tried to reproduce the fault with a small application but could not do so. I ended up purchasing an ICD2 and switching to MPLAB to debug it. When I started using MPLAB I began to get a warning dialog saying that the application may not work properly because the extended instruction configuration bit was set.

 

Sure enough, checking the configuration bits revealed that this bit is indeed set. I ignored the message for a while as I hadn't realized quite what it was telling me, and on debugging I could clearly see that the file registers being affected did not match what the disassembly was telling me should be happening.

 

Anyway, as soon as I included _XINST_OFF_4L in the configuration bits, the problem has gone away and I've been able to write the code in the way one would expect to write it. I actually didn't have any XINST_4L setting at all in the #pragmas - appears it defaults to 'on' in that case which is obviously wrong for the 18F4420 I'm using.

 

Ric.