<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
Craig,<br>
<br>
sorry, I missed posting an info on this on the list. You need to
update your esp-idf for the new build config.<br>
<br>
See commit note:<br>
<a class="moz-txt-link-freetext" href="https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/3e5ac7747b03603661a51eb791386e976bcd2b32">https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/3e5ac7747b03603661a51eb791386e976bcd2b32</a><br>
<br>
A simple pull should do, no submodules changed.<br>
<br>
Regarding your crash, that looks very similar to the ones I
mentioned here:<br>
<a class="moz-txt-link-freetext" href="https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/702#issuecomment-1295778399">https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/702#issuecomment-1295778399</a><br>
<br>
<font face="monospace">.../esp/openvehicles-xtensa-esp32-elf/components/esp32/hwcrypto/sha.c:272
<br>
<br>
void esp_sha_read_digest_state(esp_sha_type sha_type, void
*digest_state)<br>
…<br>
/* Fault injection check: verify SHA engine actually ran,<br>
state is not all zeroes.<br>
*/<br>
for (int i = 0; i < word_len; i++) {<br>
if (digest_state_words[i] != 0) {<br>
return;<br>
}<br>
}<br>
<b> abort(); // SHA peripheral returned all zero state,
probably due to fault injection</b></font><br>
<br>
<br>
That's exactly the place I saw multiple crashes when using net data
encryption while the SSH key generator was still running.<br>
<br>
No idea yet how that would happen / what we would need to change.<br>
<br>
Regards,<br>
Michael<br>
<br>
<br>
<div class="moz-cite-prefix">Am 08.11.22 um 08:15 schrieb Craig
Leres:<br>
</div>
<blockquote type="cite"
cite="mid:4e27c758-0c62-30cf-3f93-11029f779905@xse.com">I have
been having a lot of issues with netreg over the last few weeks.
But Sunday when I built a new image I noticed some stack sizes had
changed between my sdkconfig and support/sdkconfig.default.hw31.
(I normally run with basically the support version but with most
vehicles turned off and ) I remember a thread I didn't follow
closely about the increasing the size of the stack. Anyway, I
built and booted that version (3.3.003-71-g5c873b72). And hadn't
had a netreg issue for more than a day across my three active
modules.
<br>
<br>
Arriving home a few minutes ago I had a fresh netreg issue (the
first with this build). But it turned out to maybe be a crash...
<br>
<br>
Last boot was 521 second(s) ago
<br>
Time at boot: 2022-11-07 22:53:04 PST
<br>
This is reset #3 since last power cycle
<br>
Detected boot reason: Crash (12/12)
<br>
Reset reason: Exception/panic (4)
<br>
Crash counters: 3 total, 0 early
<br>
<br>
Last crash: abort() was called on core 1
<br>
Current task on core 0: IDLE0, 524 stack bytes free
<br>
Current task on core 1: OVMS NetMan, 512 stack bytes free
<br>
Backtrace:
<br>
0x400891af 0x40089449 0x40261021 0x4023d1a2 0x40236f4a
0x4023893f 0x40247d73 0x40238c0e 0x40238c39 0x40127340 0x401289ec
0x4012a135 0x4012a65b 0x40126b4e 0x4011b053 0x4011b0f1
<br>
Version: 3.3.003-71-g5c873b72-dirty/ota_1/main (build idf
v3.3.4-848-g1ff5e24b1 Nov 6 2022 10:35:33)
<br>
<br>
Hardware: OVMS WIFI BLE BT cores=2 rev=ESP32/3; MODEM
SIM7600
<br>
<br>
Which decodes as:
<br>
<br>
xtensa-esp32-elf-addr2line -e build/ovms3.elf 0x400891af
0x40089449 0x40261021 0x4023d1a2 0x40236f4a 0x4023893f 0x40247d73
0x40238c0e 0x40238c39 0x40127340 0x401289ec 0x4012a135 0x4012a65b
0x40126b4e 0x4011b053 0x4011b0f1
<br>
<br>
.../esp/openvehicles-xtensa-esp32-elf/components/esp32/panic.c:736
<br>
.../esp/openvehicles-xtensa-esp32-elf/components/esp32/panic.c:736
<br>
<br>
.../esp/openvehicles-xtensa-esp32-elf/components/esp32/hwcrypto/sha.c:272
<br>
<br>
.../esp/openvehicles-xtensa-esp32-elf/components/mbedtls/port/esp_sha256.c:349
<br>
<br>
.../esp/openvehicles-xtensa-esp32-elf/components/mbedtls/mbedtls/library/ssl_tls.c:7649
<br>
<br>
.../esp/openvehicles-xtensa-esp32-elf/components/mbedtls/mbedtls/library/ssl_tls.c:7649
<br>
<br>
.../esp/openvehicles-xtensa-esp32-elf/components/mbedtls/mbedtls/library/ssl_cli.c:3894
<br>
<br>
.../esp/openvehicles-xtensa-esp32-elf/components/mbedtls/mbedtls/library/ssl_tls.c:7649
<br>
<br>
.../esp/openvehicles-xtensa-esp32-elf/components/mbedtls/mbedtls/library/ssl_tls.c:7649
<br>
components/mongoose/mongoose/mongoose.c:1701
<br>
components/mongoose/mongoose/mongoose.c:1701
<br>
components/mongoose/mongoose/mongoose.c:1701
<br>
components/mongoose/mongoose/mongoose.c:1701
<br>
components/mongoose/mongoose/mongoose.c:1701
<br>
main/ovms_netmanager.cpp:1036
<br>
main/ovms_netmanager.cpp:1036
<br>
<br>
diff'ing my sdkconfig against support/sdkconfig.default.hw31 I was
surprised to find that CONFIG_MDNS_TASK_STACK_SIZE was missing
from mine; I added it back (again), nuked the build directory and
rebuilt... and it was missing again:
<br>
<br>
ice 616 % diff sdkconfig support/sdkconfig.default.hw31 |
fgrep -v CONFIG_OVMS_VEHICLE
<br>
209c209
<br>
< CONFIG_SPIRAM_CACHE_WORKAROUND=
<br>
---
<br>
> CONFIG_SPIRAM_CACHE_WORKAROUND=y
<br>
667,684c667,685
<br>
---
<br>
687,692c688,693
<br>
---
<br>
833a835
<br>
> CONFIG_MDNS_TASK_STACK_SIZE=3072
<br>
<br>
What's the story with CONFIG_MDNS_TASK_STACK_SIZE?
<br>
<br>
Craig
<br>
_______________________________________________
<br>
OvmsDev mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.openvehicles.com">OvmsDev@lists.openvehicles.com</a>
<br>
<a class="moz-txt-link-freetext" href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a>
<br>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26</pre>
</body>
</html>