• AVR Freaks

Hot!There's anyway to know the address where WDT gets triggered?

Author
E_Blue
Super Member
  • Total Posts : 380
  • Reward points : 0
  • Joined: 2009/03/02 18:02:17
  • Location: 0
  • Status: offline
2021/02/23 13:33:59 (permalink)
0

There's anyway to know the address where WDT gets triggered?

MPLAB  X v5.15
Device PIC24FJ1024GB606
I'm having some WDT resets and want to know what address is causing it.
The WDT reset happens after 3 or 4 hours.
Does PIC24FJ save the context or something to know this?
 


Electric Blue
#1

17 Replies Related Threads

    Bob White
    Super Member
    • Total Posts : 360
    • Reward points : 0
    • Joined: 2010/11/06 19:52:38
    • Location: Denver, Colorado
    • Status: offline
    Re: There's anyway to know the address where WDT gets triggered? 2021/02/23 14:12:23 (permalink)
    3.67 (3)
     
    Why do you think a particular address is causing the Watchdog Timer (WDT) to trigger?
     
    I suggest you read up on the Watchdog Timer, how it works, and how you are required to periodically clear it to prevent it from causing a reset.  It would also be a good idea to decide if you really need a watchdog timer or not...
     
    #2
    NKurzman
    A Guy on the Net
    • Total Posts : 19148
    • Reward points : 0
    • Joined: 2008/01/16 19:33:48
    • Location: 0
    • Status: offline
    Re: There's anyway to know the address where WDT gets triggered? 2021/02/23 21:27:27 (permalink)
    4 (1)
    I do not believe the Chip has a trap for the WDT.  so what you want is not available.
    You can Read RCON at boot up to see why you rebooted, BOR, Trap, WDT ect.
    IF it is the WDT you would need to create a "Persistent" variable. then read that and display it after a WDT reset.
    If it is some other type of reset, you can use the debugger to find it.
    #3
    oliverb
    Super Member
    • Total Posts : 409
    • Reward points : 0
    • Joined: 2009/02/16 13:12:38
    • Location: 0
    • Status: offline
    Re: There's anyway to know the address where WDT gets triggered? 2021/02/24 01:23:39 (permalink)
    5 (1)
    If you re-run the test with WDT disabled then does it lock up or keep running.
     
    If it locks up then you're probably looking for an infinite loop problem.
    If it doesn't lock up then somewhere in your code there is too long a delay between WDT resets, which can be hard to identify.
     
    #4
    moser
    Super Member
    • Total Posts : 619
    • Reward points : 0
    • Joined: 2015/06/16 02:53:47
    • Location: Germany
    • Status: offline
    Re: There's anyway to know the address where WDT gets triggered? 2021/02/24 03:46:51 (permalink)
    5 (2)
    I know the PIC32 has the possibility. You can configure a delay before the WDT timeout is causing the device reset, by setting NMICNT in register NMICON. And the WDT timeout generates a NMI (non maskable interrupt), so you can create a handler, which stores as much information as you need (for example in persistent variables), which allows you to identify where the processor was when the WDT happend. But I don't think the PIC24FJ1024GB606 has this or a similar feature.
     
    But as NKurzman suggested, there is another way: You split your program into sections and assign a unique number to every section. Then you create a persistent variable and every time you enter a different program section you set the persistent variable to that number. Directly after a device reset, you check why the reset happened by looking at RCON. If the watchdog caused it, then you create a debug output of the content of that persistent variable. This tells you in which program section the WDT happend. The finer you split program sections and the more unique numbers you assign, the more detailed your result will be.
     
    If your watchdog timeout is caused by some kind of infinite loop problem, this approach you might give you a very good hint, where the problem is located.
     
    However, if your program just sometimes causes a too long delay between WDT resets, then it depends. It might happen, that the WDT happens in the misbehaving program section directly, and the persistent variable shows you the number of that section. But if you are not lucky, the processor already continued with other program sections, and the WDT happens in a random section afterwards. Then the persistent variable will point you into the wrong direction. 
     
    Basically, you only know that your problem is caused either by the section whose number is stored in the persistent variable. Or it was caused by any other section which was executed since the last WDT reset before that section. If you really have bad luck, you get the number of the last section, just before you would have reached the wdt reset, and this tells you nothing.
    #5
    rpg7
    Super Member
    • Total Posts : 1432
    • Reward points : 0
    • Joined: 2003/11/07 12:47:35
    • Status: offline
    Re: There's anyway to know the address where WDT gets triggered? 2021/02/24 03:53:23 (permalink)
    0
    +1 for the persistent variable. Set it to different values as various routines are entered and inspect it on startup (output message to serial port)
    #6
    T Yorky
    Super (Thick) Member
    • Total Posts : 582
    • Reward points : 0
    • Joined: 2012/08/28 02:07:35
    • Location: UK
    • Status: offline
    Re: There's anyway to know the address where WDT gets triggered? 2021/02/24 04:29:51 (permalink)
    4 (1)
    E Blue, you have not really provided much info.
    But the period you identify is suspicious. As above read the watch dog documentation. But look at the default settings for the watchdog. From these calc using your clock freq and I suspect that is the period you are seeing.
    Do you need the watchdog? Do you know how to 'service' the watchdog? Do you know you can switch the watchdog off in the config bits?
    NKurzman is correct about the persistent variable just look up variable attributes in the help pdf. I would go one further and advise to declare a 32bit var. And at the start of your functions copy the program counter to it. This gives a simple trace. If you are familiar with inline assembly you can actually use a MOVD which is 2 clock cycles. If you use a macro for this you can declare the bit of code for debugging or nothing for release version. BUT you need to be able to interrogate the variable on start up to avoid corrupting it.
    MPLab8 was great for finding trap problems, even today MPLabX is no match, so good luck. The 'disassembly listing' is poo poo :(
    #7
    oliverb
    Super Member
    • Total Posts : 409
    • Reward points : 0
    • Joined: 2009/02/16 13:12:38
    • Location: 0
    • Status: offline
    Re: There's anyway to know the address where WDT gets triggered? 2021/02/24 04:39:47 (permalink)
    0
    If you have a debugger connection you might try halting and restarting the program repeatedly and see if there is a pattern to where it halts. If a section of code is taking a long time that will increase the chance it'll be in that section when you stop it.
     
    #8
    E_Blue
    Super Member
    • Total Posts : 380
    • Reward points : 0
    • Joined: 2009/03/02 18:02:17
    • Location: 0
    • Status: offline
    Re: There's anyway to know the address where WDT gets triggered? 2021/02/24 07:09:10 (permalink)
    0
    Hello, thanks for your answers.
    I just disabled the WDT and so far i haven't noticed any halt on the device; so I think there's some long delay in a routine.
    I know how WDT works from 8bit PIC's, but this one have a WWDT.
    Anyway, I'm using it with windowed mode disabled, so, as far I understand, should work as in the 8 bit PICs.
     
    I'm using WDT for two reasons:
    1) When the device is running in battery and the battery is too low I keep the device in low power mode waking up the device every 8 seconds to check if the battery is still low or if the main power is restored and the device can resume to normal mode.
    2)The device is running without human supervision, so, just in case Murphy wanna play with bugs.
     
    @T Yorky
    I agree, MPLAB 8 is better, but, unfortunately, doesn't support this device. :(
    post edited by E_Blue - 2021/02/24 11:07:59


    Electric Blue
    #9
    Chris A
    Super Member
    • Total Posts : 866
    • Reward points : 0
    • Joined: 2010/07/20 04:37:07
    • Location: 0
    • Status: offline
    Re: There's anyway to know the address where WDT gets triggered? 2021/02/24 09:47:32 (permalink)
    4 (1)
    So if it does keep working, and you have an overlong delay somewhere, you could implement a S/W watchdog with half the period of the hardware one using a timer interrupt to increment a count.  That can log the program address to find the offending loop.
     
    Probably worth checking that the H/W watchdog is also the interval that you are expecting!
    post edited by Chris A - 2021/02/24 09:48:59
    #10
    moser
    Super Member
    • Total Posts : 619
    • Reward points : 0
    • Joined: 2015/06/16 02:53:47
    • Location: Germany
    • Status: offline
    Re: There's anyway to know the address where WDT gets triggered? 2021/02/24 10:29:07 (permalink)
    0
    For a windowed watch dog timer you are not only locking for a too long delay, but also for a too short delay.
    If the watchdog clear comes too fast, then you also get a watchdog reset. If some conditions allow to skip huge parts of your code, this might happen.
    #11
    E_Blue
    Super Member
    • Total Posts : 380
    • Reward points : 0
    • Joined: 2009/03/02 18:02:17
    • Location: 0
    • Status: offline
    Re: There's anyway to know the address where WDT gets triggered? 2021/02/24 11:25:00 (permalink)
    0
    The windowed mode is disabled but I'm curious, How I can get a reset when I clear the WDT 200K per second?
    My WDT have an 8 sec period.


    Electric Blue
    #12
    NKurzman
    A Guy on the Net
    • Total Posts : 19148
    • Reward points : 0
    • Joined: 2008/01/16 19:33:48
    • Location: 0
    • Status: offline
    Re: There's anyway to know the address where WDT gets triggered? 2021/02/24 12:54:43 (permalink)
    0
    1. Have you Verified it is a WDT by checking RCON per the Data sheet.
    2. if it is a WDT, that would mean you are getting stuck somewhere in you code for more than 8 seconds.
    #13
    dan1138
    Super Member
    • Total Posts : 4242
    • Reward points : 0
    • Joined: 2007/02/21 23:04:16
    • Location: 0
    • Status: offline
    Re: There's anyway to know the address where WDT gets triggered? 2021/02/24 17:10:20 (permalink)
    0
    E_Blue
    The windowed mode is disabled but I'm curious, How I can get a reset when I clear the WDT 200K per second?

    My WDT have an 8 sec period.

    Using a Windowed WatchDog Timeout(WWDT) reset can be complicated.

    A simple way look at the WWDT is as a contract to reset the timer no earlier than a minimum number and not later than a maximum number of execution cycles. Violations of this contract result in a reset.

    The WWDT can be impossible to implement from an application that has a non-deterministic behavior with respect to execution cycles.

    Microchip does not have an In-Circuit-Debug method to locate the address a WDT timeout occurred in a PIC24FJ1024GB606 controller.

    It is possible to instrument your code to use persistent memory to store the start address of each function when that function is called. When a WDT timeout asserts your reset handler can log the address from the persistent memory to a non-volatile memory.
    post edited by dan1138 - 2021/02/24 17:50:32
    #14
    aschen0866
    Super Member
    • Total Posts : 4593
    • Reward points : 0
    • Joined: 2006/01/08 22:18:32
    • Location: San Diego
    • Status: offline
    Re: There's anyway to know the address where WDT gets triggered? 2021/02/24 18:34:05 (permalink)
    5 (6)
    You can try using a timer interrupt to mimic what the WDT does. You'll periodically reset the timer where you would normally reset the WDT. If the timer interrupt ever occurs, the return address of the ISR would be the address where the WDT bites.
     
    To get the return address from the timer ISR, you'll need to add pre-prologue code to unwind the stack, for example,

    void __attribute__((interrupt(preprologue("call _where_was_i")), no_auto_psv)) _T5Interrupt(void)
    {
    // read _AbortAddressContainer.RetAddr in the ISR
    }

    _where_was_i is an assembly module written by one of the compiler designers.
     

    ; Storage for the exception return address
    ;
    .section *,bss,near
    .global __AbortAddressContainer
    __AbortAddressContainer: .space 4 ; address where the exception occurred
    .space 2 ; previous word of stack data
    ;
    ; Function to read exception return address
    ; from the stack, plus the previous word
    ;
    .text
    .global _where_was_i
    _where_was_i:
    push.d w0
    sub w15,#12,w1 ; twelve bytes pushed since last trap!
    mov [w1], w0
    mov w0, __AbortAddressContainer
    mov [w1+2], w0
    mov.b WREG, __AbortAddressContainer+2
    mov [w1-2], w0
    mov w0, __AbortAddressContainer+4
    pop.d w0
    return
    ;
    ; Tabulation of stack usage since the exception
    ; occurred (read from bottom to top).
    ;
    ; current SP +12
    ;
    ; push w1 +10
    ; where_am_i push w0 +8
    ;
    ; rcall in PC 22->16 +6
    ; handler PC 15->0 +4
    ;
    ; PC 22->16 +2
    ; TRAP! PC 15->0 +0

     
    Search the forum for "_where_was_i", you'll find more examples.
    #15
    moser
    Super Member
    • Total Posts : 619
    • Reward points : 0
    • Joined: 2015/06/16 02:53:47
    • Location: Germany
    • Status: offline
    Re: There's anyway to know the address where WDT gets triggered? 2021/02/25 03:27:47 (permalink)
    5 (2)
    I think following the suggestion of aschen0866 will give you the quickest results, if you can get it running. Given your ratio of 5 micro seconds (= usually 200k WDT clears per second) to 8 seconds (for the watchdog), you will very likely hit the right spot.
     
     
    E_Blue, you described on the one hand, that you get a WDT after a few hours. But on the other hand, without the watchdog you said your program does never get stuck completely. I assume, that you also made sure you don't get any other device reset when you tested without the watchdog, if not, you could try to verify this.
     
    Given these symptoms, this means, that you are probably looking for something, which takes a huge amount of time (at least close to 8 seconds), but which does not loop forever.  Here are some of the issues which I would try to look for:
    • A loop from value x to value y with an assumption like x < y or similar. But due to some error in very rare cases this condition is not true. Therefore, your are looping through the whole integer range.
    • Another example is, you really get into an endless loop. Either because it is intended to wait for a signal which you thought is certain to come. Or an error causes your program to neither make any progress nor abort. But due to some external condition, which might happen after more than 8 seconds, you can get somehow out of that endless loop. For example a changed input pin, or an interrupt which is changing some variables, and somehow this allows you to escape from the "endless loop".
    • A third example would be a algorithm which works correctly, and which is very fast for a typical input value range, but gets expensive for other values. For example, instead of calculating prime factors for values between 2 and 100, you calculate it for INT_MAX.
    #16
    RISC
    Super Member
    • Total Posts : 5983
    • Reward points : 0
    • Status: offline
    Re: There's anyway to know the address where WDT gets triggered? 2021/02/25 06:34:58 (permalink)
    0
    Hi,
    A couple of ideas to think about.
    1/ Unlike the main oscillator, the watchdog internal oscillator has a tolerance of +/-20% => you must take some marin to avoid that watchdog fires due to insufficient margin. eg. if you estimate that the longest path of your SW is x ms, you must set the watchdof to >= 1.2 * x ms
    2/ for the windowed watchdog it is necessay to "evaluate" what is the minimum time your SW will need to execute one loop and maximum time to execute it on top, you need to car about the +/-20% frequency tolerance
     
    The excellent post from  aschen866 will help you to identify exactly what causes this spurious WDT reset which is most probably a hidden bug or unseen path of your SW
    Regards

    For support make sure to check first here : http://microchipdeveloper.com
    There are hundreds of PIC, AVR, SAM...which one do YOU use ?
    #17
    dan1138
    Super Member
    • Total Posts : 4242
    • Reward points : 0
    • Joined: 2007/02/21 23:04:16
    • Location: 0
    • Status: offline
    Re: There's anyway to know the address where WDT gets triggered? 2021/02/25 17:59:51 (permalink)
    4 (1)
    To go with aschen0866 excellent post, attached is a project created with the MPLAB Code Configurator(MCC) that will setup TIMER1 as an interrupt source, clocked from the LPRC clock source that asserts an interrupt after about 2.1 seconds.
     
    This will wake a controller from sleep and "should" make this interrupt behave like the WDT does from sleep mode.
     
    You will need to add the code aschen0866 posted to the interrupt handler to capture where the code was when interrupted and you will need to detect that the interrupt caused a wake up from sleep. Otherwise it would look just like a timeout.
    post edited by dan1138 - 2021/02/25 18:07:34
    #18
    Jump to:
    © 2021 APG vNext Commercial Version 4.5