<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">I’m having problems with this approach. Specifically, permanently disabling the auto start system if the system fails once during a boot.<div class=""><br class=""></div><div class="">I tried the module in my car today. Plugged it in, but the access point didn’t come up. No laptop, just an iPad.</div><div class=""><br class=""></div><div class="">It seems that while I was plugging it in, the power jiggled. So it booted for a second or so, reset, then booted again. It treated this as a problem, so turned off the auto init system permanently. No matter how many times I reset, I couldn’t get an access point to come up, and couldn’t get into the system from the iPad.</div><div class=""><br class=""></div><div class="">I’m not sure that storing this in config (fat filesystem) is optimal. I think the core reason for that was because the ESP IDF framework wipes RTC memory on boot for anything apart from a deep sleep. So, I set about finding a solution to that core problem. The result is quite neat, and visible in main/component.mk, and main/ovms_boot.*. It turns out that the ESP framework (start_cpu0) wipes the RTC BSS segment only. It leaves other RTC data untouched. So...</div><div class=""><br class=""></div><div class=""><ol class="MailOutline"><li class="">I create a linker section ‘.rtc.noload’. This goes in RTC slow ram, alongside the other RTC bss sections. But the NOLOAD flag is specified, to stop GCC from wiping this memory on boot.<br class=""><br class=""></li><li class="">I then create a typedef struct boot_data_t and storage boot_data to store the actual boot data. It is tagged __attribute__((section(".rtc.noload"))) to force it into that NOLOAD section. I’ve now got some data that never gets initialised, and survives a reset.<br class=""><br class=""></li><li class="">The last step is to check the actual boot reason (using rtc_get_reset_reason). If it is POWERON_RESET then I zero the boot_data storage (otherwise it is truly garbage - perhaps good for random number initialisation, but not much else). </li></ol></div><div class=""><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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).</div><div class=""><br class=""></div><div class="">Workable?</div><div class=""><br class=""></div><div class="">Regards, Mark.</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 26 Feb 2018, at 3:51 AM, Michael Balzer <<a href="mailto:dexter@expeedo.de" class="">dexter@expeedo.de</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">First version of the auto init system is in the hub.<br class=""><br class="">As discussed, I added an "auto" config param. It currently has these instances:<br class=""><br class="">Instance Default Remark<br class="">----------------------------------------------------------------------<br class="">init yes<br class=""><br class="">wifi.mode ap off|ap|client<br class="">wifi.ssid.ap OVMS<br class="">wifi.ssid.client - empty = scanning mode<br class=""><br class="">modem no<br class=""><br class="">vehicle.type - moved from vehicle/type<br class=""><br class="">server.v2 no<br class="">server.v3 no<br class=""><br class=""><br class="">The web UI has a new config page for this as well.<br class=""><br class="">On boot, the housekeeper temporarily sets "init" to false. 10 seconds after booting has finished it re-enables it, assuming the system is stable.<br class=""><br class="">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.<br class="">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.<br class=""><br class=""><br class="">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<br class="">codes are:<br class=""><br class="">typedef enum {<br class=""> NO_MEAN = 0,<br class=""> POWERON_RESET = 1, /**<1, Vbat power on reset*/<br class=""> SW_RESET = 3, /**<3, Software reset digital core*/<br class=""> OWDT_RESET = 4, /**<4, Legacy watch dog reset digital core*/<br class=""> DEEPSLEEP_RESET = 5, /**<3, Deep Sleep reset digital core*/<br class=""> SDIO_RESET = 6, /**<6, Reset by SLC module, reset digital core*/<br class=""> TG0WDT_SYS_RESET = 7, /**<7, Timer Group0 Watch dog reset digital core*/<br class=""> TG1WDT_SYS_RESET = 8, /**<8, Timer Group1 Watch dog reset digital core*/<br class=""> RTCWDT_SYS_RESET = 9, /**<9, RTC Watch dog Reset digital core*/<br class=""> INTRUSION_RESET = 10, /**<10, Instrusion tested to reset CPU*/<br class=""> TGWDT_CPU_RESET = 11, /**<11, Time Group reset CPU*/<br class=""> SW_CPU_RESET = 12, /**<12, Software reset CPU*/<br class=""> RTCWDT_CPU_RESET = 13, /**<13, RTC Watch dog Reset CPU*/<br class=""> EXT_CPU_RESET = 14, /**<14, for APP CPU, reseted by PRO CPU*/<br class=""> RTCWDT_BROWN_OUT_RESET = 15, /**<15, Reset when the vdd voltage is not stable*/<br class=""> RTCWDT_RTC_RESET = 16 /**<16, RTC Watch dog reset digital core and rtc module*/<br class="">} RESET_REASON;<br class=""><br class="">I get these values:<br class=""><br class="">…boot after make app-flash:<br class="">I (537) housekeeping: reset_reason: cpu0=1, cpu1=14<br class=""><br class="">…after triggering vfs-edit-bug:<br class="">I (527) housekeeping: reset_reason: cpu0=12, cpu1=12<br class=""><br class="">…after "module reset":<br class="">I (527) housekeeping: reset_reason: cpu0=12, cpu1=12<br class=""><br class="">…after "module fault":<br class="">I (527) housekeeping: reset_reason: cpu0=12, cpu1=12<br class=""><br class="">…and no, the 12/12 were not sticky, I checked with a clean boot.<br class=""><br class="">There's also a bug in the ESP32 that may trigger false positives: <a href="https://github.com/espressif/esp-idf/issues/494#issuecomment-291916959" class="">https://github.com/espressif/esp-idf/issues/494#issuecomment-291916959</a><br class=""><br class="">I haven't had that effect up to now, but it seems we cannot rely on the reset reason.<br class=""><br class="">Regards,<br class="">Michael<br class=""><br class=""><br class="">Am 25.02.2018 um 15:06 schrieb Michael Balzer:<br class=""><blockquote type="cite" class="">Am 22.02.2018 um 04:22 schrieb Mark Webb-Johnson:<br class=""><blockquote type="cite" class="">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).<br class=""></blockquote>Unfortunately, it does not survive a reboot:<br class=""><br class=""><blockquote type="cite" class="">* 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<br class="">before going to sleep are kept.<br class=""></blockquote>There is an NVS library: <a href="https://esp-idf.readthedocs.io/en/v1.0/api/nvs_flash.html" class="">https://esp-idf.readthedocs.io/en/v1.0/api/nvs_flash.html</a><br class=""><br class="">…but I've got the impression that could interfere with our own flash usage (?).<br class=""><br class="">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…<br class=""><br class="">Regards,<br class="">Michael<br class=""><br class=""></blockquote><br class="">-- <br class="">Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal<br class="">Fon 02333 / 833 5735 * Handy 0176 / 206 989 26<br class=""><br class="">_______________________________________________<br class="">OvmsDev mailing list<br class=""><a href="mailto:OvmsDev@lists.teslaclub.hk" class="">OvmsDev@lists.teslaclub.hk</a><br class="">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev<br class=""></div></div></blockquote></div><br class=""></div></div></body></html>