Hot!Difference in Behavior in Debug and Run/Free mode

Author
hariprasath
New Member
  • Total Posts : 5
  • Reward points : 0
  • Joined: 2018/09/29 06:56:50
  • Location: 0
  • Status: offline
2018/10/31 07:13:11 (permalink)
0

Difference in Behavior in Debug and Run/Free mode

Hi,
I am using PIC18f45k80 controller and XC8 compiler. I have written code for LCD interface.
void LCDPutString(char *string)
I am using this function for displaying string like
LCDPutString("Hello");
What i find is when i run the application in Debug mode, string is displayed correctly on LCD.
but when run in free/run mode the same piece of code displays junk character on LCD(same number of bytes available as in string passed to the function)
Similarly i interface RTC and EEPROM using I2C interface. In debug mode both RTC and EEPROM work fine i.e EEPROM writes and reads correctly and RTC shows correct time but the same doesn't work in Free/Run mode.

I want to know what may be reason for such different behavior in debug and run mode.
#1

14 Replies Related Threads

    keto
    Starting Member
    • Total Posts : 32
    • Reward points : 0
    • Joined: 2018/08/28 06:30:20
    • Location: 0
    • Status: offline
    Re: Difference in Behavior in Debug and Run/Free mode 2018/10/31 07:21:34 (permalink)
    +1 (1)
    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.
    #2
    jack@kksound
    code tags!
    • Total Posts : 2912
    • Reward points : 0
    • Joined: 2014/05/14 10:03:19
    • Location: 0
    • Status: offline
    Re: Difference in Behavior in Debug and Run/Free mode 2018/10/31 08:14:07 (permalink)
    +1 (1)
    What Debug hardware are you using? pickit 3 or something else?
    #3
    qhb
    Superb Member
    • Total Posts : 7990
    • Reward points : 0
    • Joined: 2016/06/05 14:55:32
    • Location: One step ahead...
    • Status: online
    Re: Difference in Behavior in Debug and Run/Free mode 2018/10/31 18:48:57 (permalink)
    +1 (1)
    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.
     
    #4
    hariprasath
    New Member
    • Total Posts : 5
    • Reward points : 0
    • Joined: 2018/09/29 06:56:50
    • Location: 0
    • Status: offline
    Re: Difference in Behavior in Debug and Run/Free mode 2018/10/31 23:20:33 (permalink)
    0
    I am using pickit 3
    #5
    hariprasath
    New Member
    • Total Posts : 5
    • Reward points : 0
    • Joined: 2018/09/29 06:56:50
    • Location: 0
    • Status: offline
    Re: Difference in Behavior in Debug and Run/Free mode 2018/11/01 10:55:00 (permalink)
    0
    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
     
    #6
    qhb
    Superb Member
    • Total Posts : 7990
    • Reward points : 0
    • Joined: 2016/06/05 14:55:32
    • Location: One step ahead...
    • Status: online
    Re: Difference in Behavior in Debug and Run/Free mode 2018/11/01 12:28:39 (permalink)
    0
    Your symptoms sound very similar to a known errata with K40 chips.
    Can you confirm again that it is actually a PIC18f45k80 that you are using?
     
    #7
    hariprasath
    New Member
    • Total Posts : 5
    • Reward points : 0
    • Joined: 2018/09/29 06:56:50
    • Location: 0
    • Status: offline
    Re: Difference in Behavior in Debug and Run/Free mode 2018/11/01 13:03:28 (permalink)
    0
    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.
    #8
    qhb
    Superb Member
    • Total Posts : 7990
    • Reward points : 0
    • Joined: 2016/06/05 14:55:32
    • Location: One step ahead...
    • Status: online
    Re: Difference in Behavior in Debug and Run/Free mode 2018/11/01 14:22:05 (permalink)
    +1 (1)
    hariprasath
    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

    If it couldn't find it, you would get a compile error, so stop worrying on that score.
     
    As I mentioned, all the rest of your symptoms (constant strings not being read properly), sound just like the "NVMREG" errata that occurs in K40 chips.
    See: https://www.microchip.com/forums/m969418.aspx
    However I have never heard of this occurring in a K80 chip.
     
    #9
    Aussie Susan
    Super Member
    • Total Posts : 3374
    • Reward points : 0
    • Joined: 2008/08/18 22:20:40
    • Location: Melbourne, Australia
    • Status: offline
    Re: Difference in Behavior in Debug and Run/Free mode 2018/11/01 18:27:35 (permalink)
    +1 (1)
    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
    #10
    qhb
    Superb Member
    • Total Posts : 7990
    • Reward points : 0
    • Joined: 2016/06/05 14:55:32
    • Location: One step ahead...
    • Status: online
    Re: Difference in Behavior in Debug and Run/Free mode 2018/11/01 18:38:44 (permalink)
    +1 (1)
    That's the version that works, so they must be getting a NULL at the end just by luck rather than good planning. ;)
     
    #11
    Aussie Susan
    Super Member
    • Total Posts : 3374
    • Reward points : 0
    • Joined: 2008/08/18 22:20:40
    • Location: Melbourne, Australia
    • Status: offline
    Re: Difference in Behavior in Debug and Run/Free mode 2018/11/04 20:24:11 (permalink)
    +1 (1)
    Hence my use of '(deliberately)'!
    Susan
    #12
    Trackhappy
    New Member
    • Total Posts : 27
    • Reward points : 0
    • Joined: 2016/11/03 16:07:08
    • Location: 0
    • Status: offline
    Re: Difference in Behavior in Debug and Run/Free mode 2018/11/06 19:19:35 (permalink)
    0
    I am a newbie and I had somewhat similar symptoms when I started playing with an LCD. I had downloaded some sample code that looked understandable to my newbie brain and I eventually figured out he was not writing to the latch. When the PicKit 3 was connected it did something that made it better. Changing the code to write to latch as it should have been, fixed it. Only mentioned it in case you found the same example code.
    Cheers,
    Glenn.
    #13
    Aussie Susan
    Super Member
    • Total Posts : 3374
    • Reward points : 0
    • Joined: 2008/08/18 22:20:40
    • Location: Melbourne, Australia
    • Status: offline
    Re: Difference in Behavior in Debug and Run/Free mode 2018/11/07 18:17:33 (permalink)
    +2 (2)
    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
    #14
    jack@kksound
    code tags!
    • Total Posts : 2912
    • Reward points : 0
    • Joined: 2014/05/14 10:03:19
    • Location: 0
    • Status: offline
    Re: Difference in Behavior in Debug and Run/Free mode 2018/11/08 16:03:57 (permalink)
    +1 (1)
     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.

    I do not think the analog mode affects the output capability of the ports, only the digital input. LATx registers will still drive the output pin hi/lo when the input mode is analog. Analog mode does of course mess with digital reads so any RMW operations on the PORTx registers will be affected (always read zeros) and digital reads from PORTx also read zero always.
    #15
    Jump to:
    © 2018 APG vNext Commercial Version 4.5