watch dog timer causes the reboot on SAME70 board

[jwu1980]

Describe the bug
By default, WDT is enabled on SAME70 board because of the following commit. After that, system reboots when doing a while loop processing.

commit 2e01e86
drivers: watchdog: wdt_sam: use the generic disable option
Use the generic option WDT_DISABLE_AT_BOOT instead of the SAM specific
one WDT_SAM_DISABLE_AT_BOOT (note the generic one has been introduced
after the SAM one).
This also have the consequence of changing the default value for yes to
no, fixing the watchdog tests.

To Reproduce
In the hello_world sample, run this code.
#include <zephyr.h>
#include <misc/printk.h>
void main(void)
{
int i = 0;
while(1){
printk("Iteration %d\n", i++);
}
}

Steps to reproduce the behavior:

1. mkdir build; cd build
2. cmake -DBOARD=sam_e70_xplained ../
3. make flash
4. System will reboot around iteration 12347

Expected behavior
No reboot

Impact
System reboots randomly.

Environment (please complete the following information):

• OS: Linux
• Toolchain: Zephyr SDK 0.10.0
• Commit SHA: cfa32af

[ioannisg]

Not sure if this should be treated as a bug; there is an option to disable the watchdog with CONFIG_WDT_DISABLE_AT_BOOT=y if desired so.

We could also select WDT_DISABLE_AT_BOOT in the board definition, if we want this to be the default behavior. @aurel32 do I understand this correctly? What's your take?

[jwu1980]

@ioannisg Thanks for the replay.
Disable the WDT is just a workaround right?
If we need to disable WDT all the time, what’s the reason to have it in the first place?

I would expect WDT can get pet even there is a while loop processing.

[ioannisg]

@f7488405 I am reading the watch dog API

/**
 * @brief Set up watchdog instance.
 *
 * This function is used for configuring global watchdog settings that
 * affect all timeouts. It should be called after installing timeouts.
 * After successful return, all installed timeouts are valid and must be
 * serviced periodically by calling wdt_feed().
 *
 * @param dev Pointer to the device structure for the driver instance.
 * @param options Configuration options as defined by the WDT_OPT_* constants
 *
 * @retval 0 If successful.
 * @retval -ENOTSUP If any of the set options is not supported.
 * @retval -EBUSY If watchdog instance has been already setup.
 */
static inline int wdt_setup(struct device *dev, u8_t options)

So it seems to me that it is the responsibility of the application developer to feed the watchdog periodically. Therefore, your eternal while look in the snipped you posted requires to have a watchdog feed function call. Do you agree?

[jwu1980]

Hi, @ioannisg ,

Thanks for the reply.
From the bug perspective, I didn't call wdt_setup() at all and the issue doesn't happen if I put a k_sleep(1000) in the while loop. If the issue is because user didn't feed the watchdog periodically, adding k_sleep(1000) should still cause WDT to reboot the board, right? The real root cause still needs to be found.

From user experience perspective, if the WDT is enabled by default and all users need to feed the WDT periodically in all applications, that will create a lot of problem and most of user will struggle the reboot issue because they are not aware of this detail.

I would suggest to disable the WDT by default before we root cause the real issue.

What do you think?

Thanks.

Best,

Larry

[mnkp]

Initially #21142 and later #22859 enabled WDT_DISABLE_AT_BOOT option by default on all Atmel SAM boards. As a result the watchdog is disabled. The few sample applications that require watchdog to function explicitly set WDT_DISABLE_AT_BOOT to n. I'm closing this issue.