[Ovmsdev] xTimerCreate <10ms

[Mark Webb-Johnson]

I’ve received a bug report that the Tesla Roadster vehicle module is crashing when the digital speedo option is used (with latest 3.2.008 firmware):

#324 Tesla Roadster digital speedo crashing on latest firmware <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/324>

Backtrace is:

0x4008b72f is in invoke_abort (esp-idf/components/esp32/panic.c:156).
0x4008b9c9 is in abort (esp-idf/components/esp32/panic.c:171).
0x40097765 is in xTimerCreate (esp-idf/components/freertos/timers.c:385).
0x4018ccaa is in OvmsVehicleTeslaRoadster::IncomingFrameCan1(CAN_frame_t*) (components/vehicle_teslaroadster/src/vehicle_teslaroadster.cpp:375).
0x4015ba95 is in OvmsVehicle::RxTask() (components/vehicle/vehicle.cpp:1138).
0x4027fee2 is in OvmsVehicleRxTask(void*) (components/vehicle/vehicle.cpp:940).

and the abort is called by an assert:

configASSERT( ( xTimerPeriodInTicks > 0 ) );

In our default sdkconfig configurations, we have:

CONFIG_FREERTOS_HZ=100

so I think that means there are 0.1 ticks per millisecond, and setting any timer <10ms will trigger the assertion crash. I have no idea why it wasn’t a problem when this was written (a few years ago), but the crash is definitely caused by this. Maybe at some time ago we disabled abort on assertions?

Anyway, reviewing the code there are a few places we use xTimerCreate and this can happen. Most are hard-coded times greater than 10ms. The remaining ones are:

ovms_events.cpp in the SignalRaise function
vehicle_teslaroadster.cpp in two places

I changed both of these to avoid the issue (enforce ticks to be >= 1).

Just beware that we can’t have timers less than 10ms with our current configuration.

Regards, Mark.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200122/010eab87/attachment.html>