int wdt_fd = open("/dev/watchdog", O_WRONLY);
failed, return -1, the error string is :
intel_scu_watchdog_evo: watchdog device is busy
I have found the source code of watchdog-sampl
the program is a sample service to show how to using sd_notify to watch a service.
It is not using hardware watchdog.
how to use the hardware watchdog? the file "/dev/watchdog"? why open the file fail?
the process runing include the following :
Should I use the watchdog configure file to config the systemd service to do some watchdog checking?
But threre are no such files in edison disk?
Currently, there are no official documents on how to configure the watchdog for the Edison. We are working on more documentation about the SOC and different features but there is no ETA yet.
Have you already tried with the files in /sys/devices/virtual/misc/watchdog ?
Do you want to disable the wathdog or you which is the goal you have?
I want to use hardware watchdog.
As a embeded device, need a hardware watchdog to keep the device stable.
I have check the folder /sys/devices/virtual/misc/watchdog, but don't know what to do with it.
So Need a document about watchdog.
CMata_Intel, Thank you very much.
We are facing some weird unexpected reboots on the Edison that might have to do with the watchdog.
We are doing the following loop:
1 Put the atom to sleep with the 'echo "mem" > /sys/power/state' command.
2 The MCU will kick in and gather some data from i2c sensors.
3 MCU will wake up the atom processor using host_send directive, and transfer all gathered data.
4 The atom will process data
After a few hours of doing the cycle (each last about 40s), eventually the Edison crashes and reboots. On the 'panic' file of crashlog_XXX.tar.gz we find the following:
[11281.958722] PM: Entering mem sleep
[11281.959002] Suspending console(s) (use no_console_suspend to debug)
[11282.088594] snd_intel_sst: runtime_resume called
[11282.111794] snd_intel_sst: runtime_suspend called
[11282.112128] bcmsdh_sdmmc_suspend Enter
[11282.112134] bcmsdh_sdmmc_suspend Enter
[11282.112144] bcmsdh_sdmmc_suspend Enter
[11282.113477] bcove_thrm bcove_thrm: suspend called.
[11282.179938] PM: suspend of devices complete after 70.328 msecs
[11282.181254] PM: late suspend of devices complete after 1.300 msecs
[11282.408502] PM: noirq suspend of devices complete after 227.153 msecs
[11282.408511] Disabling non-boot CPUs ...
[11282.410939] smpboot: CPU 1 is now offline
[11282.412218] SC device/devices not in d0i3!!
[11282.412229] pmu2_states = FFFFFFFC
[11282.412236] pmu2_states = FFFFFFFF
[11282.412242] pmu2_states = FFFFFF3F
[11282.412247] pmu2_states = FFFFFFFF
[11313.565492] wakeup from IRQ 47
[11313.565507] IRQ 47,action name:intel_psh_ipc
[11332.589347] PM: Entering mem sleep
[11332.589619] Suspending console(s) (use no_console_suspend to debug)
[11332.719107] snd_intel_sst: runtime_resume called
[11407.297842] intel_scu_watchdog_evo: [SHTDWN] watchdog_warning_interrupt, WATCHDOG TIMEOUT!
[11407.299437] Kernel panic - not syncing: Kernel Watchdog
The first part of the log shows when the atom is going to sleep and is waked up due to IRQ47, as expected. But the on the last time we issue the sleep command the watchdog interruption is triggered and the Edison crashes and reboots.
Any insights of what is happening? I feel that the watchdog is getting misconfigured somehow...
Which image are you using on the board?
The mem and freeze states are not working so the problems you have could be related with the usage of these states.
If you process the data from i2c withouth putting the atom to sleep, do you still have issues?
Thanks for the response Charlie,
We are using the image-280915 version along with the patch from this other threadRe: Putting the Edison into and taking it out of Standby?. If we process the data without putting the edison to sleep no issues are present. With the sleep part included, the crashes are generated 3 to 5 hours after starting the edison and the program.
I think the 3.0 release is out now, do you know if the sleep support is working out of the box?
I’m able to run the mem and freeze states on the 3.0 release only it I stop & disable the wpa_supplicant with systemctl. If you want to use WiFi you will need to use connman to configure the interface, so you will have to start & enable the service with systemctl.
$sytemctl stop wpa_supplicant
$systemctl disable wpa_supplicant
$systemctl start connman
$systemctl enable connman
>connect <wifi_*Respective Item*>
$echo –n mem > /sys/power/state
Let me know if this works for you too.
Yocto 3.0 image is released and I can put the Edison into sleep mode. However, there is a difference between the first time and the second time sleeping in current consumption. For example, at the first time sleeping, it just consumes about 2mA. But it consumes 5mA at the next time sleeping. So how can I fix this issue ?
I’m able to run the states if I stop and disable the wpa_supplicant service with systemctl, but as I said before the mem and freeze states are not currently working as they should in the image, so this is the reason why you can get some problems while using them.
My application requires to have a wifi connection after waking up the Atom from its sleep state and after rebooting. I used connman to configure the interface, as you had suggested previously, but after typing systemctl start wpa_supplicant or after rebooting the wpa_state was inactive.
So I tried configure_edison --wifi since on the 2.1 release there was no issue establishing a wifi connection after typing systemctl start wpa_supplicant or after rebooting. However, on the 3.0 release I do not get an IP in both cases, and I have to type udhcpc -i wlan0 -n in order to get an IP.
Could there be anything missing on the configure_edison script of the 3.0 release that is preventing getting an IP in the two described cases?
The command I ran on the 3.0 release was configure_edison --setup, not configure_edison --wifi, since I want to save the wifi setup between reboots.
Looking forward to your response.
Could you please give me some help about this problem ? How can I fix it ?
Thank you so much,