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