<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Mark,<br>
<br>
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.<br>
<br>
I'll optimize the auto start logic after finishing the webserver
fixes.<br>
<br>
Thanks,<br>
Michael<br>
<br>
<br>
<div class="moz-cite-prefix">Am 07.03.2018 um 15:39 schrieb Mark
Webb-Johnson:<br>
</div>
<blockquote type="cite"
cite="mid:BFF66E85-3BAF-41C2-8F42-3078D9BF539D@webb-johnson.net">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
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=""
moz-do-not-send="true">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="" moz-do-not-send="true">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="" moz-do-not-send="true">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=""
moz-do-not-send="true">OvmsDev@lists.teslaclub.hk</a><br
class="">
<a class="moz-txt-link-freetext"
href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a><br
class="">
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
OvmsDev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.teslaclub.hk">OvmsDev@lists.teslaclub.hk</a>
<a class="moz-txt-link-freetext" href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="160">--
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
</pre>
</body>
</html>