Difference in Behavior in Debug and Run/Free mode

Your LCD has a frequency that it can receive.Do you send at same frequency it can receive?If you send in highest frequencies then propably it cant procced in time the data you send and displays junk.

Debug mode sets some ports to digital mode that would normally power up in analog mode.
If that stops your code working, then it's a bug in your code, not doing things it should.
Hard to be more specific without actually seeing your code.
 

Hi,
i have compared clock frequency in both debug and free/run mode and found it to be same.
Regarding LCD issue, I have done different tests and got below inference
1)strcpy is not able to copy the string in run mode
char str[20];
strcpy(str,"Water");
LCDPutString(str);
It displays junk character in Run/free mode but displays correctly "Water" in debug mode
I am not sure if strcpy definition is gets added in run mode. i have added string.h but not sure if compiler is able to find definition
 
2)when i use following code then it displays correctly "98745" on LCD in both debug and run mode
char str[20];
str[0]='9';str[1]='8';str[2]='7';str[3]='4';str[4]='5';
LCDPutString(str);
 
3)when i use 
LCDPutString("hello);
it displays 5 junk characters in run mode but displays "hello" correctly in debug mode.
 
4)when i use below code then it displays correctly in both debug and run modes
char str[20]="hello";
LCDPutString(str);
 

void LCDPutString( char *string)
{
  char loop;
  for (loop = 0; loop < 5; loop++)//just displaying 5 characters at the moment for test, using sizeof instead to get string length
  {
  LCD_Write_character(string[loop]);// Write the character to the LCD
  halMcuWaitMs(5); 
  LCDX_Pos++;
  if (LCDX_Pos >= 16)// Have we reached the end of the line?
  {
   LCDX_Pos= 0;// Move to the start of the next line
   LCDY_Pos++;
   if (LCDY_Pos >= 2)// If we are off the bottom of the screen go back to the top line
                LCDY_Pos = 0;
   LCDGoto(LCDX_Pos, LCDY_Pos);// Adjust the cursor position on the LCD
  }
 }
}

 
Regarding EEPROM and RTC, it works correctly in debug mode but fails to give correct data in run mode.
I am not able to understand where the problem is.
I have changed controller to PIC18F46K80 now mainly to get larger flash size but i get inference as above. My code size is just 47% program memory in this controller
 
When i used PIC18F45K80, my code size was 92% and hence i went for higher flash. however, i noticed that in PIC18F45K80 following code was displaying correctly in both debug and run mode
char str[20];
strcpy(str,"Water");
LCDPutString(str);
 
but when i used on PIC18F45K80
LCDPutString("hello");
it displays 5 junk characters in run mode but diplays "hello" in debug mode
 

Yes, earlier i was using PIC18F45K80(on which code size reached 92%) but now i have changed my controller to PIC18F46K80. I switched to PIC18F46K80 thinking that higher code size maybe affecting in PIC18F45K80. 
I had forgot to mention clearly
Below are result in PIC18F46K80
1)strcpy is not able to copy the string in run mode
char str[20];
strcpy(str,"Water");
LCDPutString(str);
It displays junk character in Run/free mode but displays correctly "Water" in debug mode
I am not sure if strcpy definition is gets added in run mode. i have added string.h but not sure if compiler is able to find definition
 
2)when i use following code then it displays correctly "98745" on LCD in both debug and run mode
char str[20];
str[0]='9';str[1]='8';str[2]='7';str[3]='4';str[4]='5';
LCDPutString(str);
 
3)when i use 
LCDPutString("hello);
it displays 5 junk characters in run mode but displays "hello" correctly in debug mode.
 
4)when i use below code then it displays correctly in both debug and run modes
char str[20]="hello";
LCDPutString(str);
 
Below are result in PIC18F45K80
following code was displaying correctly in both debug and run mode
char str[20];
strcpy(str,"Water");
LCDPutString(str);
 
but when i used
LCDPutString("hello");
it displays 5 junk characters in run mode but diplays "hello" in debug mode
RTC and EEPROM both do not work in run mode but both works well in debug mode in both series of controller.
 
Apart from above, I also noted that even if i do not enable capture on some of the pin and just configure as digital input(on RD2), i get PWM signal. I disabled all capture related registers but still it didn't solve.

hariprasath
2)when i use following code then it displays correctly "98745" on LCD in both debug and run mode
char str[20];
str[0]='9';str[1]='8';str[2]='7';str[3]='4';str[4]='5';
LCDPutString(str);

This code has a fundamental flaw - you are not (deliberately) terminating the string: add "str[5] = '\0';" to make sure that the 'LCDPutCtring' function (which, by the name, expects a C string which further means that it must be a null-terminated character sequence).
What it will do is to continue to output characters to the LCD until it does encounter a null character. This could give rise to unpredictable behaviour.
Susan

Hence my use of '(deliberately)'!
Susan

Glenn - this may well be a different problem to the one being discussed i this thread. The general advice is to not try to hijack a thread but to start a new one.
There are some fundamental but hidden differences between using 'release' mode and 'debug' mode.
In 'release' mode, the device operates exactly as described in the data sheet, particularly with regard to how the various registers are initialised at the  POR (power on reset). Also the code that you right is the code that is run as the device comes out of reset.
In 'debug' mode, the linker adds in a bit of code called the 'Debug Kernel' and this is the code that interacts with the IDE debugger to show you variable values, set and respond to breakpoints etc.. The 'debug kernel' does a couple of things behind the scenes that are fairly obvious (such as taking over the pins used to communicate with the IDE) but also some things that are unexpected.
In particular, the 'debug kernel' will set all analog-capable pins to 'digital' mode, whereas the default POR setting is 'analog'. The usual way this shows itself is when code works under the debugger but not in 'release' mode (and vice versa) - the programmer has not set the 'analog/digital' mode correctly.
The golden rule is that you should always set the analog/digital state of all pins you use.
In your case, you possibly had not set the pins to 'digital' mode and so it did not work in 'release' mode - in 'analog' mode the pin is always assumed to be an input. However when you added the PicKit3 and used 'debug' mode, the 'debug kernel' set the pins to 'digital' mode which meant that the LAT registers could drive the pin as expected.
Susan