- OvmsDev - Open Vehicles

Leaf Odometer Units
by Tom Parker 11 Apr '18

11 Apr '18

Hi, I'm parsing the Leaf odometer out of the car can bus messages (something that wasn't possible on the ovms v2). The leaf apparently sends the odometer in km or miles, depending on the dashboard units. I'm detecting the units and setting them on the ovms metric, but I can only test on a car that records km. If it doesn't understand the units it does not populate the odometer value at all. When someone gets an OVMS on Leaf which shows it's odometer in miles can you please let me know if your odometer metric remains zero, is reported with the correct units, or reported with the wrong units. Thanks.

1 0

ssh: secure mode prompt not set #31
by Mark Webb-Johnson 10 Apr '18

10 Apr '18

Steve, Can you have a look at this one: https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/31 <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/31> When connecting to the box via ssh, using a trusted ssh.keys mechanism, it seems that the session is correctly put into secure mode (enable). But, the prompt is OVMS> (should be OVMS#). The full set of enable commands is shown, so pretty sure the session is in enable mode. I think the issue is purely the prompt being incorrect. I think (hope) it should be simple. Thanks, Mark.

3 4

Crash debugging
by Michael Balzer 10 Apr '18

10 Apr '18

I've pushed an update to enable saving crash data over a reset and automatically send that to the server using the history record "*-OVM-DebugCrash". Note: you will need to pull the esp-idf as well. As the support for exception handlers was insufficient for our needs, I have added a separate error handler registration that catches all three kinds of crashes (exceptions, panics and aborts). Crash reason, registers (if available) and backtrace are available via "boot status", with "make monitor" automatically mapping the addresses: OVMS# boot status Last boot was 16 second(s) ago This is reset #1 since last power cycle Detected boot reason: Crash Crash counters: 1 total, 0 early CPU#0 boot reason was 12 CPU#1 boot reason was 12 Last crash: abort() was called on core 1 Backtrace: 0x4008f698 0x4008f86f 0x400e7027 0x400edb76 0x400edc8d 0x400edc7f 0x400edcb5 0x400e3908 0x400f11c9 0x400f1230 0x400e3937 0x401cb613 0x400e3f49 0x400e82e5 0x400e84d1 0x400e3df5 0x400e3e04 0x400e69dd 0x4008f698: invoke_abort at /home/balzer/esp/esp-idf/components/esp32/./panic.c:669 0x4008f86f: abort at /home/balzer/esp/esp-idf/components/esp32/./panic.c:669 0x400e7027: module_fault(int, OvmsWriter*, OvmsCommand*, int, char const* const*) at /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_module.cpp:823 0x400edb76: OvmsCommand::Execute(int, OvmsWriter*, int, char const* const*) at /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_command.cpp:94 0x400edc8d: OvmsCommand::Execute(int, OvmsWriter*, int, char const* const*) at /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_command.cpp:94 0x400edc7f: OvmsCommand::Execute(int, OvmsWriter*, int, char const* const*) at /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_command.cpp:94 0x400edcb5: OvmsCommandApp::Execute(int, OvmsWriter*, int, char const* const*) at /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_command.cpp:94 0x400e3908: Execute(microrl*, int, char const* const*) at /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_shell.cpp:47 0x400f11c9: new_line_handler at /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/microrl/./microrl.c:620 0x400f1230: microrl_insert_char at /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/microrl/./microrl.c:668 0x400e3937: OvmsShell::ProcessChar(char) at /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_shell.cpp:70 0x401cb613: OvmsShell::ProcessChars(char const*, int) at /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_shell.cpp:77 (discriminator 2) 0x400e3f49: ConsoleAsync::HandleDeviceEvent(void*) at /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./console_async.cpp:169 0x400e82e5: OvmsConsole::Poll(unsigned int, void*) at /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_console.cpp:152 0x400e84d1: OvmsConsole::Service() at /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_console.cpp:132 (discriminator 1) 0x400e3df5: ConsoleAsync::Service() at /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./console_async.cpp:80 0x400e3e04: non-virtual thunk to ConsoleAsync::Service() at ??:? 0x400e69dd: TaskBase::Task(void*) at /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./task_base.cpp:156 The "*-OVM-DebugCrash" record has this structure: // H type "*-OVM-DebugCrash" // ,<firmware_version> // ,<bootcount>,<bootreason_name>,<bootreason_cpu0>,<bootreason_cpu1> // ,<crashcnt>,<earlycrashcnt>,<crashtype>,<crashcore>,<registers>,<backtrace> …with registers and backtraces separated by spaces. Example: *-OVM-DebugCrash,0,2592000,3.1.003-11-g37c5f4b/factory/main (build idf v3.1-dev-453-g0f978bcb-dirty Apr 8 2018 14:42:07),1,Crash,12,12,1,0,abort(),1,,0x4008f698 0x4008f86f 0x400e7027 0x400edb76 0x400edc8d 0x400edc7f 0x400edcb5 0x400e3908 0x400f11c9 0x400f1230 0x400e3937 0x401cb613 0x400e3f49 0x400e82e5 0x400e84d1 0x400e3df5 0x400e3e04 0x400e69dd To decode the backtrace, feed it to addr2line: balzer@leela:~/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3> xtensa-esp32-elf-addr2line -pfiaC -e build/ovms3.elf 0x4008f698 0x4008f86f 0x400e7027 0x400edb76 0x400edc8d 0x400edc7f 0x400edcb5 0x400e3908 0x400f11c9 0x400f1230 0x400e3937 0x401cb613 0x400e3f49 0x400e82e5 0x400e84d1 0x400e3df5 0x400e3e04 0x400e69dd 0x4008f698: invoke_abort at /home/balzer/esp/esp-idf/components/esp32/./panic.c:669 0x4008f86f: abort at /home/balzer/esp/esp-idf/components/esp32/./panic.c:669 0x400e7027: module_fault(int, OvmsWriter*, OvmsCommand*, int, char const* const*) at /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_module.cpp:823 0x400edb76: OvmsCommand::Execute(int, OvmsWriter*, int, char const* const*) at /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_command.cpp:94 0x400edc8d: OvmsCommand::Execute(int, OvmsWriter*, int, char const* const*) at /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_command.cpp:94 0x400edc7f: OvmsCommand::Execute(int, OvmsWriter*, int, char const* const*) at /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_command.cpp:94 0x400edcb5: OvmsCommandApp::Execute(int, OvmsWriter*, int, char const* const*) at /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_command.cpp:94 0x400e3908: Execute(microrl*, int, char const* const*) at /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_shell.cpp:47 0x400f11c9: new_line_handler at /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/microrl/./microrl.c:620 0x400f1230: microrl_insert_char at /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/microrl/./microrl.c:668 0x400e3937: OvmsShell::ProcessChar(char) at /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_shell.cpp:70 0x401cb613: OvmsShell::ProcessChars(char const*, int) at /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_shell.cpp:77 (discriminator 2) 0x400e3f49: ConsoleAsync::HandleDeviceEvent(void*) at /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./console_async.cpp:169 0x400e82e5: OvmsConsole::Poll(unsigned int, void*) at /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_console.cpp:152 0x400e84d1: OvmsConsole::Service() at /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_console.cpp:132 (discriminator 1) 0x400e3df5: ConsoleAsync::Service() at /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./console_async.cpp:80 0x400e3e04: non-virtual thunk to ConsoleAsync::Service() at ??:? 0x400e69dd: TaskBase::Task(void*) at /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./task_base.cpp:156 There is also an option to write core dumps in esp-idf, but a core has 64K, and crashes are still too many. I think the backtrace is sufficient in most situations. We should keep a central archive of .elf files for the releases rolled out, so we don't need to recompile for debugging. Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

3 8

Commit 6f732b2 issue without CONFIG_OVMS_COMP_OBD2ECU
by Julien “JaXX” Banchet 10 Apr '18

10 Apr '18

Hi, Just a heads up, seems commit 6f732b2 doesn’t like missing CONFIG_OVMS_COMP_OBD2ECU CXX build/pcp/pcp.o AR build/pcp/libpcp.a CC build/pthread/pthread.o CC build/pthread/pthread_cond_var.o CC build/pthread/pthread_local_storage.o AR build/pthread/libpthread.a CXX build/retools/src/retools.o /Users/jaxx/Projects/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/retools/src/retools.cpp: In function 'void re_list(int, OvmsWriter*, OvmsCommand*, int, const char* const*)': /Users/jaxx/Projects/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/retools/src/retools.cpp:260:91: error: 'FormatHexDump' was not declared in this scope FormatHexDump(&s, (const char*)it->second->last.data.u8, it->second->last.FIR.B.DLC, 8); ^ make[1]: *** [/Users/jaxx/Projects/esp-idf/make/component_wrapper.mk:274: src/retools.o] Error 1 make: *** [/Users/jaxx/Projects/esp-idf/make/project.mk:450: component-retools-build] Error 2 With CONFIG_OVMS_COMP_OBD2ECU=y it compiles fine. Regards, JB./.

2 1

Lost both modem and WiFi
by Greg D. 09 Apr '18

09 Apr '18

Hi folks, This occurred twice over the weekend... I took a trip in my Roadster with the OVMSv3 module hooked up. After the drive, I went to check on the car via the Android application, and it wouldn't connect. Thought perhaps it wasn't getting a good 3G signal where it was, and forgot about it overnight. But when I checked again in the morning, sill no connection. I looked in the car and saw that the modem was off (nothing blinking). Unplugged the module, and plugged it back in. All fine at that point. Charged the car for the trip home, and was able to monitor the charging just fine. Drove home late Sunday night, and when I looked at it again this morning (Monday), no modem blinks. Also failed connecting to it on the home WiFi, which it is configured to automatically connect to. I hooked up a serial port to the USB connector, and found that the module was running (OVMS prompts), but both the modem and wifi were reporting their status powered off! I just updated to today's code, and will try to reproduce the issue. In the mean time, any ideas what is going on? I do have scripts to control the ext12v power with vehicle_on and vehicle_off (to manage a HUD), but the HUD was not attached. Greg

2 1

Event task
by Mark Webb-Johnson 08 Apr '18

08 Apr '18

I’m seeing a timing/stack/mutex/whatever issue with the new 3.1 modules, regarding sd card auto-mounting at boot. Currently we are using a freertos timer to auto-mount this 500ms after insertion. That fires off some events (sd.inserted, sd.mounted) and I have a script on sd.mounted that does some things like turn on log file to /sd/ovms.log. That is failing (locking up SD). In general, as Michael pointed out, doing big things in freertos timers is not recommended. I tried a quick fix to change to use ticker.1 and housekeeping timers. But, then in ticker.1 we SignalEvent sd.inserted and sd.mounted, and that leads to a whole new set of problems (raising a signal inside a signal handler). Overall, it seems messy. The housekeeping task (where we like to run these things) is also very basic at the moment. I think the better solution maybe to remove the housekeeping task completely, and replace it with an event task reading events off a queue and firing them to all listeners. Then change SignalEvent to queue an event to the event task so that the event task fires the actual event in it’s own time and in it’s own large stack. The slight change here is that we would still guarantee in-order delivery of events raised, but the caller of SignalEvent would immediately get back control (even if the signal had not been dispatched to all listeners yet). OK? Any better suggestions? Regards, Mark

2 8

VFS / FAT deadlock
by Mark Webb-Johnson 08 Apr '18

08 Apr '18

That timing issue on headless boot-up, with 3.1 hardware, seems to be a deadlock within Espressif vfs/fat. I can repeat the issue by: Create a script /store/events/sd.mounted/logging: log file log file /sd/ovms.log log level verbose log level info ssh Unplug USB Power up module from 12V supply Any tasks accessing SD CARD will lock-up, sometime during the boot. Accessing other VFS areas seems ok. Can re-connect USB and come in with terminal emulator, ten seconds or more after boot, to examine the stack/etc. Here is the task status: OVMS# module tasks stack Number of Tasks = 16 Stack: Now Max Total Heap 32-bit SPIRAM 3FFAFB48 1 Blk esp_timer 388 548 4096 38080 644 21756 0x400dc0e3 0x4008ebed 3FFBDD5C 2 Blk eventTask 440 1208 4608 0 0 0 0x401b3814 0x4008ebed 0x401bcc06 3FFBFB58 3 Blk OVMS Events 1204 3812 6144 77388 0 6608 0x4008526a 0x4008ebed 0x4015e6b5 0x4008533c 0x401e2e53 0x40096a8c 0x4015eb7d 0x400e585a 0x400e6ece 0x400e4450 0x40085148 0x400eaec3 0x400eb768 0x400e9d1c 0x400ea6ec 0x400ea7f8 0x4008ebed 0x400ea808 3FFC4794 4 Blk OVMS CanRx 432 432 1024 0 0 0 0x400d39fd 0x4008ebed 3FFC884C 5 Blk ipc0 392 424 1024 7776 0 0 0x4008240b 0x4008ebed 0x400814fd 3FFC8E4C 6 Blk ipc1 392 504 1024 12 0 0 0x4008240b 0x4008ebed 0x40081590 3FFCAC74 9 Rdy IDLE 368 496 1024 0 0 0 0x4008fd60 3FFCB208 10 Rdy IDLE 356 484 1024 0 0 0 0x4008fd60 0x4008e0b7 0x4008e0b7 3FFCBF9C 11 Blk Tmr Svc 392 872 3072 0 0 168816 0x40090cdf 0x40090be4 3FFCF9F4 16 Blk tiT 492 700 3072 232 0 148 0x401fc049 0x4008ebed 0x40091ef6 0x401effe8 0x401f000c 0x401e7562 0x401e7562 3FFD5CA4 17 Blk OVMS SIMCOM 1584 2400 4096 284 0 0 0x4008526a 0x4008ebed 0x4015e6b5 0x4008533c 0x40000000 0x401e2e53 0x4015eb7d 0x400e585a 0x400e6ece 0x400e4450 0x40085148 0x40216acc 0x402177dc 0x401df626 0x401df4d5 0x401dfa38 0x401dfa8b 0x401e189e 0x401e2e69 0x4015eb7d 0x400e585a 0x400e6ece 0x400e4450 0x40085148 0x401379b5 0x400e58a1 0x40137a1b 0x40137a68 3FFD7C54 18 Blk wifi 432 1824 4096 240 0 1092 0x4008ab40 0x4008ebed 3FFDA3EC 19 Blk pmT 408 568 2560 0 0 0 0x401cb6c9 0x4008ebed 0x401cb751 3FFDAA04 20 Blk OVMS Vehicle 452 452 3072 0 0 0 0x4013ce45 0x4008ebed 0x4021f6e9 3FFDEC24 21 Rdy OVMS Console 760 3048 6144 220 15488 12000 0x400e6790 0x400f2a3b 0x400f6517 0x400f6585 0x400f2a72 0x400e9830 0x40197436 0x4021f01e 0x400e4508 0x400e986c 0x400e9a68 0x400e43ac 0x400e43bb 0x400f5280 3FFDF604 22 Blk mdns 412 412 4096 0 0 0 0x4020bae6 0x4008ebed The interesting tasks are OVMS Events: $ ~/esp/xtensa-esp32-elf/bin/xtensa-esp32-elf-addr2line -pfiaC -e build/ovms3.elf 0x4008526a 0x4008ebed 0x4015e6b5 0x4008533c 0x401e2e53 0x40096a8c 0x4015eb7d 0x400e585a 0x400e6ece 0x400e4450 0x40085148 0x400eaec3 0x400eb768 0x400e9d1c 0x400ea6ec 0x400ea7f8 0x4008ebed 0x400ea808 0x4008526a: lock_acquire_generic at /Users/mark/esp/esp-idf/components/newlib/./locks.c:157 0x4008ebed: xQueueGenericReceive at /Users/mark/esp/esp-idf/components/freertos/./queue.c:2037 0x4015e6b5: esp_vfs_write at /Users/mark/esp/esp-idf/components/vfs/./vfs.c:540 0x4008533c: _lock_acquire at /Users/mark/esp/esp-idf/components/newlib/./locks.c:165 0x401e2e53: vfs_fat_fsync at /Users/mark/esp/esp-idf/components/fatfs/src/vfs_fat.c:350 0x40096a8c: _fflush_r at /home/jeroen/esp8266/esp32/newlib_xtensa-2.2.0-bin/newlib_xtensa-2.2.0/xtensa-esp32-elf/newlib/libc/stdio/../../../.././newlib/libc/stdio/fflush.c:282 0x4015eb7d: fsync at /Users/mark/esp/esp-idf/components/vfs/./vfs.c:552 (discriminator 3) 0x400e585a: OvmsCommandApp::LogBuffer(LogBuffers*, char const*, __va_list_tag) at /Users/mark/Documents/ovms/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_command.cpp:94 0x400e6ece: OvmsCommandApp::Log(char const*, __va_list_tag) at /Users/mark/Documents/ovms/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_command.cpp:94 0x400e4450: ConsoleAsync::ConsoleLogger(char const*, __va_list_tag) at /Users/mark/Documents/ovms/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./console_async.cpp:118 0x40085148: esp_log_write at /Users/mark/esp/esp-idf/components/log/./log.c:215 0x400eaec3: Housekeeping::Metrics(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, void*) at /Users/mark/Documents/ovms/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_housekeeping.cpp:221 0x400eb768: std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_data() const at /Users/mark/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.h:135 (inlined by) std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_is_local() const at /Users/mark/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.h:170 (inlined by) std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_dispose() at /Users/mark/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.h:179 (inlined by) std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string() at /Users/mark/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.h:544 (inlined by) void std::_Mem_fn_base<void (Housekeeping::*)(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, void*), true>::operator()<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, void*, void>(Housekeeping*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&&, void*&&) const at /Users/mark/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/functional:600 (inlined by) void std::_Bind<std::_Mem_fn<void (Housekeeping::*)(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, void*)> (Housekeeping*, std::_Placeholder<1>, std::_Placeholder<2>)>::__call<void, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&&, void*&&, 0u, 1u, 2u>(std::tuple<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&&, void*&&>&&, std::_Index_tuple<0u, 1u, 2u>) at /Users/mark/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/functional:1074 (inlined by) void std::_Bind<std::_Mem_fn<void (Housekeeping::*)(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, void*)> (Housekeeping*, std::_Placeholder<1>, std::_Placeholder<2>)>::operator()<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, void*, void>(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&&, void*&&) at /Users/mark/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/functional:1133 (inlined by) std::_Function_handler<void (std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, void*), std::_Bind<std::_Mem_fn<void (Housekeeping::*)(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, void*)> (Housekeeping*, std::_Placeholder<1>, std::_Placeholder<2>)> >::_M_invoke(std::_Any_data const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&&, void*&&) at /Users/mark/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/functional:1871 0x400e9d1c: std::function<void (std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, void*)>::operator()(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, void*) const at /Users/mark/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/functional:2271 0x400ea6ec: std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_data() const at /Users/mark/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.h:135 (inlined by) std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_is_local() const at /Users/mark/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.h:170 (inlined by) std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_dispose() at /Users/mark/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.h:179 (inlined by) std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string() at /Users/mark/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.h:544 (inlined by) OvmsEvents::HandleQueueSignalEvent(event_queue_t*) at /Users/mark/Documents/ovms/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_events.cpp:152 0x400ea7f8: OvmsEvents::EventTask() at /Users/mark/Documents/ovms/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_events.cpp:126 0x4008ebed: xQueueGenericReceive at /Users/mark/esp/esp-idf/components/freertos/./queue.c:2037 0x400ea808: std::_Rb_tree<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::list<EventCallbackEntry*, std::allocator<EventCallbackEntry*> >*>, std::_Select1st<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::list<EventCallbackEntry*, std::allocator<EventCallbackEntry*> >*> >, std::less<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::list<EventCallbackEntry*, std::allocator<EventCallbackEntry*> >*> > >::_M_get_insert_unique_pos(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) at /Users/mark/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/stl_tree.h:1800 And OVMS SIMCOM: $ ~/esp/xtensa-esp32-elf/bin/xtensa-esp32-elf-addr2line -pfiaC -e build/ovms3.elf 0x4008526a 0x4008ebed 0x4015e6b5 0x4008533c 0x40000000 0x401e2e53 0x4015eb7d 0x400e585a 0x400e6ece 0x400e4450 0x40085148 0x40216acc 0x402177dc 0x401df626 0x401df4d5 0x401dfa38 0x401dfa8b 0x401e189e 0x401e2e69 0x4015eb7d 0x400e585a 0x400e6ece 0x400e4450 0x40085148 0x401379b5 0x400e58a1 0x40137a1b 0x40137a68 0x4008526a: lock_acquire_generic at /Users/mark/esp/esp-idf/components/newlib/./locks.c:157 0x4008ebed: xQueueGenericReceive at /Users/mark/esp/esp-idf/components/freertos/./queue.c:2037 0x4015e6b5: esp_vfs_write at /Users/mark/esp/esp-idf/components/vfs/./vfs.c:540 0x4008533c: _lock_acquire at /Users/mark/esp/esp-idf/components/newlib/./locks.c:165 0x40000000: ?? ??:0 0x401e2e53: vfs_fat_fsync at /Users/mark/esp/esp-idf/components/fatfs/src/vfs_fat.c:350 0x4015eb7d: fsync at /Users/mark/esp/esp-idf/components/vfs/./vfs.c:552 (discriminator 3) 0x400e585a: OvmsCommandApp::LogBuffer(LogBuffers*, char const*, __va_list_tag) at /Users/mark/Documents/ovms/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_command.cpp:94 0x400e6ece: OvmsCommandApp::Log(char const*, __va_list_tag) at /Users/mark/Documents/ovms/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_command.cpp:94 0x400e4450: ConsoleAsync::ConsoleLogger(char const*, __va_list_tag) at /Users/mark/Documents/ovms/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./console_async.cpp:118 0x40085148: esp_log_write at /Users/mark/esp/esp-idf/components/log/./log.c:215 0x40216acc: sdmmc_write_sectors_dma at /Users/mark/esp/esp-idf/components/sdmmc/./sdmmc_cmd.c:361 (discriminator 4) 0x402177dc: sdmmc_write_sectors at /Users/mark/esp/esp-idf/components/sdmmc/./sdmmc_cmd.c:750 0x401df626: ff_sdmmc_write at /Users/mark/esp/esp-idf/components/fatfs/src/diskio_sdmmc.c:51 0x401df4d5: ff_disk_write at /Users/mark/esp/esp-idf/components/fatfs/src/diskio.c:74 0x401dfa38: sync_window at /Users/mark/esp/esp-idf/components/fatfs/src/ff.c:4730 0x401dfa8b: move_window at /Users/mark/esp/esp-idf/components/fatfs/src/ff.c:4730 0x401e189e: f_sync at /Users/mark/esp/esp-idf/components/fatfs/src/ff.c:4730 0x401e2e69: vfs_fat_fsync at /Users/mark/esp/esp-idf/components/fatfs/src/vfs_fat.c:351 0x4015eb7d: fsync at /Users/mark/esp/esp-idf/components/vfs/./vfs.c:552 (discriminator 3) 0x400e585a: OvmsCommandApp::LogBuffer(LogBuffers*, char const*, __va_list_tag) at /Users/mark/Documents/ovms/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_command.cpp:94 0x400e6ece: OvmsCommandApp::Log(char const*, __va_list_tag) at /Users/mark/Documents/ovms/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_command.cpp:94 0x400e4450: ConsoleAsync::ConsoleLogger(char const*, __va_list_tag) at /Users/mark/Documents/ovms/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./console_async.cpp:118 0x40085148: esp_log_write at /Users/mark/esp/esp-idf/components/log/./log.c:215 0x401379b5: simcom::Task() at /Users/mark/Documents/ovms/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/simcom/src/simcom.cpp:88 0x400e58a1: OvmsCommandApp::HexDump(char const*, char const*, char const*, unsigned int, unsigned int) at /Users/mark/Documents/ovms/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_command.cpp:94 0x40137a1b: simcom::Task() at /Users/mark/Documents/ovms/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/simcom/src/simcom.cpp:105 0x40137a68: simcom::State1Ticker1() at /Users/mark/Documents/ovms/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/simcom/src/simcom.cpp:523 The other tasks all look ok. From what I can see, the task producing the log entry is dong a fsync, which presumably locks fat then locks vfs. Then another task tries to do a log as well, and gets locked up. If I comment-out the fsync in OvmsCommandApp::LogBuffer of ovms_command.cpp (line 614), it seems to avoid the problem. I’ve partially worked around the problem by introducing a mutex lock in ovms_command.cpp, when writing to the log file. That avoids the issue in ESP IDF. I’ve also raised it to Espressif. * b38b0ef (HEAD -> master, origin/master, origin/HEAD) Mutex protect fsync function call, on logging, to workaround ESP IDF bug https://github.com/espressif/esp-idf/issues/1837 It is an ugly solution, and doesn’t seem 100% effective. I’m really not sure what is going on. Any ideas? Regards, Mark.

1 0

Getting Started with OVMS v3.1
by Mark Webb-Johnson 07 Apr '18

07 Apr '18

FYI: Email sent to all purchasers of OVMS v3.1 modules Firstly, thank you for your support of the Open Vehicles project. As the first production batch of OVMS v3.1 kits has been shipped, you should be receiving yours any day now (if not already), we thought it useful to give you a few pointers for getting started with OVMS v3.1. 1] Unboxing There is a short unboxing video on youtube. It gives an overview of what is in the kit, and what you can do to get started: https://www.youtube.com/watch?v=HpyI1q4Y89I <https://www.youtube.com/watch?v=HpyI1q4Y89I> 2] User Guide Work on the user guide has begun, but is just starting and the document is expected to evolve rapidly over the coming weeks and months. You can always find the latest version here: https://docs.google.com/document/d/16JrXR7rybp-18DrEoeh1rg6GqQT_jVBvhaXh2oE… <https://docs.google.com/document/d/16JrXR7rybp-18DrEoeh1rg6GqQT_jVBvhaXh2oE…> You can comment directly on that document, and suggest revisions. If you would like to volunteer to help extend it, that would be most appreciated - please let us know and we’ll open up more access to it for you. 3] Hologram To simplify getting started, a Hologram SIM has been included with the modem in every OVMS v3.1 kit. Hologram have also kindly provided a coupon code “OVMS” that can be used to get US$5 credit; this can be used for both existing as well as new Hologram customers. You can simply enter that coupon code at checkout (when purchasing data credits, etc). When activating your Hologram SIM, you’ll need to enter the ICCID written on the SIM itself. You can also get that electronically (without having to open up the package) from the web or terminal shells with the following command: OVMS# metric list m.net.mdm.iccid 4] Firmware Status The firmware is continually evolving on a daily basis, and the development team regularly releases updates for over-the-air download and install. In these early days of production v3.1, it is important that you update your firmware on a regular basis. Please make sure you are running the latest firmware before reporting an issue. The simplest way to update the module firmware is to connect it as a client to your wifi network (or phone hotspot), and then use the web interface Config / Firmware / Flash-from-Web; that will show you the version you are running, as well as the latest version available for update. One click on 'Flash now' and the update will be downloaded and installed. Alternatively, you can download the firmware update to a file named ovms3.bin in the root directory of a FAT formatted SD CARD and insert the card into the module's slot - the new firmware will be updated automatically and the file renamed ovms3.done to signify completion. 5] Support Please remember that this first production batch is intended for experienced OVMS v2 users and v3 developers, and note: Firmware is not complete, and should be considered beta. Functionality is approximately equivalent to basic OVMS v2 firmware, but some advanced features (such as ACC, SMS control, etc) are not available yet. Firmware is far in advance of v2 in other aspects (such as built in web server, metrics, console, tcp/ip support, diagnostics, geofencing, scripting, etc). Firmware can be updated either Over The Air (OTA), by Micro SD card, or over USB interface. Vehicle support currently includes: Kia Soul EV, Nissan Leaf, Renault Twizy, and Tesla Roadster. If you do experience a problem, or need assistance, please start by talking to other OVMS v3.1 users/developers in your area. If you still can't solve the issue, then eMail support(a)openvehicles.com <mailto:support@openvehicles.com>. Software issues can be reported directly to the project GitHub issue tracker here: https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues> Thank you for your support of the project. Open Vehicles

1 0

Problem switching to Range mode charging (TR)
by Greg D. 07 Apr '18

07 Apr '18

Hi folks, To the Roadster owners among us... I just tried switching my 2.0 Roadster from Standard to Range mode charging, and there was an unusual "pop", similar to the car or OpenEVSE contactors engaging, but louder, followed by all the fans going off and a "Power Train Service Required" error on the display. Tapping away the message, the car started charging in Range mode as normal... Odd, and rather unnerving, given that I'm heading out on a trip shortly. I'll pull the logs when I return. This was my first experience using the OVMS system to control charging. I don't want to try it again. Has anyone else tried doing this? Greg

2 8

OTA status check timeout / SSL problem?
by Michael Balzer 07 Apr '18

07 Apr '18

Mark, the server check for an OTA update now fails every time, times out after 10 seconds. I think that's because the new server currently does a redirect from http to https also on the api.openvehicles.com host. Not sure why the module doesn't fail directly on that, maybe it tries to validate the certificate which also does not match. As the openvehicles server has frequent connectivity issues from here I've added a "nocheck" option to the ota status command and use that for the standard web status page. The OTA page still checks for the update. Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

3 7