- OvmsDev - Open Vehicles

Tesla Cables
by Mark Webb-Johnson 09 Aug '18

09 Aug '18

I have a suggested pinout for future Tesla Cables: X437 DB9 Signal -------- -------- -------- 1 7 CAN0-H 2 8 CAN2-H 3 1 K-Line 4 5 CAN1-H 6 2 CAN0-L 7 6 CAN2-L 9 3 GND 10 9 +12V 11 4 CAN1-L This new cable could work for both Roadster and Model S. The previous pinout did not populate DB9 pins 1, 4, 5, 6, or 8 (so only GND, +12V, CAN0-H, and CAN0-L were connected). For Tesla Roadster, that gives us access to all three CAN buses (and opens up a lot of opportunities): CAN0 - Instrumentation (VDS, TPMS, etc) CAN1 - SwitchPack / PEM CAN2 - HVAC and Battery K-Line (OBDII K-Line) For Tesla Model S and X (2014 and before), that gives us access to three of the four CAN buses (of which the PowerTrain and Chassis seem the most useful, and BodyFaultTolerant has remote climate control module on it): CAN0 - PowerTrain CAN bus CAN1 - Chassis CAN bus CAN2 - BodyFaultTolerant CAN bus K-Line (OBDII K-Line) For new Model S and X (with X437A connector), the DB9 side pinouts should be the same. I am currently trying to source a good supplier for the new style vehicle side connectors. I’ve also wired in the K-Line into the unused pin #1 of our DB9 connector (even though that is not currently connected to anything). I am working with China side to see how we can connect that up (either via direct support chip in a future module, or via expansion board). Existing modules would require a mod to work with that (but not too hard to do). As usual, suggestions / comments, and double-checking of the pinouts would be most appreciated. Regards, Mark.

1 1

Android App build issue
by Mark Webb-Johnson 09 Aug '18

09 Aug '18

Michael: Can you help this guy working on the Android App? A google search came up with this: https://stackoverflow.com/questions/24998368/the-import-android-support-v7-… <https://stackoverflow.com/questions/24998368/the-import-android-support-v7-…> which is possibly relevant. Thanks, Mark.

1 1

Re: [Ovmsdev] OVMS v3.1 crashes during boot continuously
by Henrik Scheel 08 Aug '18

08 Aug '18

> welcome :) Thanks :-) > See https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/148 > ?and the new 12V section in the user guide. Ok, I will look into that when I have a functioning module. > So the Soul doesn't top up the 12V battery from the main battery? How much capacity does the 12V battery have on the Soul? Kia Soul EV does not top up the 12 Volt battery when off. The capacity is 50 Ah. If I recall correctly, the original battery had 48 Ah. > See https://github.com/espressif/esptool/wiki/espefuse -- you can try the dump command and send the results to Espressif. If your ESP32 really lost its efuses, > I think that's a warranty issue. I ran the dump. It did not report CRC error, nor all1’s or 0’s. Is there any reason not to share the output from the dump command publicly? I am guessing the current rebooting issue could be an issue with my build. It is my first OVMS build, based on sources pulled Aug 4, and I may have done something wrong, have the wrong version of some tool installed, or something may have changed in the repos since the developer guide was last tested by someone. Can I download bootloader.bin, ovms3.bin and partitions.bin from somewhere, and flash those instead of my build? Henriks-MBP:OVMS.V3 henrik$ make print_flash_cmd --flash_mode dio --flash_freq 40m --flash_size detect 0x1000 bootloader/bootloader.bin 0x10000 ovms3.bin 0x8000 partitions.bin Is “make flash” always supposed to bring the device to a functioning state, when configured and built as described in the developer config (i.e. by cp support/sdkconfig.default.hw31 sdkconfig and then make menuconfig)? I seem to get errors when connecting to the device, e.g. when flashing: … AR build/xtensa-debug-module/libxtensa-debug-module.a LD build/ovms3.elf esptool.py v2.3.1 Flashing binaries to serial port /dev/tty.SLAB_USBtoUART (app at offset 0x10000 )... esptool.py v2.3.1 Traceback (most recent call last): File "/Users/henrik/esp/esp-idf/components/esptool_py/esptool/esptool.py", line 2637, in <module> _main() File "/Users/henrik/esp/esp-idf/components/esptool_py/esptool/esptool.py", line 2630, in _main main() File "/Users/henrik/esp/esp-idf/components/esptool_py/esptool/esptool.py", line 2355, in main esp = chip_class(args.port, initial_baud, args.trace) File "/Users/henrik/esp/esp-idf/components/esptool_py/esptool/esptool.py", line 193, in __init__ self._port = serial.serial_for_url(port) File "/Library/Python/2.7/site-packages/serial/__init__.py", line 88, in serial_for_url instance.open() File "/Library/Python/2.7/site-packages/serial/serialposix.py", line 272, in open self._reconfigure_port(force_update=True) File "/Library/Python/2.7/site-packages/serial/serialposix.py", line 438, in _reconfigure_port [iflag, oflag, cflag, lflag, ispeed, ospeed, cc]) termios.error: (22, 'Invalid argument') make: *** [flash] Error 1 Henriks-MBP:OVMS.V3 henrik$ make flash Flashing binaries to serial port /dev/tty.SLAB_USBtoUART (app at offset 0x10000 )... esptool.py v2.3.1 Connecting........_____....._____....._____....._____....._____....._____....._____....._____....._____....._____ A fatal error occurred: Failed to connect to ESP32: Timed out waiting for packet header make: *** [flash] Error 2 Henriks-MBP:OVMS.V3 henrik$ Could all of this conceivably be caused by “bad” USB hardware? I connect the device via a cheap Hama device for converting my thunderbolt port to standard USB. Best regards, Henrik -- Venlig hilsen / best regards Henrik R. Scheel Spjeldager Consult ApS Spjeldager 9 DK-2630 Taastrup CVR: 34491399 T: +45 2720 9828 http://www.spjeldager.dk/

3 4

Extending the information shown in the app and on dashboard
by Nikolay Shishkov 08 Aug '18

08 Aug '18

I am looking at ways to communicated some status data that would be helpful to the driver of the Think.Stuff like: - estimated time to charge to 100% - average kwh/km for a trip (or maybe even lifetime?) - min, avg, max cell values for cars with lithium packs - maybe even a bar graphs that show all cell voltages and temperatures - possibility to run simple diagnostics - like show error codes, send error codes to e-mail, reset error codes - producing/sharing a log of trips with essential data (distance, kwh used, and some stats - speed, kW, temperatures) I can see some very interesting stuff in the dashboard, and some of the pages for Twizy and Kia... and would appreciate some ideas on how to implement some of these. For example estimated time to end of charge is something I would like to be visible in the app, while diagnostics could be enough to be a web page. What is the easiest or the best way to extend the information shown in the app? In the simplest possible way - no graphics, just a list a name and value? Nikolay

2 1

signed 2 byte values in poll
by Nikolay Shishkov 07 Aug '18

07 Aug '18

So this is another thing that took more time than I can spare for it... and I am still curious to see what would be the correct way of doing it. I have configured the polling to ask an ecu about couple of values of temperatures. The response message can be received both in the IncomingFrameCan1 and IncomingPollReply. The code for reading the values in the respective functions is as follows: void OvmsVehicleThinkCity::IncomingPollReply(canbus* bus, uint16_t type, uint16_t pid, uint8_t* data, uint8_t length, uint16_t mlremain) { //ESP_LOGI(TAG,"Poll replay arrived %d", pid); uint8_t value = *data; switch (pid) { case 0x4965: StandardMetrics.ms_v_charge_temp->SetValue((float)((short)value) / 100.0f); break; case 0x4966: StandardMetrics.ms_v_inv_temp->SetValue((float)((short)value) / 100.0f); break; case 0x4967: StandardMetrics.ms_v_mot_temp->SetValue((float)((short)value) / 100.0f); break; case 0x4968: tc_slibatt_temp =(float)((short)value) / 100.0f; break; default: break; } } And the following code in IncomingFrameCan1: case 0x75B: if (d[3] == 0x65) { StandardMetrics.ms_v_charge_temp->SetValue((float)((short) (d[4] << 8) | d[5]) / 100.0f); } else if (d[3] == 0x66) { StandardMetrics.ms_v_inv_temp->SetValue((float)((short) (d[4] << 8) | d[5]) / 100.0f); } else if (d[3] == 0x67) { StandardMetrics.ms_v_mot_temp->SetValue((float)((short) (d[4] << 8) | d[5]) / 100.0f); } else if (d[3] == 0x68) { tc_slibatt_temp = (float)((short) (d[4] << 8) | d[5]) / 100.0f; } I am getting correct values in the IncomingFrameCan1 version, while the first version returns completely different values. Any idea why? Thanks again,Nikolay On Saturday, August 4, 2018, 1:59:03 AM GMT+2, Nikolay Shishkov <nshishkov(a)yahoo.com> wrote: Fixed some stuff and added some for the Think City. There is still more to be done but here is the status so far. https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/150 On Wednesday, August 1, 2018, 9:46:12 PM GMT+2, Michael Balzer <dexter(a)expeedo.de> wrote: Forgot: the streaming mode (feature #8 / config vehicle stream) is an option to raise the location update frequency when the car is on. It's now interpreted as the interval in seconds, so "1" will give you per second updates. Regards, Michael Am 01.08.2018 um 21:40 schrieb Michael Balzer: Nikolay, see config → server v2 → update intervals. Regarding speed, you do provide it: StandardMetrics.ms_v_pos_speed->SetValue(((unsigned char) d[5]) / 2); …that's line 65 of the thinkcity module. There is no fallback to GPS speed. Regards, Michael Am 01.08.2018 um 21:10 schrieb Nikolay Shishkov: That same module has not crashed in almost a week now. So maybe there was something that was not connected to Think City code and got fixed by some of the library fixes. I noticed that it takes almost half a minute for the gps location to update in the app. The same goes for the speed and other parameters. Is there a setting to make that more frequent? Also - I can see speed, but I am not providing it - is it coming from the GPS? Thanks again! On Wednesday, August 1, 2018, 1:11:49 AM GMT+2, Nikolay Shishkov <nshishkov(a)yahoo.com> wrote: Thanks Michael, I did not refresh the mail thread and saw you answer after I posted my solution. I see about the states and the timing now... I may need to adjust this accordingly. I thought it was in milliseconds... These are all temperatures that are changing quite slow. So every 1 second or 4 seconds is perfectly fine. Hopefully I will have access to a car tomorrow and can test this. Thanks again, Nikolay On Wednesday, August 1, 2018, 1:06:32 AM GMT+2, Nikolay Shishkov <nshishkov(a)yahoo.com> wrote: I think I found a solution. Have not tested it yet. static const OvmsVehicle::poll_pid_t obdii_polls[] = { // 0x753 03 22 49 65 - charger temp { 0x753, 0x75B,VEHICLE_POLL_TYPE_OBDIIEXTENDED, 0x4965, { 0, 999, 999 } }, // 0x753 03 22 49 66 - pcu heat sink temp { 0x753, 0x75B,VEHICLE_POLL_TYPE_OBDIIEXTENDED, 0x4966, { 0, 999, 999 } }, // 0x753 03 22 49 67 - motor temp { 0x753, 0x75B,VEHICLE_POLL_TYPE_OBDIIEXTENDED, 0x4967, { 0, 999, 999 } }, // 0x753 03 22 49 68 - sli batt temp and volts { 0x753, 0x75B,VEHICLE_POLL_TYPE_OBDIIEXTENDED, 0x4968, { 0, 200, 200 } }, { 0, 0, 0x00, 0x00, { 0, 0, 0 } } }; On Tuesday, July 31, 2018, 8:57:51 PM GMT+2, Nikolay Shishkov <nshishkov(a)yahoo.com> wrote: Quick question. How do I convert this: while (TXB0CONbits.TXREQ) {} // Loop until TX is done TXB0CON = 0; TXB0SIDL = 0b01100000; TXB0SIDH = 0b11101010; TXB0D0 = 0x03; TXB0D1 = 0x22; TXB0D2 = 0x49; TXB0D3 = 0x65; TXB0DLC = 0b00000100; // data length (4) TXB0CON = 0b00001000; // mark for transmission delay100b(); // Delay a little... (100ms, approx) while (TXB0CONbits.TXREQ) {} // Loop until TX is done TXB0CON = 0; TXB0SIDL = 0b01100000; TXB0SIDH = 0b11101010; TXB0D0 = 0x03; TXB0D1 = 0x22; TXB0D2 = 0x49; TXB0D3 = 0x66; TXB0DLC = 0b00000100; // data length (4) TXB0CON = 0b00001000; // mark for transmission delay100b(); // Delay a little... (100ms, approx) while (TXB0CONbits.TXREQ) {} // Loop until TX is done TXB0CON = 0; TXB0SIDL = 0b01100000; TXB0SIDH = 0b11101010; TXB0D0 = 0x03; TXB0D1 = 0x22; TXB0D2 = 0x49; TXB0D3 = 0x67; TXB0DLC = 0b00000100; // data length (4) TXB0CON = 0b00001000; // mark for transmission delay100b(); // Delay a little... (100ms, approx) while (TXB0CONbits.TXREQ) {} // Loop until TX is done TXB0CON = 0; TXB0SIDL = 0b01100000; TXB0SIDH = 0b11101010; TXB0D0 = 0x03; TXB0D1 = 0x22; TXB0D2 = 0x49; TXB0D3 = 0x68; TXB0DLC = 0b00000100; // data length (4) TXB0CON = 0b00001000; // mark for transmission delay100b(); // Delay a little... (100ms, approx) To the new polling framework? I took a look at the leaf code, but the configuration is a mystery to me. What are the input parameters? Maybe there is a document that I am missing? Thanks in advance, Nikolay On Saturday, July 28, 2018, 11:42:13 PM GMT+2, Nikolay Shishkov <nshishkov(a)yahoo.com> wrote: Thank you! Yes the carid is TC003. I was not running anything extraordinary - just followed the developer tutorial, but never flashed directly - always flashed from edge branch OTA. I will run the commands and provide output, but it will be with the newer firmware. I will need to see if updating will have same problems. On Friday, July 27, 2018, 3:07:09 AM GMT+2, Mark Webb-Johnson <mark(a)webb-johnson.net> wrote: Note that I store the .elf files alongside the .bin, for edge/eap/main builds. For example: http://api.openvehicles.com/firmware/ota/v3.1/edge/3.1.008-29-gaf41242.ovms… Regards, Mark. On 27 Jul 2018, at 5:51 AM, Michael Balzer <dexter(a)expeedo.de> wrote: Nikolay, you need to keep the .elf files for your builds to be able to analyze a backtrace. Do not use addr2line, it shows wrong line numbers. Use the script "a2l" I posted previously (I'll include it again below). Just feed it the .elf file and the backtrace. Example: a2ltmp/3.1.008-32-g2fa3ab8-elf/ovms3.elf 0x400dc8ec 0x4008f43d 0x4008e181 0x400818cc 0x40082163 0x40083c4d 0x400dc8e9 (I don't have the -28- version, so my output doesn't make sense) @Mark: spurious task WDT crashes and heap corruption crashes still occur, but it seems they have become less often with the internal RAM rework. How is performance and power usage affected when using StandardMetrics.xxxxx->SetValue in the IncomingFrameCan1 method? Most of the messages update value every 100ms, and except maybe speed, battery current and voltage, most of the parameters are not changing that often. And even for the speed, current and voltage, it is probably enough to update StandardMetrics in the 1 second ticker... does this make sense or is the difference non-existing. Extending Mark's answer: It's normally OK to directly set metrics from IncomingFrameCan1(), but be aware metrics listeners will be executed synchronously in the context that changes the metric. Standard metrics listeners are now for example the automatic notification generators in the vehicle base class. These may need quite some stack and time. If you spend too much time handling frames on a high volume bus, your vehicle task may lose frames. It's possible to raise the queue size (currently 20 frames) and the vehicle task stack size, but it's better to keep the CAN processing simple. TL;DR: if you need to handle many CAN frames, I recommend changing metrics that trigger notifications or other complex actions from the ticker. If you encounter crashes on some CAN frames that may be due to the vehicle task stack being too small (CONFIG_OVMS_VEHICLE_RXTASK_STACK=6144). Regards, Michael Script a2l: #!/bin/bash elf=~/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/ovms3.elf for adr in $* ; do if [[ "$adr" =~ "elf" ]] ; then elf="$adr" else cmd+=" -ex 'l *$adr'" fi done cmd+=" -ex 'q'" echo "Using elf file: $elf" evalxtensa-esp32-elf-gdb -batch $elf $cmd 2>/dev/null #| grep "^0x.* is in " Am 26.07.2018 um 09:59 schrieb Nikolay Shishkov: Quick update: I managed to do a not so quick update on one of the ovms v.3 boxes that sits in a Think and can confirm that the porting seems to work. I could see speed, parking time, ambient temperature. I had very strange problems doing the OTA update. The firmware start download and I can see the messages progressing, but it would halt in between 700kB and 1600kB and then stay there until I refresh the browser. And when I refresh the browser I am asked of my password which leads me to that there must have been a crash in the meantime. I was finally able to get the OTA update work by disconnecting the box from the car and powering it via USB. This is a single data point but it kind of points to a problem with the code that communicates with the car. I was not able to get a laptop connected to checkout the console, but managed to get the following log - not sure how to interpret it. Last boot was 87 second(s) ago Time at boot: 2018-07-25 18:07:43 GMT This is reset #3 since last power cycle Detected boot reason: Crash (12/12) Crash counters: 3 total, 0 early Last crash: Alloca exception on core 0 Registers: PC : 0x400dc8ec PS : 0x00060234 A0 : 0x8008f440 A1 : 0x3ffc45b0 A2 : 0x00000020 A3 : 0x00000001 A4 : 0x00000000 A5 : 0x3ffb44b8 A6 : 0x3ffb47e4 A7 : 0x3ffb458c A8 : 0x3ffb44d4 A9 : 0x3ffc4590 A10 : 0x00000000 A11 : 0x7fffffff A12 : 0x8008e65b A13 : 0x3ffcc450 A14 : 0x00000003 A15 : 0x00060023 SAR : 0x00000000 EXCCAUSE: 0x00000005 EXCVADDR: 0x00000000 LBEG : 0x00000000 LEND : 0x00000000 LCOUNT : 0x00000000 Backtrace: 0x400dc8ec 0x4008f43d 0x4008e181 0x400818cc 0x40082163 0x40083c4d 0x400dc8e9 Version:3.1.008-29-gaf41242/ota_1/edge (build idf v3.1-dev-987-g55d915e Jul 6 2018 00:14:59) Running partition: ota_1 Boot partition: ota_1 Firmware:3.1.008-29-gaf41242/ota_1/edge (build idf v3.1-dev-987-g55d915e Jul 6 2018 00:14:59) How is performance and power usage affected when using StandardMetrics.xxxxx->SetValue in the IncomingFrameCan1 method? Most of the messages update value every 100ms, and except maybe speed, battery current and voltage, most of the parameters are not changing that often. And even for the speed, current and voltage, it is probably enough to update StandardMetrics in the 1 second ticker... does this make sense or is the difference non-existing. Thanks for all the hand holding and help, Nikolay -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 _______________________________________________ OvmsDev mailing list OvmsDev(a)lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev _______________________________________________ OvmsDev mailing list OvmsDev(a)lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev _______________________________________________ OvmsDev mailing list OvmsDev(a)lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 _______________________________________________ OvmsDev mailing list OvmsDev(a)lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 _______________________________________________ OvmsDev mailing list OvmsDev(a)lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev

2 2

App thinks the car is not charging while it is charging
by Nikolay Shishkov 05 Aug '18

05 Aug '18

I am having trouble with the ported code where the app does not want to show the stick with info on charging current and voltage.I connected to the ovms and in the serial console I could see that the S message was stating "charging", while the P was stating "not charging" (see the log at the end of the message)... so I did dig and found a piece of code in the vehicle.cpp that uses ms_v_door_chargeport metric to determine if charging or not. bool chargeport_open = StdMetrics.ms_v_door_chargeport->AsBool(); if (chargeport_open) I am planning to add this to my code, but am wondering if this is the ok? Is this what the app uses to show the stick with the info from the AC outlet?Think City does not have a chargeport message, but even if it did, is this really the way? Here is the relevant part of the log:I (7316) ovms-server-v2: Incoming Msg: MP-0 Z1I (7316) ovms-server-v2: One or more peers have connectedI (7496) ovms-server-v2: Send MP-0 S62.0,K,207,9,charging,standard,69,57,9,0,0,0,3,1,0,0,0,0,0.00,0,0,0,0,-1,0,0,0,0,0,0,0,1.43,367.40,0I (7506) ovms-server-v2: Send MP-0 D24,0,5,0.1,0.09,29,0,0,0,5,23,1,0,0,14.46,0,12.6,0,0.1,0I (7506) ovms-server-v2: Send MP-0 L0,0,0,0,0,0,0,0,-1.4,0,0I (7506) ovms-server-v2: Send MP-0 W0,0,0,0,0,0,0,0,0I (7506) ovms-server-v2: Send MP-0 F3.1.008-85-g9365b341-dirty/factory/edge (build idf v3.1-dev-1583-g0fb2019f Aug 4 2018 12:26:37),,0,1,TGTC,VirusnetI (7506) ovms-server-v2: Send MP-0 PINot charging|SOC: 62.0%|Ideal range: 69Km|Est. range: 58Km|I (8486) simcom: State: Enter PoweredOn stateI (10496) housekeeping: System considered stable (RAM: 8b=113788-154004 32b=10236)I (27506) simcom: State: Enter MuxStart state Thanks again,Nikolay On Saturday, August 4, 2018, 1:59:03 AM GMT+2, Nikolay Shishkov <nshishkov(a)yahoo.com> wrote: Fixed some stuff and added some for the Think City. There is still more to be done but here is the status so far. https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/150 On Wednesday, August 1, 2018, 9:46:12 PM GMT+2, Michael Balzer <dexter(a)expeedo.de> wrote: Forgot: the streaming mode (feature #8 / config vehicle stream) is an option to raise the location update frequency when the car is on. It's now interpreted as the interval in seconds, so "1" will give you per second updates. Regards, Michael Am 01.08.2018 um 21:40 schrieb Michael Balzer: Nikolay, see config → server v2 → update intervals. Regarding speed, you do provide it: StandardMetrics.ms_v_pos_speed->SetValue(((unsigned char) d[5]) / 2); …that's line 65 of the thinkcity module. There is no fallback to GPS speed. Regards, Michael Am 01.08.2018 um 21:10 schrieb Nikolay Shishkov: That same module has not crashed in almost a week now. So maybe there was something that was not connected to Think City code and got fixed by some of the library fixes. I noticed that it takes almost half a minute for the gps location to update in the app. The same goes for the speed and other parameters. Is there a setting to make that more frequent? Also - I can see speed, but I am not providing it - is it coming from the GPS? Thanks again! On Wednesday, August 1, 2018, 1:11:49 AM GMT+2, Nikolay Shishkov <nshishkov(a)yahoo.com> wrote: Thanks Michael, I did not refresh the mail thread and saw you answer after I posted my solution. I see about the states and the timing now... I may need to adjust this accordingly. I thought it was in milliseconds... These are all temperatures that are changing quite slow. So every 1 second or 4 seconds is perfectly fine. Hopefully I will have access to a car tomorrow and can test this. Thanks again, Nikolay On Wednesday, August 1, 2018, 1:06:32 AM GMT+2, Nikolay Shishkov <nshishkov(a)yahoo.com> wrote: I think I found a solution. Have not tested it yet. static const OvmsVehicle::poll_pid_t obdii_polls[] = { // 0x753 03 22 49 65 - charger temp { 0x753, 0x75B,VEHICLE_POLL_TYPE_OBDIIEXTENDED, 0x4965, { 0, 999, 999 } }, // 0x753 03 22 49 66 - pcu heat sink temp { 0x753, 0x75B,VEHICLE_POLL_TYPE_OBDIIEXTENDED, 0x4966, { 0, 999, 999 } }, // 0x753 03 22 49 67 - motor temp { 0x753, 0x75B,VEHICLE_POLL_TYPE_OBDIIEXTENDED, 0x4967, { 0, 999, 999 } }, // 0x753 03 22 49 68 - sli batt temp and volts { 0x753, 0x75B,VEHICLE_POLL_TYPE_OBDIIEXTENDED, 0x4968, { 0, 200, 200 } }, { 0, 0, 0x00, 0x00, { 0, 0, 0 } } }; On Tuesday, July 31, 2018, 8:57:51 PM GMT+2, Nikolay Shishkov <nshishkov(a)yahoo.com> wrote: Quick question. How do I convert this: while (TXB0CONbits.TXREQ) {} // Loop until TX is done TXB0CON = 0; TXB0SIDL = 0b01100000; TXB0SIDH = 0b11101010; TXB0D0 = 0x03; TXB0D1 = 0x22; TXB0D2 = 0x49; TXB0D3 = 0x65; TXB0DLC = 0b00000100; // data length (4) TXB0CON = 0b00001000; // mark for transmission delay100b(); // Delay a little... (100ms, approx) while (TXB0CONbits.TXREQ) {} // Loop until TX is done TXB0CON = 0; TXB0SIDL = 0b01100000; TXB0SIDH = 0b11101010; TXB0D0 = 0x03; TXB0D1 = 0x22; TXB0D2 = 0x49; TXB0D3 = 0x66; TXB0DLC = 0b00000100; // data length (4) TXB0CON = 0b00001000; // mark for transmission delay100b(); // Delay a little... (100ms, approx) while (TXB0CONbits.TXREQ) {} // Loop until TX is done TXB0CON = 0; TXB0SIDL = 0b01100000; TXB0SIDH = 0b11101010; TXB0D0 = 0x03; TXB0D1 = 0x22; TXB0D2 = 0x49; TXB0D3 = 0x67; TXB0DLC = 0b00000100; // data length (4) TXB0CON = 0b00001000; // mark for transmission delay100b(); // Delay a little... (100ms, approx) while (TXB0CONbits.TXREQ) {} // Loop until TX is done TXB0CON = 0; TXB0SIDL = 0b01100000; TXB0SIDH = 0b11101010; TXB0D0 = 0x03; TXB0D1 = 0x22; TXB0D2 = 0x49; TXB0D3 = 0x68; TXB0DLC = 0b00000100; // data length (4) TXB0CON = 0b00001000; // mark for transmission delay100b(); // Delay a little... (100ms, approx) To the new polling framework? I took a look at the leaf code, but the configuration is a mystery to me. What are the input parameters? Maybe there is a document that I am missing? Thanks in advance, Nikolay On Saturday, July 28, 2018, 11:42:13 PM GMT+2, Nikolay Shishkov <nshishkov(a)yahoo.com> wrote: Thank you! Yes the carid is TC003. I was not running anything extraordinary - just followed the developer tutorial, but never flashed directly - always flashed from edge branch OTA. I will run the commands and provide output, but it will be with the newer firmware. I will need to see if updating will have same problems. On Friday, July 27, 2018, 3:07:09 AM GMT+2, Mark Webb-Johnson <mark(a)webb-johnson.net> wrote: Note that I store the .elf files alongside the .bin, for edge/eap/main builds. For example: http://api.openvehicles.com/firmware/ota/v3.1/edge/3.1.008-29-gaf41242.ovms… Regards, Mark. On 27 Jul 2018, at 5:51 AM, Michael Balzer <dexter(a)expeedo.de> wrote: Nikolay, you need to keep the .elf files for your builds to be able to analyze a backtrace. Do not use addr2line, it shows wrong line numbers. Use the script "a2l" I posted previously (I'll include it again below). Just feed it the .elf file and the backtrace. Example: a2ltmp/3.1.008-32-g2fa3ab8-elf/ovms3.elf 0x400dc8ec 0x4008f43d 0x4008e181 0x400818cc 0x40082163 0x40083c4d 0x400dc8e9 (I don't have the -28- version, so my output doesn't make sense) @Mark: spurious task WDT crashes and heap corruption crashes still occur, but it seems they have become less often with the internal RAM rework. How is performance and power usage affected when using StandardMetrics.xxxxx->SetValue in the IncomingFrameCan1 method? Most of the messages update value every 100ms, and except maybe speed, battery current and voltage, most of the parameters are not changing that often. And even for the speed, current and voltage, it is probably enough to update StandardMetrics in the 1 second ticker... does this make sense or is the difference non-existing. Extending Mark's answer: It's normally OK to directly set metrics from IncomingFrameCan1(), but be aware metrics listeners will be executed synchronously in the context that changes the metric. Standard metrics listeners are now for example the automatic notification generators in the vehicle base class. These may need quite some stack and time. If you spend too much time handling frames on a high volume bus, your vehicle task may lose frames. It's possible to raise the queue size (currently 20 frames) and the vehicle task stack size, but it's better to keep the CAN processing simple. TL;DR: if you need to handle many CAN frames, I recommend changing metrics that trigger notifications or other complex actions from the ticker. If you encounter crashes on some CAN frames that may be due to the vehicle task stack being too small (CONFIG_OVMS_VEHICLE_RXTASK_STACK=6144). Regards, Michael Script a2l: #!/bin/bash elf=~/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/ovms3.elf for adr in $* ; do if [[ "$adr" =~ "elf" ]] ; then elf="$adr" else cmd+=" -ex 'l *$adr'" fi done cmd+=" -ex 'q'" echo "Using elf file: $elf" evalxtensa-esp32-elf-gdb -batch $elf $cmd 2>/dev/null #| grep "^0x.* is in " Am 26.07.2018 um 09:59 schrieb Nikolay Shishkov: Quick update: I managed to do a not so quick update on one of the ovms v.3 boxes that sits in a Think and can confirm that the porting seems to work. I could see speed, parking time, ambient temperature. I had very strange problems doing the OTA update. The firmware start download and I can see the messages progressing, but it would halt in between 700kB and 1600kB and then stay there until I refresh the browser. And when I refresh the browser I am asked of my password which leads me to that there must have been a crash in the meantime. I was finally able to get the OTA update work by disconnecting the box from the car and powering it via USB. This is a single data point but it kind of points to a problem with the code that communicates with the car. I was not able to get a laptop connected to checkout the console, but managed to get the following log - not sure how to interpret it. Last boot was 87 second(s) ago Time at boot: 2018-07-25 18:07:43 GMT This is reset #3 since last power cycle Detected boot reason: Crash (12/12) Crash counters: 3 total, 0 early Last crash: Alloca exception on core 0 Registers: PC : 0x400dc8ec PS : 0x00060234 A0 : 0x8008f440 A1 : 0x3ffc45b0 A2 : 0x00000020 A3 : 0x00000001 A4 : 0x00000000 A5 : 0x3ffb44b8 A6 : 0x3ffb47e4 A7 : 0x3ffb458c A8 : 0x3ffb44d4 A9 : 0x3ffc4590 A10 : 0x00000000 A11 : 0x7fffffff A12 : 0x8008e65b A13 : 0x3ffcc450 A14 : 0x00000003 A15 : 0x00060023 SAR : 0x00000000 EXCCAUSE: 0x00000005 EXCVADDR: 0x00000000 LBEG : 0x00000000 LEND : 0x00000000 LCOUNT : 0x00000000 Backtrace: 0x400dc8ec 0x4008f43d 0x4008e181 0x400818cc 0x40082163 0x40083c4d 0x400dc8e9 Version:3.1.008-29-gaf41242/ota_1/edge (build idf v3.1-dev-987-g55d915e Jul 6 2018 00:14:59) Running partition: ota_1 Boot partition: ota_1 Firmware:3.1.008-29-gaf41242/ota_1/edge (build idf v3.1-dev-987-g55d915e Jul 6 2018 00:14:59) How is performance and power usage affected when using StandardMetrics.xxxxx->SetValue in the IncomingFrameCan1 method? Most of the messages update value every 100ms, and except maybe speed, battery current and voltage, most of the parameters are not changing that often. And even for the speed, current and voltage, it is probably enough to update StandardMetrics in the 1 second ticker... does this make sense or is the difference non-existing. Thanks for all the hand holding and help, Nikolay -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 _______________________________________________ OvmsDev mailing list OvmsDev(a)lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev _______________________________________________ OvmsDev mailing list OvmsDev(a)lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev _______________________________________________ OvmsDev mailing list OvmsDev(a)lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 _______________________________________________ OvmsDev mailing list OvmsDev(a)lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 _______________________________________________ OvmsDev mailing list OvmsDev(a)lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev

2 1

OVMS v3.1 crashes during boot continuously
by Henrik Scheel 05 Aug '18

05 Aug '18

Hi. I ordered my OVMS v3 module in march 2018, and excited when I received it months later. The module has been connected in my Kia Soul EV from around version 3.1.004, with OTA updates enabled, until July 12. It was connected to dexters-web.de V2 server. It usually reported data to the app, sometimes with long delays, at other times not at all. From July 8th to July 10th, I drove the car 1450 km from Copenhagen to Paris, then parked it. When I tried to unlock the car 5 days later, the 12 Volt battery was completely drained, and since then, the OVMS has neither connected, nor sent beacons for the WIFI AP after a factory reset. I have no idea what happened. To my knowledge the module was functioning normally when I parked the car. On dexters-web, I can see that the last update was received at 22:07 12.07.2018. I have now (today) installed the development tools and OVMS software, built, and captured the output from the continuing crashes, when booting on the current master: Henriks-MBP:OVMS.V3 henrik$ make simple_monitor --- forcing DTR inactive --- forcing RTS inactive --- Miniterm on /dev/tty.SLAB_USBtoUART 115200,8,N,1 --- --- Quit: Ctrl+] | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H --- make: *** [simple_monitor] Terminated: 15 Terminated: 15 Henriks-MBP:OVMS.V3 henrik$ make monitor MONITOR --- WARNING: Serial ports accessed as /dev/tty.* will hang gdb if launched. --- Using /dev/cu.SLAB_USBtoUART instead... --- idf_monitor on /dev/cu.SLAB_USBtoUART 115200 --- --- Quit: Ctrl+] | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H --- ets Jun 8 2016 00:22:57 rst:0x1 (POWERON_RESET),boot:0x3f (SPI_FAST_FLASH_BOOT) configsip: 0, SPIWP:0xee clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00 mode:DIO, clock div:2 load:0x3fff0018,len:4 load:0x3fff001c,len:4796 load:0x40078000,len:0 load:0x40078000,len:14896 entry 0x400785) spiram: SPI RAM mode: flash 40m sram 40m I (655) spiram: PSRAM initialized, cache is in low/high (2-core) mode.2mI (656) cpu_start: Pro cpu up. I (660) cpu_start: Starting app cpu,t is 0x40081574 0x40081574: start_cpu0_default at /Users/henrik/esp/esp-idf/components/esp32/cpu_start.c:322 I (0) cpu_start: App cpu up.I (1521) spiram: SPI SRAM memory test OK I (1521) heap_init: Initializing. RAM available for dynamic allocation: I (1521) heap_init: At 3FFAE6E0 len 00001920 (6 KiB): DRAM I (1528) heap_init: At 3FFBC5C0 len 00023A40 (142 KiB): DRAM I (1534) heap_init: At 3FFE0440 len 00003BC0 (14 KiB): D/IRAM I (1540) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM I (1548) heap_init: At 40098ED8 len 00007128 (28 KiB): IRAM I (1553) cpu_start: Pro cpu start user code I (1558) spiram: Adding pool of 4096K of external SPI memory to heap allocator I (127) ovms_main: Set default logging level for * to INFO I (128) command: Initialising COMMAND (1000) I (129) boot: Initialising BOOT (1100) I (132) boot: Power cycle reset detected I (137) events: Initialising EVENTS (1200) I (142) config: Initialising CONFIG (1400) I (147) time: Initialising TIME (1500) I (152) script: Initialising SCRIPTS (1600) I (156) script: Using DUKTAPE javascript engine I (161) metrics: Initialising METRICS (1810) I (166) metrics: Expandjavascript engine I (176) notify: Initialising NOTIFICATIONS (1820) I (178) notify: Registered notification type info I (182) notify: Registered notification type error I (188) notify: Registered notification type alert I (193) notify: Registered notie data I (198) location: Initialising LOCATIONS (1900) I (205) location: Expanding DUKTAPE javascript engine I (210) vehicle: Initialising VEHICLE Factory (2000) I (216) pcp: Initialising POWER (4000) I (220) max7317: Initialising MAX7317 EGPIO (4200) I (225) sdcard: Initialising SD CARD (4400) I (230) ota: Initialising OTA (4400) I (235) can: Initialising CAN (4500) I (240) simcom: Initialising SIMCOM (4600) I (244) test: Initialising TEST (5000) I (248) ovms-module: Initialising MODULE (5100) I (253) vfs: Initialising VFS (5200) I (257) oInitialising OVMS Server (6000) I (263) ovms-server-v2: Initialising OVMS V2 Server (6100) I (269) ovms-server-v3: Initialising OVMS V3 Server (6200) I (275) obd2ecu: Initialising OBD2ECU (7000) I (280) canopen: Initialising CANopen (7000) I (286) esp32wifi: Initialising ESP32WIFI (8000) I (290) ovms-mdns: Initialising MDNS (8100) I (296) webserver: Initialising WEBSERVER (8200) I (302) ssh: Initialising SSH (8300) I (305) re: Initialising RE Tools (8800) I (310) netmanager: Initialising NETMANAGER (8999) I (317) v-voltampera: Registering Vehicle: Volt/Ampera (9000) I (321) v-track: Registering Vehicle: TRACK (9000) I (327) v-teslaroadster: Registering Vehicle: Tesla Roadster (9000) I (333) v-teslamodels: Registering Vehicle: Tesla 00) I (340) v-twizy: Registering Vehicle: Renault Twizy (9000) v-obdii: Registering Vehicle: OBDII (9000) I (352) v-none: Registering Vehicle: NONE (9000) I (357) v-nissanleaf: Registering Vehicle: Nissan Leaf (9000) I (364) v-kiasoulev: Registering Vehicle: Kia Soul EV (9000) I (370) v-demo: Registering Vehicle: DEMO (90;32mI (375) version: Initialising Versioning (9900) I (383) cpu_start: Starting scheduler on PRO CPU. I (0) cpu_start: Starting scheduler on APP CPU. I (451) ovms_main: Executing on CPU core 0 I (451) ovms_main: Mounting CONFIG... Initialising OVMS CONFIG within STORE E (461) config: Error: Cannot open config store directory I (461) ovms_main: Configure logging... I (461) ovms_main: Registering default configs... I (471) ovms_main: Starting HOUSEKEEPING... I (471) housekeeping: Initialising HOUSEKEEPING Framework... I (481) housekeeping: Executing on CPU core 1 I (481) housekeeping: reset_reason: cpu0=1, cpu1=14 I (491) housekeeping: Initialising WATCHDOG... I (491) housekeeping: Starting PERIPHERALS... I (501) peripherals: Initialising OVMS Peripherals... I (511) peripherals: TCP/IP Adaptor I (511) peripherals: ESP32 system I (511) peripherals: SPI bus I (521) peripherals: MAX7317 I/O Expander I (521) peripherals: ESP32 CAN I (531) peripherals: ESP32 WIFI I (531) peripherals: ESP32 ADC I (541) peripherals: MCP2515 CAN 1/2 I (551) peripherals: MCP2515 CAN 2/2 I (561) peripherals: SD CARD I (561) peripherals: SIMCOM MODEM I (561) gpio: GPIO[13]| InputEn: 0| OutputEn: 1| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0 I (571) gpio: GPIO[4]| InputEn: 1| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0 I (581) uart: queue free spaces: 10 I (581) ext12v: Powering off external 12V devices I (591) housekeeping: Auto init ext12v (free: 216052 bytes) I (591) housekeeping: Auto init wifi (free: 216052 bytes) W (601) esp32wifi: AutoInit: factory reset detected, starting public AP net 'OVMS' with password 'OVMSinit' I (611) esp32wifi: Powering up WIFI driver I (611) wifi: wifi firmware version: c25fd80 I (621) wifi: config NVS flash: enabled I (621) wifi: config nano formating: disabled I (621) system_api: Base MAC address is not set, read default base MAC address from BLK0 of EFUSE E (631) system_api: Base MAC address from BLK0 of EFUSE CRC error, efuse_crc = 0xb2; calc_crc = 0x3d abort() was called at PC 0x400dc76b on core 1 0x400dc76b: __gnu_cxx::new_allocator<char>::deallocate(char*, unsigned int) at /Users/henrik/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/ext/new_allocator.h:110 (inlined by) std::allocator_traits<std::allocator<char> >::deallocate(std::allocator<char>&, char*, unsigned int) at /Users/henrik/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/alloc_traits.h:386 (inlined by) std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_destroy(unsigned int) at /Users/henrik/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.h:185 (inlined by) std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_dispose() at /Users/henrik/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.h:180 (inlined by) std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string() at /Users/henrik/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.h:544 (inlined by) OvmsSSH::Authenticate(unsigned char, WS_UserAuthData const*, void*) at /Users/henrik/dev/ovms/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/console_ssh/src/console_ssh.cpp:232 Backtrace: 0x40091e73:0x3ffbfee0 0x40091fcb:0x3ffbff00 0x400dc76b:0x3ffbff20 0x400dc7b5:0x3ffbff50 0x401a6c23:0x3ffbff80 0x401a6fa8:0x3ffbffa0 0x4019da97:0x3ffbffd0 0x4019d161:0x3ffbfff0 0x400ddc2b:0x3ffc0010 0x400dddd3:0x3ffc0040 0x400de1a9:0x3ffc0060 0x400df7c9:0x3ffc0090 0x400e65f0:0x3ffc0190 0x400e62d2:0x3ffc0200 0x400e5da5:0x3ffc0240 0x400e5ef9:0x3ffc0270 0x400e5fad:0x3ffc02c0 0x400e5fbd:0x3ffc02f0 0x40091e73: xTaskCreatePinnedToCore at /Users/henrik/esp/esp-idf/components/freertos/tasks.c:3564 0x40091fcb: vTaskDelete at /Users/henrik/esp/esp-idf/components/freertos/tasks.c:3564 0x400dc76b: __gnu_cxx::new_allocator<char>::deallocate(char*, unsigned int) at /Users/henrik/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/ext/new_allocator.h:110 (inlined by) std::allocator_traits<std::allocator<char> >::deallocate(std::allocator<char>&, char*, unsigned int) at /Users/henrik/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/alloc_traits.h:386 (inlined by) std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_destroy(unsigned int) at /Users/henrik/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.h:185 (inlined by) std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_dispose() at /Users/henrik/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.h:180 (inlined by) std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string() at /Users/henrik/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.h:544 (inlined by) OvmsSSH::Authenticate(unsigned char, WS_UserAuthData const*, void*) at /Users/henrik/dev/ovms/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/console_ssh/src/console_ssh.cpp:232 0x400dc7b5: __gnu_cxx::new_allocator<char>::deallocate(char*, unsigned int) at /Users/henrik/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/ext/new_allocator.h:110 (inlined by) std::allocator_traits<std::allocator<char> >::deallocate(std::allocator<char>&, char*, unsigned int) at /Users/henrik/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/alloc_traits.h:386 (inlined by) std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_destroy(unsigned int) at /Users/henrik/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.h:185 (inlined by) std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_dispose() at /Users/henrik/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.h:180 (inlined by) OvmsSSH::Authenticate(unsigned char, WS_UserAuthData const*, void*) at /Users/henrik/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.h:544 0x401a6c23: std::time_get<char, std::istreambuf_iterator<char, std::char_traits<char> > >::_M_extract_via_format(std::istreambuf_iterator<char, std::char_traits<char> >, std::istreambuf_iterator<char, std::char_traits<char> >, std::ios_base&, std::_Ios_Iostate&, tm*, char const*) const at /Volumes/build/idf/crosstool-NG/.build/xtensa-esp32-elf/build/build-cc-gcc-final/xtensa-esp32-elf/libstdc++-v3/include/bits/locale_classes.tcc:114 (discriminator 6) 0x401a6fa8: std::num_get<char, std::istreambuf_iterator<char, std::char_traits<char> > >::_M_extract_float(std::istreambuf_iterator<char, std::char_traits<char> >, std::istreambuf_iterator<char, std::char_traits<char> >, std::ios_base&, std::_Ios_Iostate&, std::string&) const at /Volumes/build/idf/crosstool-NG/.build/xtensa-esp32-elf/build/build-cc-gcc-final/xtensa-esp32-elf/libstdc++-v3/include/bits/locale_classes.tcc:114 (discriminator 6) 0x4019da97: std::ostreambuf_iterator<char, std::char_traits<char> > std::__cxx11::money_put<char, std::ostreambuf_iterator<char, std::char_traits<char> > >::_M_insert<true>(std::ostreambuf_iterator<char, std::char_traits<char> >, std::ios_base&, char, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) const at /Volumes/build/idf/crosstool-NG/.build/xtensa-esp32-elf/build/build-cc-gcc-final/xtensa-esp32-elf/libstdc++-v3/include/bits/locale_classes.h:675 0x4019d161: void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char const*>(char const*, char const*, std::forward_iterator_tag) at /Volumes/build/idf/crosstool-NG/.build/xtensa-esp32-elf/build/build-cc-gcc-final/xtensa-esp32-elf/libstdc++-v3/include/bits/locale_classes.h:675 0x400ddc2b: dbc::dbc() at /Users/henrik/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/char_traits.h:243 0x400dddd3: std::__cxx11::_List_base<dbcNode*, std::allocator<dbcNode*> >::_M_init() at /Users/henrik/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/char_traits.h:243 (inlined by) std::__cxx11::list<dbcNode*, std::allocator<dbcNode*> >::clear() at /Users/henrik/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/stl_list.h:1369 (inlined by) dbcNodeTable::EmptyContent() at /Users/henrik/dev/ovms/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/dbc/src/dbc.cpp:194 0x400de1a9: unsigned int const& std::min<unsigned int>(unsigned int const&, unsigned int const&) at /Users/henrik/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/char_traits.h:243 (inlined by) std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::compare(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) const at /Users/henrik/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.h:2315 (inlined by) bool std::operator< <char, std::char_traits<char>, std::allocator<char> >(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) at /Users/henrik/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.h:4987 (inlined by) std::less<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >::operator()(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) const at /Users/henrik/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/stl_function.h:387 (inlined by) 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, dbcValueTable*>, std::_Select1st<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, dbcValueTable*> >, 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, dbcValueTable*> > >::_M_lower_bound(std::_Rb_tree_node<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, dbcValueTable*> >*, std::_Rb_tree_node<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, dbcValueTable*> >*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) at /Users/henrik/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/stl_tree.h:1628 0x400df7c9: std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >::size() const at /Users/henrik/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/char_traits.h:243 (inlined by) dbcfile::LoadParseOneLine(int, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >) at /Users/henrik/dev/ovms/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/dbc/src/dbc.cpp:649 0x400e65f0: esp32wifi::StartAccessPointClientMode(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >) at /Users/henrik/dev/ovms/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/esp32wifi/src/esp32wifi.cpp:580 (discriminator 1) 0x400e62d2: esp32wifi::StartClientMode(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, unsigned char*) at /Users/henrik/dev/ovms/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/esp32wifi/src/esp32wifi.cpp:461 0x400e5da5: esp32wifi::EventWifiStaDisconnected(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, void*) at /Users/henrik/dev/ovms/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/esp32wifi/src/esp32wifi.cpp:761 0x400e5ef9: void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct_aux<char const*>(char const*, char const*, std::__false_type) at /Users/henrik/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.h:195 (inlined by) void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char const*>(char const*, char const*) at /Users/henrik/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.h:214 (inlined by) std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&) at /Users/henrik/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.h:457 (inlined by) esp32wifi::EventWifiScanDone(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, void*) at /Users/henrik/dev/ovms/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/esp32wifi/src/esp32wifi.cpp:882 0x400e5fad: esp32wifi::EventWifiScanDone(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, void*) at /Users/henrik/dev/ovms/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/esp32wifi/src/esp32wifi.cpp:891 (discriminator 1) 0x400e5fbd: esp32wifi::EventWifiScanDone(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, void*) at /Users/henrik/dev/ovms/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/esp32wifi/src/esp32wifi.cpp:892 (discriminator 1) Rebooting... ets Jun 8 2016 00:22:57 rst:0xc (SW_CPU_RESET),boot:0x3f (SPI_FAST_FLASH_BOOT) configsip: 0, SPIWP:0xee clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00 mode:DIO, clock div:2 load:0x3fff0018,len:4 load:0x3fff001c,len:4796 load:0x40078000,len:0 load:0x40078000,len:14896 entry 0x40078d74 I (655) spiram: SPI RAM mode: flash 40m sram 40m I (655) spiramialized, cache is in low/high (2-core) mode. I (657) cpu_start: Pro cpu up. I (660) cpu_start: Starting app cpu, entry point is 0x40081574 0x40081574: start_cpu0_default at /Users/henrik/esp/esp-idf/components/esp32/cpu_start.c:322 u_start: App cpu up. I (1521) spiram: SPI SRAM memory test OK I (1522) heap_init: Initializing. RAM available for dynamic allocation: I (1522) heap_init: At 3FFAE6E0 len 00001920 (6 KiB): DRAM I (1529) heap_init: At 3FFBC5C0 len 00023A40 (142 KiB): DRAM I (1534) heap_init: At 3FFE0440 len 00003BC0 (14 KiB): D/IRAM Is the OVMS module hardware broken? Or can I somehow fix the module (if so; how)? Is it possible that the OVMS malfunctioned, and the repeated re-booting caused extensive power drain, either directly from the OBD-II, or by somehow keeping some systems in the car “awake”, via CAN-bus activity? Best regards, Henrik -- Venlig hilsen, Henrik R. Scheel Kia Soul EV 2015

2 1

Vehicle Feature List wiki page
by Robert Sharpe (Electric Vehicle Consultant) 04 Aug '18

04 Aug '18

Hi, In order to help understand the current status of the Nissan Leaf support a Vehicle Feature List wiki page has been created. As I don't have access to an OVMS the Leaf entries are only what could be gleened from the code. Please feel free to contribute/correct as you see fit. Enjoy Regards, Robert Sharpe Electric Vehicle Consultant 07711 252971 Your Plugged-in Partner Evergreen Consulting is the trading name of Sharpe Consultants Ltd

4 4

Porting code from v2 to v3
by Nikolay Shishkov 04 Aug '18

04 Aug '18

Hi, I am working on the Think City EV code and have some questions.- what is the best way to signal that the charging connector is plugged? ms_v_charge_pilot?previously it was cardoorbits1. - what is the best way to compare OvmsMetricStrings? Or should I dublicate the state in an enum and use that? - what is the best way to compare the OvmsMetricFloat to a literal float? - what is the current way of doing net_req_notification Thanks in advance,Nikolay On Tuesday, July 17, 2018, 3:37:49 AM GMT+2, Mark Webb-Johnson <mark(a)webb-johnson.net> wrote: Jacob, > Is there a reason why OVMS bundles three different SSL libraries? I think wolfSSL is there (but WOLFCRYPT_ONLY) because wolfSSH needs it. The ESP-IDF offers mbedtls and openssl libraries, but we don’t currently use either. > Also why is there a custom HTTP implementation when mongoose already has one? Primarily because we wrote those before we included mongoose into the project. But also because the mongoose http_client code sucks. It reads the entire message body into RAM, before passing it on to the client; that just won’t work for something like a firmware image. To complicate the choice further, ESP now includes a esp_http_client in their latest 3.x IDF (which wasn’t there before). I did try to convert our TCP and HTTP client libraries to mongoose a while ago, but failed. Those libraries are blocking (with i/o done in the context of the thread calling them), but the mongoose library is event-based non-blocking (with i/o output in the context of the calling thread, and i/o input in the context of the mongoose thread). Mongoose didn’t use to be thread safe, and that caused us all sorts of issues (now solved, by the work Michael and others did to make it thread safe). > IMO the best way would be to rewrite ovms_net and > ovms_http to use mongoose and configure mongoose to compile with SSL > support (probably mbedtls as the other two don't work). I agree. In general, I prefer the mongoose approach, and we are trying to standardise on that (for good or bad). Probably the best would be to fix the http client in mongoose to work properly (or at least have an option to deliver the body block by block as they arrive), then convert our stuff that uses ovms tcp/http libraries, then drop the tcp and http libraries. Not trivial given the different models (blocking vs non-blocking events). Between openssl vs mbedtls, I don’t really care. I think we’re going to have to manage certificate loading ourselves anyway (as we need to load from a combination of statically defined (in flash using COMPONENT_EMBED_TXTFILES and asm(“_binary_* start/end) and dynamic (in /store/tls/trustedca/* or somewhere like that). Regards, Mark. > On 17 Jul 2018, at 1:02 AM, Jakob Löw <ovms(a)m4gnus.de> wrote: > > Hey, > > I've been playing around a bit with implementing SSL/TLS support. For > starters I wanted to implement an OvmsNetTlsConnection class which > could then be used for https requests. At first I tried using wolfSSL > but it turns out wolfSSL is compiled with WOLFCRYPT_ONLY. OpenSSL also > didn't work as SSL_CTX_load_verify_locations is missing in ESP-IDF's > OpenSSL. I didn't try mbedtls yet. Is there a reason why OVMS bundles > three different SSL libraries? Also why is there a custom HTTP > implementation when mongoose already has one? Speaking of mongoose, it > seems to have an abstraction layer which allows to use one of the three > SSL/TLS libraries. IMO the best way would be to rewrite ovms_net and > ovms_http to use mongoose and configure mongoose to compile with SSL > support (probably mbedtls as the other two don't work). > > - Jakob > > On Mon, 2018-07-16 at 12:47 +0800, Mark Webb-Johnson wrote: >> Drupal authentication is done, and working against mosquitto now on >> the live api.openvehicles.com site. Plain text MQTT only at the >> moment (I still need to get mosquitto and OVMS module firmware >> supporting SSL). >> >> To configure OVMS v3 to use Server V3 protocol: >> >> config set: >> vehicle id <vehicleid> >> server.v3 server api.openvehicles.com >> server.v3 port 1883 >> server.v3 user <openvehicles.com username> >> password server.v3 <openvehicles.com password> >> >> server v3 start >> >> Can also 'config set auto server.v3 yes’ to auto-start at boot >> >> If you have an MQTT client, you can connect to the same server to >> query the metrics, issue commands, etc. The default topic hierarchy >> is ovms/<username>/<vehicleid>. >> >> I think we are close now. Just need SSL support. And then Apps… >> >> Feedback appreciated. >> >> Regards, Mark. >> >>> On 10 Jul 2018, at 2:42 PM, Mark Webb-Johnson <mark(a)webb-johnson.ne >>> t> wrote: >>> >>> I’ve just pushed the support for notifications in OVMS Server v3. >>> >>> With that, the server v3 is functionally complete (at least on the >>> car side). We can: >>> >>> Connect/disconnect >>> Handle lists of apps connecting/disconnecting >>> Send metrics >>> Send events >>> Send notifications (including info, error, alert, and historical >>> data) >>> Receive commands, run them, and return the results >>> >>> I’m still struggling against drupal authentication at the server >>> side; once that is done we can open this up to wider testing. >>> >>> Overall, I’m pretty happy with it. We need SSL/TLS support, but at >>> least functionally now it works and is complete. >>> >>> Regards, Mark >>> >>>> On 6 Jul 2018, at 4:16 PM, Mark Webb-Johnson <mark(a)webb-johnson.n >>>> et> wrote: >>>> >>>>>>> I suppose the following topic names: >>>>>>> metrics: <prefix>/metric/# >>>>>>> events: <prefix>/event/# >>>>>>> notifications: <prefix>/notify/# >>>>>>> config: <prefix>/config/# >>>>>>> logs: <prefix>/log/<tag> >>>>>>> active: <prefix>/client/<clientid>/active >>>>>>> requests: <prefix>/client/<clientid>/request/# >>>>>>> commands: <prefix>/client/<clientid>/command/<command >>>>>>> id> >>>>>>> cmd responses: <prefix>/client/<clientid>/response/<command >>>>>>> id> >>>>>> >>>>>> All ok. I am fine with this, and looks clean. I will make the >>>>>> changes today, as I want to get this into some cars asap so >>>>>> we can get a feel for how it behaves. >>>> >>>> Ok. Now implemented, and tested: >>>> >>>> <prefix>/metric/# >>>> <prefix>/client/<clientid>/active >>>> <prefix>/client/<clientid>/command/<command id> >>>> <prefix>/client/<clientid>/response/<command id> >>>> >>>> I don’t think config, logs, and requests are critical or urgent. >>>> So, I will try to finish events tonight (as that is relatively >>>> simple). Notifications over the weekend (more tricky, especially >>>> for historical data). It can go in my car with tonight’s nightly >>>> ota, for real world testing. >>>> >>>> I’m still trying to get the authentication working for drupal vs >>>> mosquitto. Once that is done, I can open up >>>> api.openvehicles.com MQTT for public use. If I can’t get it done >>>> within the next couple of days, I’ll try another broker (lua >>>> scripting, anyone?). >>>> >>>> P.S. Commands over MQTT are pretty cool: >>>> >>>> <PastedGraphic-2.tiff> >>>> <PastedGraphic-3.tiff> >>>> >>>> Regards, Mark. >>>> _______________________________________________ >>>> OvmsDev mailing list >>>> OvmsDev(a)lists.openvehicles.com >>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev >>> >>> _______________________________________________ >>> OvmsDev mailing list >>> OvmsDev(a)lists.openvehicles.com >>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev >> >> _______________________________________________ >> OvmsDev mailing list >> OvmsDev(a)lists.openvehicles.com >> http://lists.openvehicles.com/mailman/listinfo/ovmsdev > _______________________________________________ > OvmsDev mailing list > OvmsDev(a)lists.openvehicles.com > http://lists.openvehicles.com/mailman/listinfo/ovmsdev _______________________________________________ OvmsDev mailing list OvmsDev(a)lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev

3 18

3.1.007 OTA
by Mark Webb-Johnson 30 Jul '18

30 Jul '18

On my devices I’m seeing a problem with doing OTA updates when running 3.1.007. I’m seeing: OVMS# ota flash http Current running partition is: factory Target partition is: ota_0 Download firmware from api.openvehicles.com/firmware/ota/v3.1/edge/ovms3.bin to ota_0 Expected file size is 2850336 Preparing flash partition... abort() was called at PC 0x401b8e84 on core 0 0x401b8e84: pm_on_beacon_rx at ??:? Backtrace: 0x40091e6b:0x3ffcc4a0 0x40091fc3:0x3ffcc4c0 0x401b8e84:0x3ffcc4e0 0x401b94ef:0x3ffcc520 0x401b9bd1:0x3ffcc550 0x40089e62:0x3ffcc5a0 0x40091e6b: invoke_abort at /Users/mark/esp/esp-idf/components/esp32/panic.c:669 0x40091fc3: abort at /Users/mark/esp/esp-idf/components/esp32/panic.c:669 0x401b8e84: pm_on_beacon_rx at ??:? 0x401b94ef: ppRxProtoProc at ??:? 0x401b9bd1: ppRxPkt at ??:? 0x40089e62: ppTask at ??:? (this is a firmware rebuild so addresses may vary from stock 3.1.007, but the functions are the same) The pm_on_beacon_rx function is in libpp (as are ppRxProtoProc, ppRxPkt, and ppTask. If I comment out the esp_ota_* functions, it does the download and works fine. But if esp_ota_begin is called, then the crash occurs within http.BodyRead. (although I think it is within the ppTask, not in our code). It I reduce the size parameter given to esp_ota_begin, I can get it to work just fine. Around 1.5MB is fine, but above that is starts to get flaky. Espressif say that during flash writes the cache must be disabled, so all access to SPIRAM halted. Sometimes, I get to see a message 'I (20642) wifi: bcn_timout,ap_probe_send_start’ which seems to confirm the wifi task is being starved for cpu time during the esp_ota_begin(). I guess that is triggering a bug within the wifi stack where it doesn’t handle it gracefully. I then tried hacking around the esp_ota_begin() function. The Espressif implementation simply calls esp_partition_erase_range() to erase the partition in one call. For us, that now means blanking 2.8MB of flash and takes about 15 seconds or so. I changed that to call esp_partition_erase_range() multiple times, in 256KB chunks, with a 10ms vTaskDelay between each chunk. Problem solved. OTA works again doing it that way. I’m not sure how to get this fix applied. The issue is in Espressif’s code, related to big partition sizes. I guess they haven’t seen it because with 1MB OTA partitions the delay is only 3 seconds or so and probably not long enough to trigger the issue. I’ll raise a bug report with them, but suspect it will be a while for them to address it. As a temporary workaround for us, I think I’ll bring esp_ota_begin() into our ovms_ota code and customise it there specifically for us. We can always switch back to the normal esp_ota_begin when/if Espressif come up with a permanent solution. I don’t really want to change that core Espressif code, without direction from Espressif as to how to change it (been there, done that, and wasted a lot of time doing it). For safety, I’ve rolled back edge to 3.1.006-15-g14b8eb6. That will stop new deployments of this, while we solve the problem. For existing deployments in the field, I can only think of two solutions: (a) switch ota to factory, reboot, and flash to fixed code, or (b) ota from sdcard, with wifi unused/off. I should have the fix later today. Regards, Mark.

4 8