i.MX7ULP watchdog reset trigger during initialization of watchdog

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

i.MX7ULP watchdog reset trigger during initialization of watchdog

435 Views
bram
Contributor II

I'm sometimes experiencing issues with the watchdog of the i.MX7ULP where when the /dev/watchdog file is accessed for the first time (probably when imx7ulp_wdt_start is called), it triggers a watchdog reset.

From what I have found, some patches have been applied to imx7ulp_wdt.c since the Linux kernel version that we are using (5.4.70). The latest commit that we have is 6371593fbad75cfb9ee14e8b462a5ebb1aa38c02, see: https://github.com/nxp-imx/linux-imx/commits/lf-6.1.y/drivers/watchdog/imx7ulp_wdt.c

I was thinking of backporting the latest patches to my kernel version. However, doing that results in kernel warnings when the watchdog should trigger a reset, as well as the watchdog not working anymore (see trace).

When I read the commit messages, I see that they changed the timeout for waiting for the WDOG_CS_RCS and WDOG_CS_ULK registers. They also changed the timeout according to if the wdog prescaler is enabled. However, I can't find anything in the reference manual that supports these changes. The reference manual states that the bus clock is used during reconfiguring or unlocking the watchdog. The prescaler is enabled in my project, so this matters to me.

So my questions are:

1. Do you know what could be triggering the watchdog reset when i'm accessing the /dev/watchdog file during boot
2. Do I need to increase the timeout in the imx7ulp_wdt.c driver, this is currently 20us in my version.
3. Does selecting a different clock source for the watchdog have impact on the time of the WDOG_CS_ULK and WDOG_CS_RCS sequences
4. Does enabling the prescaler have impact on the time of the unlock and reconfigure sequences
5. What amount of time should I expect to wait for the WDOG_CS_ULK and WDOG_CS_RCS sequences

Increasing the timeout could lead to the kernel warnings that i'm seeing so I want to be sure that the timeout is as low as possible.

Thanks in advance!

 

 

Trace:

[ 368.890849] ------------[ cut here ]------------
[ 368.895527] WARNING: CPU: 0 PID: 424 at kernel/rcu/tree_plugin.h:293 rcu_note_context_switch+0x98/0x4e0
[ 368.904922] Modules linked in:
[ 368.908021] CPU: 0 PID: 424 Comm: reboot Not tainted 5.4.70+g29bee674ebea #1
[ 368.915069] Hardware name: Freescale i.MX7ULP (Device Tree)
[ 368.920688] [<c01104d8>] (unwind_backtrace) from [<c010b540>] (show_stack+0x10/0x14)
[ 368.928459] [<c010b540>] (show_stack) from [<c083ee78>] (dump_stack+0x8c/0xa0)
[ 368.935693] [<c083ee78>] (dump_stack) from [<c0130b1c>] (__warn+0xb4/0xd0)
[ 368.942582] [<c0130b1c>] (__warn) from [<c0130bb4>] (warn_slowpath_fmt+0x7c/0xa8)
[ 368.950074] [<c0130bb4>] (warn_slowpath_fmt) from [<c018a01c>] (rcu_note_context_switch+0x98/0x4e0)
[ 368.959134] [<c018a01c>] (rcu_note_context_switch) from [<c08580f0>] (__schedule+0x84/0x534)
[ 368.967575] [<c08580f0>] (__schedule) from [<c0858600>] (schedule+0x60/0x104)
[ 368.974723] [<c0858600>] (schedule) from [<c085c854>] (schedule_hrtimeout_range_clock+0xe8/0x190)
[ 368.983603] [<c085c854>] (schedule_hrtimeout_range_clock) from [<c085c918>] (schedule_hrtimeout_range+0x1c/0x24)
[ 368.993782] [<c085c918>] (schedule_hrtimeout_range) from [<c085c384>] (usleep_range+0x6c/0x98)
[ 369.002401] [<c085c384>] (usleep_range) from [<c063e5f0>] (imx7ulp_wdt_wait_rcs+0xcc/0x114)
[ 369.010765] [<c063e5f0>] (imx7ulp_wdt_wait_rcs) from [<c063ea44>] (imx7ulp_wdt_enable+0x70/0xd8)
[ 369.019557] [<c063ea44>] (imx7ulp_wdt_enable) from [<c063ebc0>] (imx7ulp_wdt_restart+0x10/0x30)
[ 369.028257] [<c063ebc0>] (imx7ulp_wdt_restart) from [<c063cd40>] (watchdog_restart_notifier+0x18/0x28)
[ 369.037571] [<c063cd40>] (watchdog_restart_notifier) from [<c0152a38>] (atomic_notifier_call_chain+0x64/0x88)
[ 369.047491] [<c0152a38>] (atomic_notifier_call_chain) from [<c010a114>] (machine_restart+0x78/0x7c)
[ 369.056542] [<c010a114>] (machine_restart) from [<c01542ac>] (__do_sys_reboot+0x25c/0x264)
[ 369.064818] [<c01542ac>] (__do_sys_reboot) from [<c0101000>] (ret_fast_syscall+0x0/0x54)
[ 369.072910] Exception stack(0xec9cdfa8 to 0xec9cdff0)
[ 369.077973] dfa0: bed30df4 00000003 fee1dead 28121969 01234567 00000000
[ 369.086158] dfc0: bed30df4 00000003 00000000 00000058 00023108 00000000 00000000 00011fd0
[ 369.094331] dfe0: 00000058 bed30c44 4a5b7bf5 4a53c806
[ 369.099388] ---[ end trace cf4c3d1cda903e49 ]---

 

Labels (1)
Tags (1)
0 Kudos
Reply
1 Reply

403 Views
brian14
NXP TechSupport
NXP TechSupport

Hi @bram

For this problem we recommend updating the BSP version to our latest release:

Embedded Linux for i.MX Applications Processors | NXP Semiconductors

Also, about the watchdog information you could use the datasheet at this link:

Datasheet for iMX7ULP

Best regards, Brian.

 

0 Kudos
Reply