<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Falling back to the prior version (other OTA partition) is more
traditional, but once things get settled, we probably won't need the
added complexity. The factory version should support enough
automation that recovery would be easy.<br>
<br>
Just curious... What version is "factory" on the units being built
now?<br>
<br>
Greg<br>
<br>
<br>
<div class="moz-cite-prefix">Mark Webb-Johnson wrote:<br>
</div>
<blockquote type="cite"
cite="mid:EB88DA90-CF00-44BA-AE5E-4AA8A8713CAD@webb-johnson.net">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
I guess it is possible, but probably easiest to just fallback to
factory (rather than the other OTA partition).
<div class=""><br class="">
</div>
<div class="">I suggest something like if auto is inhibited, and
we’ve had five further crashes within 10 seconds of boot, and we
are running OTA, then switch back to factory.</div>
<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 11:29 PM, 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=""> Should we
extend that logic to also cover firmware updates?<br
class="">
<br class="">
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 class="">
<br class="">
Regards,<br class="">
Michael<br class="">
<br class="">
<br class="">
<div class="moz-cite-prefix">Am 09.03.2018 um 07:14
schrieb Mark Webb-Johnson:<br class="">
</div>
<blockquote type="cite"
cite="mid:7A59A1E7-410A-4B33-B326-E77851A00F1E@webb-johnson.net"
class="">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8" class="">
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 class="">
<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"
moz-do-not-send="true">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a><br
class="">
</div>
</blockquote>
</div>
<br class="">
</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>
</body>
</html>