Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

TPL5111 hardware watchdog timer not suppressible by firmware

Abierto
  • ¿Algo no está bien?
#27 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
30/100
Tipo de issue
Nueva funcionalidad
Claridad
Necesita aclaración
Estado de actividad
Tranquilo
Stack tecnológico
embedded-iot
Área
embedded-iot

Línea de trabajo

Inspect the hardware schematic and PCB connections for the TPL5111, the DONE signal to the ATmega1284P, and the DELAY resistor. Verify the IC designator and resistor value, calculate the current timeout, and determine whether the revision should document firmware feeding or pursue the proposed firmware-controlled enable; done means the timeout and selected approach are confirmed.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

enhancement

Summary

The TPL5111 (nano-power timer) is used as a hardware watchdog that periodically resets the board if the MCU fails to strobe the DONE pin. Once the TPL5111 is active, firmware has no way to disable or extend the timeout beyond the hardware-set interval — if the board needs to perform a long-duration operation (e.g., writing a large log file, waiting for cellular registration, firmware OTA update), it must continuously strobe DONE or risk a spurious reset.

Specific concerns

OTA firmware update:
The Particle B-Series module supports OTA firmware updates. An update can take several minutes depending on cellular conditions. If the TPL5111 timeout is shorter than the OTA window and firmware is unable to strobe DONE while the modem is occupied, the board will reset mid-update, potentially corrupting the firmware image.

Cellular registration:
In poor-signal areas, initial cellular registration (attach + PDP context) can take 2–10 minutes. The ATmega must strobe DONE during this window, which means firmware must handle the TPL5111 feed loop separately from the cellular wait loop.

Long sensor acquisition:
Some sensor integrations (e.g., SDI-12 sensor with long command timeout) block the MCU for extended periods. If these exceed the watchdog interval, a reset occurs.

TPL5111 timeout setting

The timeout is set by a single resistor on the TPL5111 DELAY pin. This is a fixed hardware value and cannot be changed in software.

Recommended approaches

Option A — Firmware must always strobe DONE:
Accept the current design and require firmware to be structured around always being able to strobe DONE within the timeout period. Document the timeout value prominently for firmware authors.

Option B — Add a firmware-controlled enable on TPL5111 (preferred):
The TPL5111 has an active-low enable pin (!EN or equivalent — verify in datasheet). If connected to a GPIO rather than hard-wired to GND, firmware can:

  • Disable the watchdog before entering a long operation
  • Re-enable it afterward
    This is a hardware change requiring a PCB respin.

Option C — Increase the timeout resistor:
Set the DELAY resistor for a longer timeout (maximum is ~7200 s per the datasheet). Longer timeout reduces protection efficacy but reduces the risk of spurious resets during legitimate long operations.

Affected components

  • U? (verify designator): TPL5111 nano-power timer
  • DONE signal connection to IC1 (ATmega1284P) GPIO
  • DELAY resistor (verify designator and value)

Action required for current revision

Confirm the timeout value set by the DELAY resistor and document it. Ensure all planned firmware use cases (OTA, cellular registration, long sensor reads) can feed the watchdog within that interval.

🤖 Generated with Claude Code

Lenguaje dominante
G-code
Estrellas
8
Forks
2
Sin PR fusionados en 30 d

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de NorthernWidget/Project-Okapi

Todos los issues de NorthernWidget/Project-Okapi

Issues similares

Más issues de Embedded & IoT

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.