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