CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to CCS Technical Support

Variables not changing.

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
DaveThib



Joined: 17 Oct 2004
Posts: 15
Location: New Hampshire USA

View user's profile Send private message

Variables not changing.
PostPosted: Sat Jan 20, 2007 6:09 pm     Reply with quote

I have a very strange problem that has me stumped. MY program is not functioning because all of my variables asre not being initialized properly. This is VERY simple code! So I looked at the assembler code and I see that the variables that I am having trouble with are being addressed differently. I have looked around for the diference and could not find an explaination. For instance, one of the array elements is using a MOVWF 5E and that data is being transfered to the corrent memory location. But four out of the six elements are using a MOVFW x61 and that line does not put the data into memory position 0x61 like it should. There are several variables that are doing this. It is right in the beginning of my code so there is not much opportunity for me to screw it up! Smile

Here are the details:
I am using a USB-40 to connect to a PIC 18F6310. This is a new piece of hardware so I double and tripple checked the programming port connections. I am using the compiler version 3.249. ( I have yet to update to the new one...)
The hardware I am designing is taking seven different parallel buffers to read 56 different switches and turn on one of seven different parallel output drivers. I have designed a similar unit a couple of years ago and had no issues like this! So I have several arrays of pointers and variables so that I can quickly change an output enable by writing to a port. Or toggle the Latch Enable on the transparent latches.

This is a new processor that I have not used before.

Here is the header

[/code]
#include <18F6310.h>
//#device *=18
#device ICD=TRUE

#FUSES NOWDT //No Watch Dog Timer
#FUSES INTRC_IO //Internal RC Osc
#FUSES PUT //Power Up Timer
#FUSES MCLR //Master Clear pin enabled
#FUSES BROWNOUT //Reset when brownout detected
//#FUSES NOLVP //Low Voltage Programming on B3(PIC16) or B5(PIC18) Disabled
//#FUSES NOCPD //No EE protection
//#FUSES NOWRT //Program memory not write protected
#FUSES DEBUG //Debug mode for use with ICD
#FUSES NOPROTECT //Code not protected from reading
//#FUSES PROTECT // Code proteced from being read out
#FUSES FCMEN //Fail-safe clock monitor enabled
#FUSES NOIESO //Internal External Switch Over mode disabled

#use delay(clock=32000000,RESTART_WDT)

#use fast_io(A)// Set up all the ports to not change direction or tri-state but to remain fixed.
#use fast_io(B)
#use fast_io(C)
#use fast_io(D)
#use fast_io(E)
#use fast_io(F)
#use fast_io(G)

#byte TIMER2CON = 0x12

#bit SSPCON_WCOL = 0x14.7 // Location of WCOL bit in the SSPCON register
#bit SSP_INT_Flag = 0x0C.3 // Location of SSPIF bit in the PIR1 register

#DEFINE CLEAR_SSP_WCOL_Flag() SSPCON_WCOL= FALSE
#DEFINE CLEAR_SSP_INT_Flag() SSP_INT_Flag= FALSE
#DEFINE Setup_Timer2_Custom TIMER2CON = 0x7F
Code:


Here is my main routine up to the main program loop. This happens before I get that far.



void main()
{
set_tris_a(0b11111111);
set_tris_b(0b11111111);
set_tris_c(0b11011111);
set_tris_d(0b00000000);
set_tris_e(0b10000000);
set_tris_f(0b10000000);
set_tris_g(0b11111110);

// Shut off all outputs
// for (Count = 0; Count<7; Count++)
// {
// Output_Relay_LED_Data(0 ); // Output the byte
// Output_Bank_LE_Lines(Input_and_Output_Byte_Enable[Count]); // Raise the LE line to move the data to the output pins
// Clear_Output_Bank_LE_Lines; // Latch in the data
// }; // end of FOR loop
Output_Relay_LED_Data(0 ); // Put all zeros out to the data bus
Output_Bank_LE_Lines(0x7F); // Raise the all the LE lines to move the data to the output pins
Clear_Output_Bank_LE_Lines; // Latch in the data
delay_MS(100);



Initialize();

}



Code:


Here are my data definitions:




byte OutputBytes[7]; //Array of 7 bytes which have the following functions:
//Byte 0 = Option LED states
//Byte 1 = Solo 1-8 LED states
//Byte 2 = Solo 9-12 Cut 9-12
//Byte 3 = Cut 1-8
//Byte 4 = Solo 13-20
//Byte 5 = Solo 21-24, Cut 21-24
//Byte 6 = Cut 13-20

byte SIP_OutputBytes[7]; //Array of 7 bytes which have the following functions:
//Byte 0 = Option LED states
//Byte 1 = Solo 1-8 LED states
//Byte 2 = Solo 9-12 Cut 9-12
//Byte 3 = Cut 1-8
//Byte 4 = Solo 13-20
//Byte 5 = Solo 21-24, Cut 21-24
//Byte 6 = Cut 13-20


byte Input_and_Output_Byte_Enable[7];
//The input buffer output enables and the output buffer's latch enable all have
// the same address so they can both use the same variable.

#define Output_Bank_LE_Lines(x) (output_e(x))
#define Clear_Output_Bank_LE_Lines (output_e(0))
#define Output_Relay_LED_Data(x) (output_d(x))
byte Input_To_Output_Lookup_Table[56];

byte Output_Byte_Packed_Changes; // this is seven different boolean variable packed into one byte
// they are Flags used to tell the output service routine which byte changed

boolean Something_Changed; // if any switch has changed this is true


// int_RTCC global variables used for debouncing

byte Current_Sample[7]; // stores the values of port A when reading in the switches
byte Last_Sample[7]; // Stores the last sample readings
byte Time_Before_Last_Sample[7]; // Stores the sample from two times ago
//byte Count_Same_Samples;
byte NotPressed_Result[7]; // the result of testing for all zeros
byte Pressed_Result[7]; // the result of the anding of three sample periods to find 1s
boolean New_Result_Is_Ready; // flag the main routine to check the results
byte Input_byte_Ptr; // pointer to determine which bank of switces are being looked at.


#define Start_Debounce_Timer set_rtcc(65466) //65466 = .14ms interrupt time
// See the RTCC interrupt code for an explaination of where this number came from.


// Main routine variables
byte Current_Switch_Ptr;
byte Counter;



// Solo system variables and defines

#define Release_Solo_Logic (output_low(PIN_G0))
#define Engage_Solo_Logic (output_high(PIN_G0))
#define Solo_Receive_Flag (input(PIN_B0))
#define SIP_Mode_Flag (input(PIN_B2))
#define Monitor_Solo_Iso_Flag (bit_test( Switch_State[5] , Value ))
#define Clear_Solo (bit_test( Switch_State[6] , Value ))
#define Clear_Solo_Lamp_On (bit_set (OutputBytes[0] , 6)) // Turn on the Solo Clear Lamp
#define Clear_Solo_Lamp_OFF (bit_clear (OutputBytes[0] , 6)) // Turn off the Solo Clear Lamp

boolean SIP_Engage_Flag;
boolean AFL_Engage_Flag;
byte Solo_State; // State variable for the Solo system state machine


Code:



Below here is the initialize routine.



Clear_Output_Bank_LE_Lines;
Input_byte_Ptr = 0; // start with the option switches. Sounds good to me
Current_Switch_Ptr = 0; // Start looking at the first switch
Output_Byte_Packed_Changes = 0x7F; // set all the flags so that they all get updated the first time thru the loop.
Something_Changed = TRUE;
New_Result_Is_Ready = FALSE; // Wait for all the switches to be tested at least once

// Initialize the Solo system
Release_Solo_Logic;
SIP_Engage_Flag = FALSE;
AFL_Engage_Flag = FALSE;
Solo_State = 0;


Input_To_Output_Lookup_Table[0] =0x00;
Input_To_Output_Lookup_Table[1] =0x01;
Input_To_Output_Lookup_Table[2] =0x02;
Input_To_Output_Lookup_Table[3] =0x03;
Input_To_Output_Lookup_Table[4] =0x04;
Input_To_Output_Lookup_Table[5] =0x05;
Input_To_Output_Lookup_Table[6] =0x06;
Input_To_Output_Lookup_Table[7] =0x07;
Input_To_Output_Lookup_Table[8] =0x10;
Input_To_Output_Lookup_Table[9] =0x30;
Input_To_Output_Lookup_Table[10] =0x11;
Input_To_Output_Lookup_Table[11] =0x31;
Input_To_Output_Lookup_Table[12] =0x12;
Input_To_Output_Lookup_Table[13] =0x32;
Input_To_Output_Lookup_Table[14] =0x13;
Input_To_Output_Lookup_Table[15] =0x33;
Input_To_Output_Lookup_Table[16] =0x14;
Input_To_Output_Lookup_Table[17] =0x34;
Input_To_Output_Lookup_Table[18] =0x15;
Input_To_Output_Lookup_Table[19] =0x35;
Input_To_Output_Lookup_Table[20] =0x16;
Input_To_Output_Lookup_Table[21] =0x36;
Input_To_Output_Lookup_Table[22] =0x17;
Input_To_Output_Lookup_Table[23] =0x37;
Input_To_Output_Lookup_Table[24] =0x20;
Input_To_Output_Lookup_Table[25] =0x24;
Input_To_Output_Lookup_Table[26] =0x21;
Input_To_Output_Lookup_Table[27] =0x25;
Input_To_Output_Lookup_Table[28] =0x22;
Input_To_Output_Lookup_Table[29] =0x26;
Input_To_Output_Lookup_Table[30] =0x23;
Input_To_Output_Lookup_Table[31] =0x27;
Input_To_Output_Lookup_Table[32] =0x40;
Input_To_Output_Lookup_Table[33] =0x60;
Input_To_Output_Lookup_Table[34] =0x41;
Input_To_Output_Lookup_Table[35] =0x61;
Input_To_Output_Lookup_Table[36] =0x42;
Input_To_Output_Lookup_Table[37] =0x62;
Input_To_Output_Lookup_Table[38] =0x43;
Input_To_Output_Lookup_Table[39] =0x63;
Input_To_Output_Lookup_Table[40] =0x44;
Input_To_Output_Lookup_Table[41] =0x64;
Input_To_Output_Lookup_Table[42] =0x45;
Input_To_Output_Lookup_Table[43] =0x65;
Input_To_Output_Lookup_Table[44] =0x46;
Input_To_Output_Lookup_Table[45] =0x66;
Input_To_Output_Lookup_Table[46] =0x47;
Input_To_Output_Lookup_Table[47] =0x67;
Input_To_Output_Lookup_Table[48] =0x50;
Input_To_Output_Lookup_Table[49] =0x54;
Input_To_Output_Lookup_Table[50] =0x51;
Input_To_Output_Lookup_Table[51] =0x55;
Input_To_Output_Lookup_Table[52] =0x52;
Input_To_Output_Lookup_Table[53] =0x56;
Input_To_Output_Lookup_Table[54] =0x53;
Input_To_Output_Lookup_Table[55] =0x57;


Input_and_Output_Byte_Enable[0] =0b01000000;
Input_and_Output_Byte_Enable[1] =0b00000001;
Input_and_Output_Byte_Enable[2] =0b00000010;
Input_and_Output_Byte_Enable[3] =0b00000100;
Input_and_Output_Byte_Enable[4] =0b00001000;
Input_and_Output_Byte_Enable[5] =0b00010000;
Input_and_Output_Byte_Enable[6] =0b00100000;


Code:



And last but not least is the assembler printout of this last bit of the init routine. There are other places that this happens but this shows the problem:



....................
....................
.................... Input_and_Output_Byte_Enable[0] =0b01000000;
035A: MOVLW 40
035C: MOVWF 5E
.................... Input_and_Output_Byte_Enable[1] =0b00000001;
035E: MOVLW 01
0360: MOVWF 5F
.................... Input_and_Output_Byte_Enable[2] =0b00000010;
0362: MOVLW 02
0364: MOVWF x60
.................... Input_and_Output_Byte_Enable[3] =0b00000100;
0366: MOVLW 04
0368: MOVWF x61
.................... Input_and_Output_Byte_Enable[4] =0b00001000;
036A: MOVLW 08
036C: MOVWF x62
.................... Input_and_Output_Byte_Enable[5] =0b00010000;
036E: MOVLW 10
0370: MOVWF x63
.................... Input_and_Output_Byte_Enable[6] =0b00100000;
0372: MOVLW 20
0374: MOVWF x64
....................
....................
Code:


Now notice the MOVWF commands. The first two update the variable but the next five do not.

Thanks for any help and sorry for the long post.

DaveThib



Joined: 17 Oct 2004
Posts: 15
Location: New Hampshire USA

View user's profile Send private message

I think I know what the problm is
PostPosted: Sat Jan 20, 2007 9:23 pm     Reply with quote

I have been reading and it looks like the extended instuction set is the problem. The diference between these two modes takes effect at the boundry of 5Fh and 60h and that is where I have the problem. The memory changes below 60h but not at or above it.

So I tried setting the fuses
#FUSES XINST
and
#FUSES NOXINST

And either mode made no difference.

Does anyone know how to get the compiler to either use or do not use this mode?

Here is an excerpt from the datasheet:

the Enabling the PIC18 extended instruction set (XINST
configuration bit = 1) significantly changes certain
aspects of data memory and its addressing. Specifi-
cally, the use of the Access Bank for many of the core
PIC18 instructions is different; this is due to the
introduction of a new addressing mode for the data
memory space. This mode also alters the behavior of
indirect addressing using FSR2 and its associated
operands.
operation.
5.6.2 INSTRUCTIONS AFFECTED BY
INDEXED LITERAL OFFSET MODE
Any of the core PIC18 instructions that can use direct
addressing are potentially affected by the Indexed
Literal Offset Addressing mode. This includes all
byte-oriented and bit-oriented instructions, or almost
DaveThib



Joined: 17 Oct 2004
Posts: 15
Location: New Hampshire USA

View user's profile Send private message

Work Around
PostPosted: Mon Jan 22, 2007 9:25 am     Reply with quote

I was right in that this problem is a problem where the configuration bits are set to the wrong addressing mode. Changing it using the #FUSES directive was making no difference however.

Here is what I did.
I downloaded the software update utility and ran it. So it installed the newest version of the compiler. 4.022. I tried again with no success. So then I got the idea to try MPLAB. So I pulled out my ICD2 (which I brought with me just in case I might need it), compiled it and it ran just perfect! So something in either the IDE software or in the ICD-U40 that is not programming the fuses (configuration bits) properly. I remember having a problem almost two years ago with setting the protect fuse and not being able to clear it to reprogram the part.

I am waiting to hear back from CCS to see if I am doing something stupid. If I get more info I will post it here.
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group