<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Done:<br>
<br>
<tt>E (1226) housekeeping: Auto init inhibited: too many early
crashes (6)</tt><tt><br>
</tt><tt>…</tt><tt><br>
</tt><tt>OVMS > boot status </tt><tt><br>
</tt><tt>Last boot was 71 second(s) ago</tt><tt><br>
</tt><tt> This is reset #6 since last power cycle</tt><tt><br>
</tt><tt> Detected boot reason: EarlyCrash</tt><tt><br>
</tt><tt> Crash counters: 6 total, 6 early</tt><tt><br>
</tt><tt> CPU#0 boot reason was 12</tt><tt><br>
</tt><tt> CPU#1 boot reason was 12</tt><tt><br>
</tt><br>
<br>
A manual reset by "module reset" is detected as a soft reboot and
resets all counters like a hard reset. Hard resets (i.e. ^T^R in the
monitor) look just like a normal power on.<br>
<br>
Regards,<br>
Michael<br>
<br>
<br>
<div class="moz-cite-prefix">Am 08.03.2018 um 04:55 schrieb Mark
Webb-Johnson:<br>
</div>
<blockquote type="cite"
cite="mid:ADFA6751-2A05-4774-95B0-1DB85BE29260@webb-johnson.net">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<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="" moz-do-not-send="true">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"
moz-do-not-send="true">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 class="" wrap="">_______________________________________________
OvmsDev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.teslaclub.hk" moz-do-not-send="true">OvmsDev@lists.teslaclub.hk</a>
<a class="moz-txt-link-freetext" href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev" moz-do-not-send="true">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=""
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>
</blockquote>
</div>
<br class="">
</div>
</div>
</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>