And, why is the script running from obd2ecu causing the async console to fall over?

To show the value it executes the script. That needs stack.

Regards, Mark.

On 29 Mar 2018, at 10:29 AM, Greg D. <gregd2350@gmail.com> wrote:
... looks like it needs an additional 512 bytes. Dropping to an increment of 256 bytes, 21*256 didn't do it, 22*256 did.

How much above that is needed for safety? And, why is the script running from obd2ecu causing the async console to fall over? The output from the script is no different than a regular line generated from a regular metric.

Greg

Greg D. wrote:
Thanks for the analysis. module tasks isn't working, but I'll do some tests to get an approximate limit.

Please get some "day job" stuff done - this isn't time critical.

Greg

Mark Webb-Johnson wrote:
Probably insufficient stack in AsyncConsole.

At the moment it should be 5KB. Maybe more needed?

console_async.cpp line 50

ConsoleAsync::ConsoleAsync() : TaskBase("AsyncConsole", 5*1024)

Can you try increasing, then running a ‘module tasks’ to see what it actually used?

Regards, Mark.

On 29 Mar 2018, at 10:08 AM, Greg D. <gregd2350@gmail.com> wrote:

Here you go... (newlines added for clarity)

Greg

greg@linux-0rpb:~/greg/ovms/Open-Vehicle-Monitoring-System-3-master/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3>
~/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

0x4008ead4: invoke_abort at
/home/greg/esp/esp-idf/components/esp32/./panic.c:648
0x4008ecab: abort at /home/greg/esp/esp-idf/components/esp32/./panic.c:648
0x4008ecc4: vApplicationStackOverflowHook at
/home/greg/esp/esp-idf/components/esp32/./panic.c:648
0x4008ab6b: vTaskSwitchContext at
/home/greg/esp/esp-idf/components/freertos/./tasks.c:4837
0x4008cd94: _frxt_dispatch at
/home/greg/esp/esp-idf/components/freertos/./portasm.S:406
0x4008cd4a: _frxt_int_exit at
/home/greg/esp/esp-idf/components/freertos/./portasm.S:206

greg@linux-0rpb:~/greg/ovms/Open-Vehicle-Monitoring-System-3-master/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3>

Mark Webb-Johnson wrote:

Greg,

The backtrace we need is one either via gdbstub, or one you produce with:

~/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

Regards, Mark

On 29 Mar 2018, at 9:44 AM, Greg D. <gregd2350@gmail.com> wrote:

So, now it's failing at my desk, too. Good - a lot easier to grab a
backtrace...   But, it's also happening whether the metrics are set or
not. I've updated the code to the current (including your housekeeping
changes); not sure if that made a difference.

OVMS> vfs cat /store/obd2ecu/10
ret1=OvmsMetricFloat("v.p.speed");
ret2=OvmsMetricFloat("v.b.power");
out = 0.0;
if(ret1 > 0) { out=ret2/ret1; }
out;
OVMS> obdii ecu list
PID             Type        Value    Metric
0   (0x00)       internal     0.000000
4   (0x04)       internal     0.000000 v.b.soc
5   (0x05)         metric     0.000000 v.e.temp
***ERROR*** A stack overflow in task AsyncConsole has been detected.
abort() was called at PC 0x4008ecc4 on core 1

Backtrace: 0x4008ead4:0x3fff2f50 0x4008ecab:0x3fff2f70
0x4008ecc4:0x3fff2f90 0x4008ab6b:0x3fff2fb0 0x4008cd94:0x3fff2fd0
0x4008cd4a:0x3fff600c

Rebooting...

Mark Webb-Johnson wrote:

Need to see a backtrace. Perhaps you are just on the borderline of stack usage, or something going crazy?

Looking at DukOvmsMetricFloat(), it just return the metric AsFloat(), and for float type metrics that should just be zero if not defined.

Regards, Mark.

On 29 Mar 2018, at 8:58 AM, Greg D. <gregd2350@gmail.com> wrote:

Hi folks,

Does anyone know how DukTape scripting handles math with a metric that
hasn't been updated yet?

I have a short example script in the OBDII ECU documentation which
(should) calculate a power-per-speed metric for display on a HUD. Seems
like it would be a useful example, and wanted to verify that it actually
works.

OVMS> vfs cat /store/obd2ecu/10
ret1=OvmsMetricFloat("v.p.speed");
ret2=OvmsMetricFloat("v.b.power");
out = 0.0;
if(ret1 > 0) { out=ret2/ret1; }
out;

I have the module in the my Roadster, and the v.p.speed metric comes up
as 0 kph (that's good - it's parked), but the power metric isn't
provided by the car, so is blank when listing the metrics. I expected
the code to return zero.

Instead, executing the script by asking for 'obdii ecu list' causes an
immediate crash with a stack overflow in task AsyncConsole. If I
initialize the power metric by hand (metric set v.b.power 0), the script
runs just fine, returning 0 for the metric.

Oddly, when I first set it up on the desk (sans vehicle), so both of the
metrics were blank, executing the script didn't cause crash.

Is there a way to make the code "Roadster safe", without dummying up the
metric in, say, a startup script? Better, is there a fix for DukTape to
handle this, or should I just increase the stack size in AsyncConsole?

Thanks,

Greg

_______________________________________________
OvmsDev mailing list
OvmsDev@lists.teslaclub.hk
http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

_______________________________________________
OvmsDev mailing list
OvmsDev@lists.teslaclub.hk
http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

_______________________________________________
OvmsDev mailing list
OvmsDev@lists.teslaclub.hk
http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

_______________________________________________
OvmsDev mailing list
OvmsDev@lists.teslaclub.hk
http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

_______________________________________________
OvmsDev mailing list
OvmsDev@lists.teslaclub.hk
http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________
OvmsDev mailing list
OvmsDev@lists.teslaclub.hk
http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________
OvmsDev mailing list
OvmsDev@lists.teslaclub.hk
http://lists.teslaclub.hk/mailman/listinfo/ovmsdev