[Ovmsdev] Auto start/init
Michael Balzer
dexter at expeedo.de
Thu Mar 8 01:25:34 HKT 2018
Mark,
I also had the problem of losing auto start when rebooting within 10 seconds. I was about to add more config instances to track the state, but having the RTC
RAM for this is much better. I wasn't aware of the option to add custom segments in there.
I'll optimize the auto start logic after finishing the webserver fixes.
Thanks,
Michael
Am 07.03.2018 um 15:39 schrieb Mark Webb-Johnson:
> I’m having problems with this approach. Specifically, permanently disabling the auto start system if the system fails once during a boot.
>
> I tried the module in my car today. Plugged it in, but the access point didn’t come up. No laptop, just an iPad.
>
> 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.
>
> 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...
>
> 1. 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.
>
> 2. 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.
>
> 3. 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).
>
>
> 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 at expeedo.de <mailto:dexter at 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 at lists.teslaclub.hk <mailto:OvmsDev at lists.teslaclub.hk>
>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>
>
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
--
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20180307/caa984b2/attachment.htm>
More information about the OvmsDev
mailing list