blob: e6adf65afc9acb5d09c65034423df04999dd3ba5 [file] [log] [blame]
/*
* Copyright (c) 2020 Raspberry Pi (Trading) Ltd.
*
* SPDX-License-Identifier: BSD-3-Clause
*/
#ifndef _HARDWARE_WATCHDOG_H
#define _HARDWARE_WATCHDOG_H
#include "pico.h"
#include "hardware/structs/watchdog.h"
/** \file hardware/watchdog.h
* \defgroup hardware_watchdog hardware_watchdog
*
* \brief Hardware Watchdog Timer API
*
* Supporting functions for the Pico hardware watchdog timer.
*
* The RP-series microcontrollers have a built in HW watchdog Timer. This is a countdown timer that can restart parts of the chip if it reaches zero.
* For example, this can be used to restart the processor if the software running on it gets stuck in an infinite loop
* or similar. The programmer has to periodically write a value to the watchdog to stop it reaching zero.
*
* \subsection watchdog_example Example
* \addtogroup hardware_watchdog
* \include hello_watchdog.c
*/
#ifdef __cplusplus
extern "C" {
#endif
// PICO_CONFIG: PARAM_ASSERTIONS_ENABLED_HARDWARE_WATCHDOG, Enable/disable assertions in the hardware_watchdog module, type=bool, default=0, group=hardware_watchdog
#ifndef PARAM_ASSERTIONS_ENABLED_HARDWARE_WATCHDOG
#ifdef PARAM_ASSERTIONS_ENABLED_WATCHDOG // backwards compatibility with SDK < 2.0.0
#define PARAM_ASSERTIONS_ENABLED_HARDWARE_WATCHDOG PARAM_ASSERTIONS_ENABLED_WATCHDOG
#else
#define PARAM_ASSERTIONS_ENABLED_HARDWARE_WATCHDOG 0
#endif
#endif
/*! \brief Define actions to perform at watchdog timeout
* \ingroup hardware_watchdog
*
* \note If \ref watchdog_start_tick value does not give a 1MHz clock to the watchdog system, then the \p delay_ms
* parameter will not be in milliseconds. See the datasheet for more details.
*
* By default the SDK assumes a 12MHz XOSC and sets the \ref watchdog_start_tick appropriately.
*
* \param pc If Zero, a standard boot will be performed, if non-zero this is the program counter to jump to on reset.
* \param sp If \p pc is non-zero, this will be the stack pointer used.
* \param delay_ms Initial load value. Maximum value 8388, approximately 8.3s.
*/
void watchdog_reboot(uint32_t pc, uint32_t sp, uint32_t delay_ms);
/*! \brief Start the watchdog tick
* \ingroup hardware_watchdog
*
* \param cycles This needs to be a divider that when applied to the XOSC input, produces a 1MHz clock. So if the XOSC is
* 12MHz, this will need to be 12.
*/
void watchdog_start_tick(uint cycles);
/*! \brief Reload the watchdog counter with the amount of time set in watchdog_enable
* \ingroup hardware_watchdog
*
*/
void watchdog_update(void);
/**
* \brief Enable the watchdog
* \ingroup hardware_watchdog
*
* \note If \ref watchdog_start_tick value does not give a 1MHz clock to the watchdog system, then the \p delay_ms
* parameter will not be in milliseconds. See the datasheet for more details.
*
* By default the SDK assumes a 12MHz XOSC and sets the \ref watchdog_start_tick appropriately.
*
* This method sets a marker in the watchdog scratch register 4 that is checked by \ref watchdog_enable_caused_reboot.
* If the device is subsequently reset via a call to watchdog_reboot (including for example by dragging a UF2
* onto the RPI-RP2), then this value will be cleared, and so \ref watchdog_enable_caused_reboot will
* return false.
*
* \param delay_ms Number of milliseconds before watchdog will reboot without watchdog_update being called. Maximum of 8388, which is approximately 8.3 seconds
* \param pause_on_debug If the watchdog should be paused when the debugger is stepping through code
*/
void watchdog_enable(uint32_t delay_ms, bool pause_on_debug);
/**
* \brief Disable the watchdog
* \ingroup hardware_watchdog
*/
void watchdog_disable(void);
/**
* \brief Did the watchdog cause the last reboot?
* \ingroup hardware_watchdog
*
* @return true If the watchdog timer or a watchdog force caused the last reboot
* @return false If there has been no watchdog reboot since the last power on reset. A power on reset is typically caused by a power cycle or the run pin (reset button) being toggled.
*/
bool watchdog_caused_reboot(void);
/**
* \brief Did watchdog_enable cause the last reboot?
* \ingroup hardware_watchdog
*
* Perform additional checking along with \ref watchdog_caused_reboot to determine if a watchdog timeout initiated by
* \ref watchdog_enable caused the last reboot.
*
* This method checks for a special value in watchdog scratch register 4 placed there by \ref watchdog_enable.
* This would not be present if a watchdog reset is initiated by \ref watchdog_reboot or by the RP-series microcontroller bootrom
* (e.g. dragging a UF2 onto the RPI-RP2 drive).
*
* @return true If the watchdog timer or a watchdog force caused (see \ref watchdog_caused_reboot) the last reboot
* and the watchdog reboot happened after \ref watchdog_enable was called
* @return false If there has been no watchdog reboot since the last power on reset, or the watchdog reboot was not caused
* by a watchdog timeout after \ref watchdog_enable was called.
* A power on reset is typically caused by a power cycle or the run pin (reset button) being toggled.
*/
bool watchdog_enable_caused_reboot(void);
/**
* \brief Returns the number of microseconds before the watchdog will reboot the chip.
* \ingroup hardware_watchdog
*
* \if rp2040_specicifc
* On RP2040 this method returns the last value set instead of the remaining time due to a h/w bug.
* \endif
*
* @return The number of microseconds before the watchdog will reboot the chip.
*/
uint32_t watchdog_get_time_remaining_ms(void);
// backwards compatibility with SDK < 2.0.0
static inline uint32_t watchdog_get_count(void) {
return watchdog_get_time_remaining_ms();
}
#ifdef __cplusplus
}
#endif
#endif