Does anybody know if we can use this Hardware Watchdog timer and the Application Watch Dog timer at the same time on an Argon or Boron?
I’m thinking of using the Hardware Watchdog in case the Software Watchdog fails.
@RWB, the Application Watchdog is implemented as a FreeRTOS thread so it won’t interfere with the Hardware Watchdog. However, like many other MCUs, you will find that the absolute safest type of watchdog timer is an external hardware device which does a hard reset of the MCU (and possibly other devices).
1 Like
Thanks for clarifying, I didn’t want to assume using both was fine.
It’s nice to have access to the Hardware Watchdog.
Hi,
Really interested in implementing this. Is there an equivalent for the Photon? I have a remote Photon that takes environmental readings and logs the data online every half hour. It sleeps in between readings/postings. It works well but about once a year it drops offline and I have to wait til I can get there to reset it. I have no idea what causes the drops and it happens so rarely it’s difficult to test. If it’s a brief power cut I’d expect it to reboot without issues.
A watchdog for the Photon that can handle the sleep intervals would be great.
Any advice would be amazing
Thanks
D
External Watchdog is your best bet on the Photon.
1 Like
Thanks for the quick response, really appreciate it. I used a TPL5010 on another Photon I deployed so I guess I’ll have to bring this one in and modify the board. Was hoping there was an option I could use without taking the thing down!
D
TPL5010 is a great chip, and I use it on the Boron. I know @chipmc and others here use it as well.
Yes, I use the TPL5010 and have only recently switched.
I ended up moving to a custom watchdog because the TPL5010 does not allow you to “align” the watchdog interrupts to your sleep / wake cycle. I wanted a watchdog that would let the device sleep for an hour without interruption but then reset the device if it failed to wake or got stuck in a loop. The TPL5010 has a fixed interval and “petting” the Done pin does not reset the interval as I had hoped.
Otherwise, excellent chip
1 Like
Thanks for trying the reset pin.
For a decision on internal/external watchdog on a new project under consideration, I found this in the 1.5.2 source src/bootloader/main.c. This is part of the code, deciding what to do on startup.
It seems to be a an old bug likely from never finishing the concept, that multiple watchdog resets always means a firmware transition has gone wrong ending up in DFU mode.
// Get the Bootloader Mode that will be used when IWDG reset occurs due to invalid firmware
volatile uint16_t BKP_DR1_Value = HAL_Core_Read_Backup_Register(BKP_DR_01);
if(BKP_DR1_Value != 0xFFFF)
{
// Check if application requested to enter DFU mode
if (BKP_DR1_Value == ENTER_DFU_APP_REQUEST)
{
USB_DFU_MODE = 1;
//Subsequent system reset or power on-off should execute normal firmware
HAL_Core_Write_Backup_Register(BKP_DR_01, 0xFFFF);
}
else if (BKP_DR1_Value == ENTER_SAFE_MODE_APP_REQUEST)
{
SAFE_MODE = 1;
HAL_Core_Write_Backup_Register(BKP_DR_01, 0xFFFF);
}
// Else check if the system has resumed from IWDG reset
else if (RCC_GetFlagStatus(RCC_FLAG_IWDGRST) != RESET)
{
// These are still initialized to zero, no need to do it again.
// REFLASH_FROM_BACKUP = 0;
// OTA_FLASH_AVAILABLE = 0;
// USB_DFU_MODE = 0;
// FACTORY_RESET_MODE = 0;
switch(BKP_DR1_Value)
{
case FIRST_RETRY: // On 1st retry attempt, try to recover using sFlash - Backup Area
REFLASH_FROM_BACKUP = 1;
BKP_DR1_Value += 1;
break;
case SECOND_RETRY: // On 2nd retry attempt, try to recover using sFlash - Factory Reset
FACTORY_RESET_MODE = 1;
SYSTEM_FLAG(NVMEM_SPARK_Reset_SysFlag) = 0x0000;
BKP_DR1_Value += 1;
break;
case THIRD_RETRY: // On 3rd retry attempt, try to recover using USB DFU Mode (Final attempt)
USB_DFU_MODE = 1;
// fall through - No break at the end of case
// toDO create a location in vector table for bootloadr->app - app->bootloader API.
// add version number to build, and mode (debug,release etc) in vector table
// Then make informed decisions on what to do on WDT timeouts
// for now ran something
case ENTERED_SparkCoreConfig:
case ENTERED_Main:
case ENTERED_Setup:
case ENTERED_Loop:
case RAN_Loop:
case PRESERVE_APP:
default:
BKP_DR1_Value = 0xFFFF;
break;
}
HAL_Core_Write_Backup_Register(BKP_DR_01, BKP_DR1_Value);
OTA_Flashed_ResetStatus();
// Clear reset flags
RCC_ClearFlag();
}
}
else
{
// On successful firmware transition, BKP_DR1_Value is reset to default 0xFFFF
BKP_DR1_Value = 1; //Assume we have an invalid firmware loaded in internal flash
HAL_Core_Write_Backup_Register(BKP_DR_01, BKP_DR1_Value);
}
It seems with a watchdog reset, if BKP_DR1_Value equals 0xFFFF at the first reset, (meaning the last firmware transition went well), it will be set to 1 (meaning it did not go well).
At the next reset if(BKP_DR1_Value != 0xFFFF) will be true (unless changed elsewhere), and the counting of watchdog resets begins in an effort to recover from a non existing situation, and ends up in DFU mode.
I will go with an external watchdog.
2 Likes
Has anyone been able to get WCL’s HW watchdog code to work on an Argon?
I’ve been banging my head against the wall trying to get any of the register writes to “stick” (e.g. when I read registers back after writing them, nothing seems to changes), but have had no luck so far. The watchdog never seems to trigger a reset. I’m using OS 4.0.0.