[Ovmsdev] Auto start/init

Tue Feb 27 20:07:53 HKT 2018

Saw this one just now:

Brownout detector was triggered

ets Jun  8 2016 00:22:57

rst:0xc (SW_CPU_RESET),boot:0x3b (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:5984
ho 0 tail 12 room 4
load:0x40078000,len:0
load:0x40078000,len:15696
entry 0x4007901c
I (30) boot: ESP-IDF v3.1-dev-430-gddeff7d5 2nd stage bootloader

I (402) housekeeping: Initialising HOUSEKEEPING Framework...
I (462) housekeeping: Executing on CPU core 1
I (462) housekeeping: reset_reason: cpu0=12, cpu1=12

(Not taking my own advise about powered USB hubs)

Regards, Mark.

> On 26 Feb 2018, at 3:51 AM, Michael Balzer <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
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20180227/74ac124b/attachment.htm>