Greg,
... looks like it needs an additional 512 bytes. Dropping to an increment of 256 bytes, 21*256 didn't do it, 22*256 did.
I suggest 6144. That is what the others use.
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 <mailto: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 <mailto:greg@linux-0rpb:%7E/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 <mailto:greg@linux-0rpb:%7E/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 <mailto: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 <mailto: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 <mailto:OvmsDev@lists.teslaclub.hk> >> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev> > _______________________________________________ > OvmsDev mailing list > OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> > http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev> _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev