0

I am currently working on a project using arduino Due (Atmel SAM3X8E), which hit a watchdog reset randomly. (sometimes it reset in 10 minutes, sometimes it runs hours then hit the watchdog reset). My watchdog time-out is set fairly long(7 sec.)

The project has grown fairly big now, and I dont have a debugger(also no debugger is available for arduino code)

And unfortunately I have no idea where the program can be stocked.

What would you guys suggest to do in this situation?

====================Update 01:======================

Now I am going to use watchdog interrupt to give me more information when watchdog is triggered. I had some research in internet and wrote following code for the setup. But it does not work...

My expect that when I create a while(1){}, the watchdog will be triggered, and through WDT_handler() I can get some debugging message, which later on I can put maybe more useful debugging information. But in the real case. I did not get any message, so I assume that the WDT_handler was not performed at all.

Could anyone have a look and help me to figure out what the problem is?

watchdog setup:

inline static void startWatchdog() 
{
    //WDT_Enable(WDT, WDT_MR_WDRSTEN | WATCHDOG_INTERVAL );
    uint32_t timeout = 8000 * 256 / 1000; //8000ms = 8s
    if (timeout == 0) timeout = 1;
    else if (timeout > 0xFFF) timeout = 0xFFF;
    timeout = WDT_MR_WDRSTEN | WDT_MR_WDV(timeout) | 
    WDT_MR_WDD(timeout)|WDT_MR_WDFIEN;

    WDT_Enable (WDT, timeout);       

    /* Configure and enable WDT interrupt. */
    NVIC_DisableIRQ(WDT_IRQn);
    NVIC_ClearPendingIRQ(WDT_IRQn);
    NVIC_SetPriority(WDT_IRQn, 0);
    NVIC_EnableIRQ(WDT_IRQn);       
}

And I have a watchdog handler

void WDT_Handler(void) 
{
    /* Clear status bit to acknowledge interrupt by dummy read. */
    WDT_GetStatus(WDT);
        
    print("help! in WDT");
}

===========================Update 02:=====================

I found out where the problem is! If I want to use Interrupt handler, I should not use WDT_MR_WDRSTEN. It would reset the processor immediately, that is why the WDT_handler did not run. (I guess)

==========Update 03: ========================

I tried to catch return address from stack pointer inside the WDT_Handler. using following code:

uint32_t returnAddr;
// IRQ handler for WDT
void WDT_Handler() 
{
    returnAddr = __get_MSP();
    Com::printFLN(PSTR("return addr: "),returnAddr);
}

Yes, I got some number: 0x20087F28. And I check the disassembly of my project by using arm-none-eabi-objdump.exe to decode my .elf file. And I could not find any address, which is pointing to this number 0x20087F28

Am I doing something wrong here?

Wenfang Du
  • 8,804
  • 9
  • 59
  • 90
MinShu Huang
  • 53
  • 1
  • 2
  • 12
  • Start by checking every loop. 7 seconds is a very long time, so one of the loops is not exiting. Loops related to any kind of input would be on top of my list. The problem could also be from an ISR not resetting its interrupt flag. Sorry, if these sound like generic answers, but it's difficult to answer such a wide-ranging question. You could also try debugging with atmel-studio, which supports arduino projects. If it's worth the effort. – Michaël Roy Aug 28 '17 at 18:15
  • Thank you Michael for your comments – MinShu Huang Sep 01 '17 at 09:23
  • Thank you Michael for your comments, I will try that. I would like to know, can a watchdogReset only be triggered by unappropriate software loop? Or is there also other reason to make the software stock then triggering the watchdogReset? like hardware related voltage-spike, memory-overflow...etc So far as I know, atmel-studio does not provide debugging environment for 32bit arduino-DUE program. So I am kind of helpless in that regards. – MinShu Huang Sep 01 '17 at 09:35
  • Well, the usual way to use a watchdog, is to reset its timer in the main loop. Voltage spikes and the like can reset the chip, even when the WDT is not used. If you can spare a pin, you should use it to monitor the RSTTYP status bits on reboot, to make sure the reset is due to the WDT triggering. See section 12.5.2 of the datasheet. – Michaël Roy Sep 01 '17 at 14:06

0 Answers0