<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Should we extend that logic to also cover firmware updates?<br>
<br>
I.e. if the system can't get to the stable state after disabling
auto init, we could try to activate the other ota partition with a
fallback to factory.<br>
<br>
Regards,<br>
Michael<br>
<br>
<br>
<div class="moz-cite-prefix">Am 09.03.2018 um 07:14 schrieb Mark
Webb-Johnson:<br>
</div>
<blockquote type="cite"
cite="mid:7A59A1E7-410A-4B33-B326-E77851A00F1E@webb-johnson.net">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
Looks good to me. Working well in simulations (module fault).
<div class=""><br class="">
</div>
<div class="">Regards, Mark.</div>
<div class=""><br class="">
<div>
<blockquote type="cite" class="">
<div class="">On 9 Mar 2018, at 6:54 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=""> Done:<br
class="">
<br class="">
<tt class="">E (1226) housekeeping: Auto init inhibited:
too many early crashes (6)</tt><tt class=""><br
class="">
</tt><tt class="">…</tt><tt class=""><br class="">
</tt><tt class="">OVMS > boot status </tt><tt
class=""><br class="">
</tt><tt class="">Last boot was 71 second(s) ago</tt><tt
class=""><br class="">
</tt><tt class=""> This is reset #6 since last power
cycle</tt><tt class=""><br class="">
</tt><tt class=""> Detected boot reason: EarlyCrash</tt><tt
class=""><br class="">
</tt><tt class=""> Crash counters: 6 total, 6 early</tt><tt
class=""><br class="">
</tt><tt class=""> CPU#0 boot reason was 12</tt><tt
class=""><br class="">
</tt><tt class=""> CPU#1 boot reason was 12</tt><tt
class=""><br class="">
</tt><br class="">
<br class="">
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 class="">
<br class="">
Regards,<br class="">
Michael<br class="">
<br class="">
<br class="">
<div class="moz-cite-prefix">Am 08.03.2018 um 04:55
schrieb Mark Webb-Johnson:<br class="">
</div>
<blockquote type="cite"
cite="mid:ADFA6751-2A05-4774-95B0-1DB85BE29260@webb-johnson.net"
class="">
<meta http-equiv="Content-Type" content="text/html;
charset=utf-8" 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 class=""><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"
moz-do-not-send="true">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a><br
class="">
</div>
</blockquote>
</div>
<br class="">
</div>
</div>
</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>
<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>