Colibri iMX6ULL: Any software work-around to detect the correct 'Reset Cause' if reset triggered by Watchdog

Technical Support
,
1

Software summary

Bootloader: U-Boot
Kernel version: 6.6.108-7.4.0-devel #1 SMP PREEMPT Thu Sep 25 09:00:10 UTC 2025
Kernel command line: ubi.mtd=ubi root=ubi0:rootfs rw rootfstype=ubifs ubi.fm_autoconvert=1 console=tty1 console=ttymxc0,115200n8 mtdparts=gpmi-nand:512k(mx6ull-bcb),1536k(u-boot1)ro,1536k(u-boot2)ro,512k(u-boot-env),-(ubi)
Distro name: NAME=“TDX Wayland with XWayland Upstream”
Distro version: VERSION_ID=7.4.0-devel-20251021032930-build.0
Distro variant: -
Hostname: colibri-imx6ull-15591266

Hardware info

HW model: Toradex Colibri iMX6ULL 256/512MB on Colibri Evaluation Board V3
Toradex version: 0036 V1.1A
Serial number: 15591266
Processor arch: armv7l

I understand from various discussions that, because of the way the Watchdog Timeout reset causes a cold-reset through PMIC, the ‘SRC Reset Status Register (SRC_SRSR)‘ always indicates the ‘Reset Cause’ as POR even if reset triggered by Watchdog Timeout. Seems to be same problem with ‘Watchdog Reset Status Register (WDOGx_WRSR)‘. Shown below the console log indicating the problem:

……….
TDX Wayland with XWayland Upstream 7.4.0-devel-20251023161417+build.0 (scarthgap) colibri-imx6ull-15591266 ttymxc0
Colibri-iMX6ULL_Reference-Minimal-Image-upstream

colibri-imx6ull-15591266 login: [ 182.390577] 8<— cut here —
[ 182.393841] Unhandled fault: external abort on non-linefetch (0x1008) at 0xb6faf004
[ 182.401789] [b6faf004] *pgd=8313b835, *pte=020bc703, *ppte=020bce33
[ 276.165612] watchdog: watchdog0: watchdog did not stop!

U-Boot 2024.07-7.4.0-devel+git.3f772959501c (Jul 01 2024 - 18:07:18 +0000)
CPU: Freescale i.MX6ULL rev1.1 528 MHz (running at 396 MHz)
CPU: Commercial temperature grade (0C to 95C) at 41C
Reset cause: POR
DRAM: 256 MiB

In our software application we need to detect if the system reset caused by normal power-cycling or Watchdog Timeout(application crash) and so is there any software work-around to correctly determine the ‘Reset Cause’ after system reboot?

Thanks in advance for your support.

BR,

Vijay.

2

Hi, I’m the Toradex AI Assistant.

I might make mistakes or occasionally get you wrong. Our support team will step in if needed.

Understanding the Watchdog Reset Issue on Colibri iMX6ULL

You’ve identified a known issue with the Colibri iMX6ULL where watchdog timeout resets are not properly reported in the reset cause registers(1). This issue has been confirmed by the Toradex team and affects the ability to distinguish between normal power-on resets and watchdog-triggered resets.

The Root Cause

The problem occurs because the watchdog timeout on the iMX6ULL triggers a system reset through the PMIC, which results in a cold reset that appears identical to a power-on reset (POR)(1). This causes both the SRC Reset Status Register (SRC_SRSR) and Watchdog Reset Status Register (WDOGx_WRSR) to show incorrect reset cause information.

Software Workaround Solutions

Since the hardware registers don’t provide reliable reset cause information for watchdog timeouts, you’ll need to implement a software-based detection mechanism:

1. Application Health Flag Method

  • Create a persistent flag in non-volatile storage (e.g., a file in /var or EEPROM)
  • Set this flag during normal application startup
  • Clear this flag during controlled shutdown
  • After boot, check if the flag is still set:
    • Flag set = Previous session ended unexpectedly (likely watchdog timeout)
    • Flag clear = Normal shutdown occurred

2. Timestamp-Based Detection

  • Store the current timestamp periodically during normal operation
  • After boot, compare the stored timestamp with system uptime
  • A significant gap suggests an unexpected reset

3. U-Boot Environment Variable Method

You can leverage U-Boot’s environment variables for persistent storage(2). The U-Boot documentation shows how to manage environment variables using setenv(2):

  • Set a variable in U-Boot environment before Linux starts
  • Modify this variable from Linux during normal operation
  • Check the variable state after reboot to determine reset cause

Implementation Considerations

For your Colibri iMX6ULL system, consider these factors:

  • Storage Location: Use persistent storage that survives power cycles but can be accessed by your application
  • Timing: Implement the flag management early in your boot process and late in your shutdown sequence
  • Reliability: Include error handling for storage access failures

Status of the Issue

This issue has been reported and acknowledged by the Toradex team(1). While there’s no hardware-level fix available, the software workaround approaches mentioned above provide reliable alternatives for detecting watchdog-triggered resets.

The community discussion indicates this issue persists across different BSP versions, so implementing a software-based solution is currently the most practical approach for distinguishing between normal power cycles and application crashes that trigger watchdog timeouts.

Best regards, Toradex AI Assistant.

Did you like my answer? :+1: :-1:

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.