• AVR Freaks

Hot!PIC24FJ64GA002 - program runs in debug mode, in production WDT triggered unexpectedly

Author
KJSmeets
New Member
  • Total Posts : 19
  • Reward points : 0
  • Joined: 2010/09/05 12:18:19
  • Location: the Netherlands
  • Status: offline
2020/09/20 01:33:31 (permalink)
0

PIC24FJ64GA002 - program runs in debug mode, in production WDT triggered unexpectedly

Hello -
 
I have a thing here going on I cannot get my head around.
 
I was investigation unexpected WDT events and set MPLABX IDE (5.35, XC16 v1.50) to break "when watchdog timer has expired".
 
Sure enough - when in debug mode, WDT does not expire and hence no pointers from debug where the issue may be.
 
Are they any 'clever' ways to investigate this further - other than writing a unique ID to non-volatile memory at the start of each function to see where the programs hangs when the WDT times out in production image?
 
#1

6 Replies Related Threads

    ric
    Super Member
    • Total Posts : 28629
    • Reward points : 0
    • Joined: 2003/11/07 12:41:26
    • Location: Australia, Melbourne
    • Status: offline
    Re: PIC24FJ64GA002 - program runs in debug mode, in production WDT triggered unexpectedly 2020/09/20 03:27:40 (permalink)
    0
    As far as I know, the WDT is automatically disabled while in debug mode (as it would interfere with the debug executive), so it's impossible to "break" on it.
     

    I also post at: PicForum
    Links to useful PIC information: http://picforum.ric323.co...opic.php?f=59&t=15
    NEW USERS: Posting images, links and code - workaround for restrictions.
    To get a useful answer, always state which PIC you are using!
    #2
    KJSmeets
    New Member
    • Total Posts : 19
    • Reward points : 0
    • Joined: 2010/09/05 12:18:19
    • Location: the Netherlands
    • Status: offline
    Re: PIC24FJ64GA002 - program runs in debug mode, in production WDT triggered unexpectedly 2020/09/20 03:53:26 (permalink)
    0
    Hi Ric,
     
    thank you for your reply.
    Interesting, then I must be misreading/misinterpreting the MPLAB X IDE user manual here:
    http://ww1.microchip.com/downloads/en/DeviceDoc/50002027E.pdf
    on page 222 i says breakpoint can be inserted on watchdog timer periods ending?
     
    Hope somebody can clarify further.
     
    The performance of the program in debug mode is impeccable - it is supposed to post to a webserver every 10 seconds. In debug mode it never misses a beat. In production 5% of intervals is missed due to a WDT reset.
    The watchdog period is set to 16 seconds.
    #3
    ric
    Super Member
    • Total Posts : 28629
    • Reward points : 0
    • Joined: 2003/11/07 12:41:26
    • Location: Australia, Melbourne
    • Status: offline
    Re: PIC24FJ64GA002 - program runs in debug mode, in production WDT triggered unexpectedly 2020/09/20 03:58:53 (permalink)
    0
    I could well be wrong, I haven't used that particular family.
    Where do you "kick the dog" to reset the WDT?
    What should be the longest interval between kicks?
     
    post edited by ric - 2020/09/20 04:00:12

    I also post at: PicForum
    Links to useful PIC information: http://picforum.ric323.co...opic.php?f=59&t=15
    NEW USERS: Posting images, links and code - workaround for restrictions.
    To get a useful answer, always state which PIC you are using!
    #4
    KJSmeets
    New Member
    • Total Posts : 19
    • Reward points : 0
    • Joined: 2010/09/05 12:18:19
    • Location: the Netherlands
    • Status: offline
    Re: PIC24FJ64GA002 - program runs in debug mode, in production WDT triggered unexpectedly 2020/09/20 04:15:47 (permalink)
    0
    It is kicked by ClrWdt() inside while(1) loop in main();
     
    there are four other calls in that while loop:
    - ApplicationTask() and m2m_wifi_task() from the winc1500 microchip library
    - a call to a very short function without while loop
    - a call to a function that builds the HTTP request - this is fired only every 10 seconds based on  a timer - and querying I2C device in that function. I could reset the I2C bus there (currently not in this function) - but to me that does not explain why this runs flawlessly in debug mode (unless indeed the watchdog timer is not active in debug mode).
     
    I will check BTW if the production code runs fine without the watchdog timer - reason I want the watchdog is to make sure the device is never in hang state because it controls a heating element and I do not want to have it hang in full power (of course there is a thermal fuse there as well for extra security).
    #5
    KJSmeets
    New Member
    • Total Posts : 19
    • Reward points : 0
    • Joined: 2010/09/05 12:18:19
    • Location: the Netherlands
    • Status: offline
    Re: PIC24FJ64GA002 - program runs in debug mode, in production WDT triggered unexpectedly 2020/09/20 07:36:18 (permalink)
    0
    hmmm... seems to be a timing issue...
     
    If I remove the printf calls in below the watchdog not longer gets triggered.
    The second printf seems to be most important one, but just adding the second one is not rock solid.
     
    So apparently it enters the m2m_wifi_task() in a state that it cannot handle...
    Sure enough, as I type this, WDT is triggered with '2' as latest character in the screen, meaning it times out inside m2m_wifi_task()....
     
    Will check for further diagnostics to set somewhere....
     
        while (1)
        {
            printf("1\n\r");
            ApplicationTask();
        
            printf("2\n\r");
            m2m_wifi_task();
            
            //BlinkLed();
            printf("3\n\r");
            SendData();
            printf("4\n\r");
            CheckBoilerPWM();
            printf("5\n\r");
            ClrWdt();

        }

     
     
    #6
    Antipodean
    Super Member
    • Total Posts : 1919
    • Reward points : 0
    • Joined: 2008/12/09 10:19:08
    • Location: Didcot, United Kingdom
    • Status: offline
    Re: PIC24FJ64GA002 - program runs in debug mode, in production WDT triggered unexpectedly 2020/09/20 15:30:22 (permalink)
    0
    KJSmeets
    I will check BTW if the production code runs fine without the watchdog timer - reason I want the watchdog is to make sure the device is never in hang state because it controls a heating element and I do not want to have it hang in full power (of course there is a thermal fuse there as well for extra security).



    never a good idea to leave the heater in the "I am going to cook" state. I would suggest you set up an LED using a timer interrupt to blink it, and then at various points in your code change the blink rate so you get an indication of where the wdt times out, or just put in lots more "pat the dog" statements (kicking the timer isn't politically correct these days grin: grin ).
     
    I wasn't present when this happened, but at a certain place of employment a programmer for UV eraseable EPROMs was made with all the timing done in software. One day a glitch left the EPROM in "i am going to cook" state, which resulted in the bond wires glowing cherry red, and a destroyed chip. after that an edict was issued that the software timing loops were not to be used for critical timing.
     

    Do not use my alias in your message body when replying, your message will disappear ...

    Alan
    #7
    Jump to:
    © 2020 APG vNext Commercial Version 4.5