<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="">Probably insufficient stack in AsyncConsole.<div class=""><br class=""></div><div class="">At the moment it should be 5KB. Maybe more needed?</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">console_async.cpp line 50</div><div class=""><br class=""></div><div class="">ConsoleAsync::ConsoleAsync() : TaskBase("AsyncConsole", 5*1024)</div></blockquote><div class=""><div><br class=""></div><div>Can you try increasing, then running a ‘module tasks’ to see what it actually used?</div><div><br class=""></div><div>Regards, Mark.</div><div><br class=""><blockquote type="cite" class=""><div class="">On 29 Mar 2018, at 10:08 AM, Greg D. <<a href="mailto:gregd2350@gmail.com" class="">gregd2350@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Here you go... (newlines added for clarity)<br class=""><br class="">Greg<br class=""><br class="">greg@linux-0rpb:~/greg/ovms/Open-Vehicle-Monitoring-System-3-master/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3><br class="">~/esp/xtensa-esp32-elf/bin/xtensa-esp32-elf-addr2line -pfiaC -e<br class="">build/ovms3.elf 0x4008ead4:0x3fff2f50 0x4008ecab:0x3fff2f70<br class="">0x4008ecc4:0x3fff2f90 0x4008ab6b:0x3fff2fb0 0x4008cd94:0x3fff2fd0<br class="">0x4008cd4a:0x3fff600c<br class=""><br class="">0x4008ead4: invoke_abort at<br class="">/home/greg/esp/esp-idf/components/esp32/./panic.c:648<br class="">0x4008ecab: abort at /home/greg/esp/esp-idf/components/esp32/./panic.c:648<br class="">0x4008ecc4: vApplicationStackOverflowHook at<br class="">/home/greg/esp/esp-idf/components/esp32/./panic.c:648<br class="">0x4008ab6b: vTaskSwitchContext at<br class="">/home/greg/esp/esp-idf/components/freertos/./tasks.c:4837<br class="">0x4008cd94: _frxt_dispatch at<br class="">/home/greg/esp/esp-idf/components/freertos/./portasm.S:406<br class="">0x4008cd4a: _frxt_int_exit at<br class="">/home/greg/esp/esp-idf/components/freertos/./portasm.S:206<br class=""><br class="">greg@linux-0rpb:~/greg/ovms/Open-Vehicle-Monitoring-System-3-master/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3><br class=""><br class=""><br class=""><br class=""><br class=""><br class="">Mark Webb-Johnson wrote:<br class=""><blockquote type="cite" class="">Greg,<br class=""><br class="">The backtrace we need is one either via gdbstub, or one you produce with:<br class=""><br class="">~/esp/xtensa-esp32-elf/bin/xtensa-esp32-elf-addr2line -pfiaC -e build/ovms3.elf 0x4008ead4:0x3fff2f50 0x4008ecab:0x3fff2f70 0x4008ecc4:0x3fff2f90 0x4008ab6b:0x3fff2fb0 0x4008cd94:0x3fff2fd0 0x4008cd4a:0x3fff600c<br class=""><br class="">Regards, Mark<br class=""><br class=""><blockquote type="cite" class="">On 29 Mar 2018, at 9:44 AM, Greg D. <<a href="mailto:gregd2350@gmail.com" class="">gregd2350@gmail.com</a>> wrote:<br class=""><br class="">So, now it's failing at my desk, too. Good - a lot easier to grab a<br class="">backtrace... But, it's also happening whether the metrics are set or<br class="">not. I've updated the code to the current (including your housekeeping<br class="">changes); not sure if that made a difference.<br class=""><br class="">OVMS> vfs cat /store/obd2ecu/10<br class="">ret1=OvmsMetricFloat("v.p.speed");<br class="">ret2=OvmsMetricFloat("v.b.power");<br class="">out = 0.0;<br class="">if(ret1 > 0) { out=ret2/ret1; }<br class="">out;<br class="">OVMS> obdii ecu list<br class=""> PID Type Value Metric<br class="">0 (0x00) internal 0.000000<br class="">4 (0x04) internal 0.000000 v.b.soc<br class="">5 (0x05) metric 0.000000 v.e.temp<br class="">***ERROR*** A stack overflow in task AsyncConsole has been detected.<br class="">abort() was called at PC 0x4008ecc4 on core 1<br class=""><br class="">Backtrace: 0x4008ead4:0x3fff2f50 0x4008ecab:0x3fff2f70<br class="">0x4008ecc4:0x3fff2f90 0x4008ab6b:0x3fff2fb0 0x4008cd94:0x3fff2fd0<br class="">0x4008cd4a:0x3fff600c<br class=""><br class="">Rebooting...<br class=""><br class=""><br class=""><br class=""><br class="">Mark Webb-Johnson wrote:<br class=""><blockquote type="cite" class="">Need to see a backtrace. Perhaps you are just on the borderline of stack usage, or something going crazy?<br class=""><br class="">Looking at DukOvmsMetricFloat(), it just return the metric AsFloat(), and for float type metrics that should just be zero if not defined.<br class=""><br class="">Regards, Mark.<br class=""><br class=""><blockquote type="cite" class="">On 29 Mar 2018, at 8:58 AM, Greg D. <<a href="mailto:gregd2350@gmail.com" class="">gregd2350@gmail.com</a>> wrote:<br class=""><br class="">Hi folks,<br class=""><br class="">Does anyone know how DukTape scripting handles math with a metric that<br class="">hasn't been updated yet? <br class=""><br class="">I have a short example script in the OBDII ECU documentation which<br class="">(should) calculate a power-per-speed metric for display on a HUD. Seems<br class="">like it would be a useful example, and wanted to verify that it actually<br class="">works. <br class=""><br class="">OVMS> vfs cat /store/obd2ecu/10<br class="">ret1=OvmsMetricFloat("v.p.speed");<br class="">ret2=OvmsMetricFloat("v.b.power");<br class="">out = 0.0;<br class="">if(ret1 > 0) { out=ret2/ret1; }<br class="">out;<br class=""><br class="">I have the module in the my Roadster, and the v.p.speed metric comes up<br class="">as 0 kph (that's good - it's parked), but the power metric isn't<br class="">provided by the car, so is blank when listing the metrics. I expected<br class="">the code to return zero.<br class=""><br class="">Instead, executing the script by asking for 'obdii ecu list' causes an<br class="">immediate crash with a stack overflow in task AsyncConsole. If I<br class="">initialize the power metric by hand (metric set v.b.power 0), the script<br class="">runs just fine, returning 0 for the metric.<br class=""><br class="">Oddly, when I first set it up on the desk (sans vehicle), so both of the<br class="">metrics were blank, executing the script didn't cause crash.<br class=""><br class="">Is there a way to make the code "Roadster safe", without dummying up the<br class="">metric in, say, a startup script? Better, is there a fix for DukTape to<br class="">handle this, or should I just increase the stack size in AsyncConsole?<br class=""><br class="">Thanks,<br class=""><br class="">Greg<br class=""><br class="">_______________________________________________<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=""></blockquote>_______________________________________________<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=""></blockquote>_______________________________________________<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=""></blockquote>_______________________________________________<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=""></blockquote><br class="">_______________________________________________<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></div></blockquote></div><br class=""></div></body></html>