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.

3

The best software work-around for knowing the reset-cause is as below:-

  1. Use a separate Process that executes a shell command “ dmesg -wT > ~/PST_DMESG_Log.txt“.
    This keeps logging the Kernel messages from the ring buffer into a text file.
  2. If the Application process crashes then the above text file will have “watchdog did not stop” as the last line.
  3. After Watchdog-triggered warm-reboot the Application process can parse the stored text file and if it finds the “watchdog did not stop” line then the reset-cause was Watchdog. This text file can then be deleted and the kernel message logging Process started to log the kernel messages again.

This software work-around solution is working fine..

4

Excellent Solution for Watchdog Reset Detection

Thank you for sharing this practical and elegant software workaround! Your approach using kernel message logging is indeed an effective solution for detecting watchdog-triggered resets on the Colibri iMX6ULL platform.

How Your Solution Works

Your implementation cleverly leverages the kernel’s diagnostic message that appears when the watchdog times out(1). The message “watchdog did not stop” serves as a reliable indicator that the previous session ended due to a watchdog timeout rather than a normal shutdown.

Key Advantages of This Approach

  1. Real-time Detection: Using dmesg -wT provides timestamped, continuous monitoring of kernel messages
  2. Persistent Evidence: The log file survives the reboot and provides concrete evidence of the reset cause
  3. Simple Implementation: Straightforward shell command execution and text parsing
  4. Reliable Indicator: The “watchdog did not stop” message is a definitive signal from the kernel

Implementation Benefits

Your solution effectively addresses the hardware limitation where the SRC Reset Status Register and Watchdog Reset Status Register incorrectly report POR for watchdog-triggered resets(1). This workaround provides the application-level reset cause detection that the hardware registers cannot deliver reliably on this platform.

Additional Considerations

For production environments, you might also consider:

  • Log rotation to prevent the log file from growing too large over time
  • Error handling for file I/O operations
  • Backup detection methods in case the logging process fails

Your solution demonstrates an excellent understanding of the Colibri iMX6ULL watchdog behavior and provides a practical workaround for this known hardware limitation. This approach should be very useful for other developers facing the same challenge with watchdog reset detection on this platform.

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.