It seems to work well for me, and is a quite neat solution. I added a ‘boot status’ command to show the status of the last boot, including the count of reboots.

Regarding differentiating between ‘module reset’ and another type of reset, I think we can now simply add a bool to boot_data_t and have ‘module reset’ set it before resetting. It can then be picked up during boot (reason SW_CPU_RESET, and check for this flag) to pickup on this specific case. If it is a SW_CPU_RESET and this flag is not set, then we can assume it was a crash.

With this, I think we can do some more sophisticated logic. The ‘first ten seconds’ flag goes in boot_data_t. We can also keep a count of failure resets during first 10 seconds, and if it exceeds say 5 then turn off auto init (but with a setting just in ram, leaving the config 'auto init' to indicate whether the user wants init to be auto or not).

Workable?

Regards, Mark.

On 26 Feb 2018, at 3:51 AM, Michael Balzer <dexter@expeedo.de> wrote:

First version of the auto init system is in the hub.

As discussed, I added an "auto" config param. It currently has these instances:

Instance                Default           Remark
----------------------------------------------------------------------
init                    yes

wifi.mode               ap                off|ap|client
wifi.ssid.ap            OVMS
wifi.ssid.client        -                 empty = scanning mode

modem                   no

vehicle.type            -                 moved from vehicle/type

server.v2               no
server.v3               no

The web UI has a new config page for this as well.

On boot, the housekeeper temporarily sets "init" to false. 10 seconds after booting has finished it re-enables it, assuming the system is stable.

The auto wifi ap mode does a fallback to "OVMS" with the module password if no AP network is configured. It does not start the AP mode if the password is empty.
So in order to enable the AP mode for configuration, it's sufficient to set the module password and leave all auto configs to their defaults.

Unfortunately a crash reboot seems to be indistinguishable from a manual reset. I've added a log output of the reset reason provided by the ESP. The reason
codes are:

typedef enum {
    NO_MEAN                = 0,
    POWERON_RESET          = 1,    /**<1, Vbat power on reset*/
    SW_RESET               = 3,    /**<3, Software reset digital core*/
    OWDT_RESET             = 4,    /**<4, Legacy watch dog reset digital core*/
    DEEPSLEEP_RESET        = 5,    /**<3, Deep Sleep reset digital core*/
    SDIO_RESET             = 6,    /**<6, Reset by SLC module, reset digital core*/
    TG0WDT_SYS_RESET       = 7,    /**<7, Timer Group0 Watch dog reset digital core*/
    TG1WDT_SYS_RESET       = 8,    /**<8, Timer Group1 Watch dog reset digital core*/
    RTCWDT_SYS_RESET       = 9,    /**<9, RTC Watch dog Reset digital core*/
    INTRUSION_RESET        = 10,    /**<10, Instrusion tested to reset CPU*/
    TGWDT_CPU_RESET        = 11,    /**<11, Time Group reset CPU*/
    SW_CPU_RESET           = 12,    /**<12, Software reset CPU*/
    RTCWDT_CPU_RESET       = 13,    /**<13, RTC Watch dog Reset CPU*/
    EXT_CPU_RESET          = 14,    /**<14, for APP CPU, reseted by PRO CPU*/
    RTCWDT_BROWN_OUT_RESET = 15,    /**<15, Reset when the vdd voltage is not stable*/
    RTCWDT_RTC_RESET       = 16     /**<16, RTC Watch dog reset digital core and rtc module*/
} RESET_REASON;

I get these values:

…boot after make app-flash:
I (537) housekeeping: reset_reason: cpu0=1, cpu1=14

…after triggering vfs-edit-bug:
I (527) housekeeping: reset_reason: cpu0=12, cpu1=12

…after "module reset":
I (527) housekeeping: reset_reason: cpu0=12, cpu1=12

…after "module fault":
I (527) housekeeping: reset_reason: cpu0=12, cpu1=12

…and no, the 12/12 were not sticky, I checked with a clean boot.

There's also a bug in the ESP32 that may trigger false positives: https://github.com/espressif/esp-idf/issues/494#issuecomment-291916959

I haven't had that effect up to now, but it seems we cannot rely on the reset reason.

Regards,
Michael

Am 25.02.2018 um 15:06 schrieb Michael Balzer:

Am 22.02.2018 um 04:22 schrieb Mark Webb-Johnson:

When looking at the deep sleep stuff, I found there is a way to tag a global variable as ‘rtc’. That should survive a deep sleep (or reboot).

Unfortunately, it does not survive a reboot:

* Data in RTC memory is initialised whenever the SoC restarts, except when waking from deep sleep. When waking from deep sleep, the values which were present
before going to sleep are kept.

There is an NVS library: https://esp-idf.readthedocs.io/en/v1.0/api/nvs_flash.html

…but I've got the impression that could interfere with our own flash usage (?).

Also, if flash is the way and as /store is already present at housekeeping init, I think we can just as well use our own config module…

Regards,
Michael

--
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

_______________________________________________
OvmsDev mailing list
OvmsDev@lists.teslaclub.hk
http://lists.teslaclub.hk/mailman/listinfo/ovmsdev