<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><blockquote type="cite" class=""><div text="#000000" bgcolor="#FFFFFF" class="">I wasn't aware of the option to add custom segments in there.</div></blockquote><div class=""><br class=""></div>Me neither. It was fun finding out how to do this. I learned a lot about GCC linker scripts and how the Espressif IDF framework uses them. Also learned that the error messages coming out of the linker are so obscure as to be useless.<div class=""><div class=""><br class=""></div><div class="">I think we should be able to store the reason for a crash in that area, then after reboot submit it as a notification to the servers (in much the same way we did for OVMS v2, but more powerful as we have the reason before the crash, not just the crash itself). It seems that some of the system crash handlers can be overridden (such as void __attribute__((weak)) vApplicationStackOverflowHook).<br class=""><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div text="#000000" bgcolor="#FFFFFF" class="">I'll optimize the auto start logic after finishing the webserver fixes.</div></blockquote><div class=""><br class=""></div><div class="">Thanks.</div><div class=""><br class=""></div><div class="">Regards, Mark.</div><div class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 8 Mar 2018, at 1:25 AM, Michael Balzer <<a href="mailto:dexter@expeedo.de" class="">dexter@expeedo.de</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" class="">
<div text="#000000" bgcolor="#FFFFFF" class="">
Mark,<br class="">
<br class="">
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 class="">
<br class="">
I'll optimize the auto start logic after finishing the webserver
fixes.<br class="">
<br class="">
Thanks,<br class="">
Michael<br class="">
<br class="">
<br class="">
<div class="moz-cite-prefix">Am 07.03.2018 um 15:39 schrieb Mark
Webb-Johnson:<br class="">
</div>
<blockquote type="cite" cite="mid:BFF66E85-3BAF-41C2-8F42-3078D9BF539D@webb-johnson.net" class="">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" 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 class="">
<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 class="">
<fieldset class="mimeAttachmentHeader"></fieldset>
<br class="">
<pre wrap="" class="">_______________________________________________
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 class="">
<pre class="moz-signature" cols="160">--
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
</pre>
</div>
_______________________________________________<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></blockquote></div><br class=""></div></div></div></div></body></html>