@web-font-path: "roboto-debian.css";
v2.2.0 (RP2040)
Loading...
Searching...
No Matches
hardware_watchdog

Hardware Watchdog Timer API. More...

## Functions

void | watchdog_reboot (uint32_t pc, uint32_t sp, uint32_t delay_ms)
| Define actions to perform at watchdog timeout.
void | watchdog_start_tick (uint cycles)
| Start the watchdog tick.
void | watchdog_update (void)
| Reload the watchdog counter with the amount of time set in watchdog_enable.
void | watchdog_enable (uint32_t delay_ms, bool pause_on_debug)
| Enable the watchdog.
void | watchdog_disable (void)
| Disable the watchdog.
bool | watchdog_caused_reboot (void)
| Did the watchdog cause the last reboot?
bool | watchdog_enable_caused_reboot (void)
| Did watchdog_enable cause the last reboot?
uint32_t | watchdog_get_time_remaining_us (void)
| Returns the number of microseconds before the watchdog will reboot the chip.
uint32_t | watchdog_get_time_remaining_ms (void)
| Returns the number of milliseconds before the watchdog will reboot the chip.

## Detailed Description

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.

## Example

## Function Documentation

## watchdog_caused_reboot()

bool watchdog_caused_reboot | ( | void |  | ) |

Did the watchdog cause the last reboot?

Returns
  true If the watchdog timer or a watchdog force caused the last reboot
  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.

## watchdog_enable()

void watchdog_enable | ( | uint32_t | delay_ms,
|  | bool | pause_on_debug )

Enable the watchdog.

Note
  If watchdog_start_tick value does not give a 1MHz clock to the watchdog system, then the `delay_ms` parameter will not be in milliseconds. See the datasheet for more details.

On RP2040 the maximum delay is 8388 milliseconds, which is approximately 8.3 seconds (this is due to RP2040-E1).

By default the SDK assumes a 12MHz XOSC and sets the watchdog_start_tick appropriately.

This method sets a marker in the watchdog scratch register 4 that is checked by 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 watchdog_enable_caused_reboot will return false.

Parameters

  delay_ms | Number of milliseconds before watchdog will reboot without watchdog_update being called
  pause_on_debug | If the watchdog should be paused when the debugger is stepping through code

## watchdog_enable_caused_reboot()

bool watchdog_enable_caused_reboot | ( | void |  | ) |

Did watchdog_enable cause the last reboot?

Perform additional checking along with watchdog_caused_reboot to determine if a watchdog timeout initiated by watchdog_enable caused the last reboot.

This method checks for a special value in watchdog scratch register 4 placed there by watchdog_enable. This would not be present if a watchdog reset is initiated by watchdog_reboot or by the RP-series microcontroller bootrom (e.g. dragging a UF2 onto the RPI-RP2 drive).

Returns
  true If the watchdog timer or a watchdog force caused (see watchdog_caused_reboot) the last reboot and the watchdog reboot happened after watchdog_enable was called
  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 watchdog_enable was called. A power on reset is typically caused by a power cycle or the run pin (reset button) being toggled.

## watchdog_get_time_remaining_ms()

uint32_t watchdog_get_time_remaining_ms | ( | void |  | ) |

Returns the number of milliseconds before the watchdog will reboot the chip.

On RP2040 this method returns the last value set instead of the remaining time due to a h/w bug.

Returns
  The number of milliseconds before the watchdog will reboot the chip.

## watchdog_get_time_remaining_us()

uint32_t watchdog_get_time_remaining_us | ( | void |  | ) |

Returns the number of microseconds before the watchdog will reboot the chip.

On RP2040 this method returns the last value set instead of the remaining time due to a h/w bug.

Returns
  The number of microseconds before the watchdog will reboot the chip.

## watchdog_reboot()

void watchdog_reboot | ( | uint32_t | pc,
|  | uint32_t | sp,
|  | uint32_t | delay_ms )

Define actions to perform at watchdog timeout.

Note
  If watchdog_start_tick value does not give a 1MHz clock to the watchdog system, then the `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 watchdog_start_tick appropriately.

Parameters

  pc | If Zero, a standard boot will be performed, if non-zero this is the program counter to jump to on reset.
  sp | If `pc` is non-zero, this will be the stack pointer used.
  delay_ms | Initial load value. Maximum value 8388, approximately 8.3s.

## watchdog_start_tick()

void watchdog_start_tick | ( | uint | cycles | ) |

Start the watchdog tick.

Parameters

  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.