December 2018 - OvmsDev - Open Vehicles

Poor wifi performance
by Stephen Casner 09 Jan '19

09 Jan '19

I find the wifi performance of OVMS v3 to be poor, and I'm wondering how it might be improved. I have a mix of thoughts here. For both my own unit and that of Timothy Rodgers, wifi reception in our garages was unusable. You can blame that on too much distance from the access point, but my iPhone and MacBook both access the wifi just fine from my garage. The wifi antenna in the OVMS is probably smaller and its location within the metal framework around the car's firewall may impede radio transmission. Perhaps it would be feasible to switch to an ESP32-WROVER-I with an external antenna to improve performance, but that would be a big deal. If there is a transmit power adjustment, perhaps that could be increased? When Timothy parks his car next to his house, which is about 50 feet closer than the garage, then the wifi reception was good enough for the update to 3.1.008 to succeed. But when he tries to connect with the browser, page updates often time out, so it is close to unusable. Perhaps we could improve usability by increasing the timeout in our javascript to allow more time for TCP to retransmit? For my own unit, I switched from AP+client to just client mode and at first it seemed that had improved the client performance. But still the next day I had no access from the iPhone app. When I connected to the console to find out why I saw that server v2 was repeatedly trying to connect and failing. I'm presuming that the cause was poor wifi connectivity since I was also not able to reach the web server on the client address, although I have not proven that. But since the client wifi was associated with the home AP and had an address, the OVMS network routing preferred the wifi and did not try to use the modem. For now I have resorted to turning off wifi. I suggest that the network routing algorithm be enhanced to back off to use the modem if some number of attempts to connect to the server over wifi have failed. The iPhone will do this for itself (there is a setting to enable this called Wi-Fi Assist). The behavior of repeated connection attempts and failures by server v2 seems to induce a more serious failure after a while, perhaps due to some resource starvation. At that point there is a failure message "mg_connect(api.openvehicles.com:6867) failed: cannot parse address" every time server v2 tries to connect. I expect that is a bug that could be fixed. Lastly, since we may encounter situations where network communication is not working, we should facilitate access to the console. When I was trying to help Timothy change a location radius setting remotely by phone and the web browser was timing out, I suggested that he find a micro-USB cable so he could connect to the console. But then I realized he would not have any application on his laptop that would allow him to connect to the console. Developers use "make monitor" in the software development cycle, but users won't have that tool. I have my own program on the MacBook that I use as an alternative when I don't want to induce a reset when I connect. But is there a simple program for Windows suitable for non-developer users that can connect to the OVMS console? -- Steve

4 46

What’s inside
by Mark Webb-Johnson 29 Dec '18

29 Dec '18

😱

3 4

Mitsubishi i-MiEV SOH
by Tamás Kovács 25 Dec '18

25 Dec '18

I want to add SOH value to MI vehicle. I found this pid list for car: http://can4eve.bitplan.com/index.php/Cantriplet on the last row show pid 762 has battery capacity, this redirect another page which is outlander phev forum: The actual charge in Ah could be specified as: Request address = 761 Response address = 762 Mode + PID = 2101 Relevant Data Items = 29, 30 Formula = Total / 10 Any idea how to get this value, i don't get 762 pid in can bus -- Üdvözlettel: Kovács Tamás

1 0

Javascript
by Mark Webb-Johnson 23 Dec '18

23 Dec '18

I’ve enabled the javascript support in the ovms_scripts module. You can now write script files using the javascript language, and they will be run by the duktape engine. Any script file ending with “.js” extension will be treated as javascript. I’ve also added OvmsCommand and OvmsPrint extension commands. Two examples: OVMS# vfs cat /store/scripts/helloworld.js OvmsPrint("Hello world!\n”); OVMS# . helloworld.js Hello world! OVMS# vfs cat /store/scripts/ota.js OvmsPrint(OvmsCommand("ota status")); OVMS# . ota.js Running partition: factory Boot partition: factory Firmware: 3.1.008-40-g9254170-dirty/factory/edge (build idf v3.1-dev-1583-g0fb2019f Jul 9 2018 08:49:48) Server Available: 3.1.008-37-g939416c (no update required) Sat Jul 7 16:00:45 UTC 2018 Automated build (markhk8) ... A useful example would be to have a script that runs on location.leave, and checks the v.e.gear metric for vehicle in Drive, before firing off the homelink to close the garage door. Like all good things, the opportunity for evil is forever prevalent (and truly scary): OVMS# vfs cat /store/scripts/bruteforce.js for (var pin = 1000; pin < 10000; pin++) { OvmsCommand("unlock " + pin); } OVMS# . bruteforce.js V (1421374) canlog: TX can1 id 102 len 8: 0b 03 00 00 e8 03 00 40 | .......@ V (1421374) canlog: TX can1 id 102 len 8: 0b 03 00 00 e9 03 00 40 | .......@ V (1421374) canlog: TX can1 id 102 len 8: 0b 03 00 00 ea 03 00 40 | .......@ V (1421384) canlog: TX can1 id 102 len 8: 0b 03 00 00 eb 03 00 40 | .......@ V (1421384) canlog: TX can1 id 102 len 8: 0b 03 00 00 ec 03 00 40 | .......@ V (1421384) canlog: TX can1 id 102 len 8: 0b 03 00 00 ed 03 00 40 | .......@ V (1421384) canlog: TX can1 id 102 len 8: 0b 03 00 00 ee 03 00 40 | .......@ V (1421384) canlog: TX can1 id 102 len 8: 0b 03 00 00 ef 03 00 40 | .......@ V (1421384) canlog: TX can1 id 102 len 8: 0b 03 00 00 f0 03 00 40 | .......@ V (1421394) canlog: TX can1 id 102 len 8: 0b 03 00 00 f1 03 00 40 | .......@ ... I’ll leave it up to an exercise to the reader to change that script to use DukOvmsMetricValue() to monitor the v.e.locked metric to record success. Note that this is very hacky and experimental at the moment. A better approach seems to be to have a javascript task running, initialised at boot with a user’s javascript program. That can have timers, and whatever else it needs, to do it’s stuff. Then, scripts executed are run in the context of that task. The current implementation is really just a proof of concept. The OvmsPrint is particularly kludgy (a better implementation would be to hook to the duktape I/O system). Duktape is also currently running in internal RAM, although changing it to use SPI RAM should not be hard. Regards, Mark. > Begin forwarded message: > > From: GitHub > > Branch: refs/heads/master > Home: https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3 > Commit: f1736f927df582c5ff374ef5d8c3a565e8f67295 > https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/f17… > Author: Mark Webb-Johnson <mark(a)webb-johnson.net> > Date: 2018-07-09 (Mon, 09 Jul 2018) > > Changed paths: > M vehicle/OVMS.V3/main/ovms_command.cpp > > Log Message: > ----------- > Javascript: Add a OvmsCommand function to execute an OVMS command > > > Commit: 69427f4ac0cf68dc462b05752936befe4be22256 > https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/694… > Author: Mark Webb-Johnson <mark(a)webb-johnson.net> > Date: 2018-07-09 (Mon, 09 Jul 2018) > > Changed paths: > M vehicle/OVMS.V3/main/ovms_script.cpp > > Log Message: > ----------- > Javascript: Add a OvmsPrint function to be able to print a string > JavaScript: Support .js script files (executed with javascript engine) > > > Compare: https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/compare/92… > **NOTE:** This service been marked for deprecation: https://developer.github.com/changes/2018-04-25-github-services-deprecation/ > > Functionality will be removed from GitHub.com on January 31st, 2019.

3 14

Notification subtypes vs. MQTT topics & subscriptions
by Michael Balzer 22 Dec '18

22 Dec '18

I pushed the support for notification transport to web clients yesterday: Notifications via WebSocket channel & Web UI dialog widgets https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/83 Includes addition of a fifth notification channel "stream" for subtype/app specific data. Notification subtypes are used as MQTT style topics: "notify/<type>/<subtype>" …with subtype dots '.' replaced by '/'. The web client subscribes to topics on a receiver object. Types "info", "error" and "alert" are always forwarded to the web client, "data" and "stream" only as subscribed. MQTT topic patterns are supported (as far as mongoose implements them, which is currently only "#"). Test & documentation: - components/ovms_webserver/dev/notifications.htm - components/ovms_webserver/dev/dialogtest.htm 1) Notification subtypes fit MQTT topics semantically, but have been introduced by us using a dotted syntax. Server v3 currently uses subtypes as submitted for the MQTT topics generated from them. For the webserver, I convert the dots to slashes (utils: mqtt_topic()). I suggest applying the same scheme to the v3 transport, so subscriptions can be simplified by applying standard MQTT wildcards (e.g. "notify/+/charge/#" would subscribe to all charge notifications). I haven't changed the v3 server, because it may break existing subscriptions. Are there any MQTT users working with notification subscriptions yet? And as subtypes really are topics now, maybe we should change the subtype scheme to reflect this? 2) The new "stream" channel is meant for "re" and similar applications, i.e. apps needing fast display update channels. It's currently not transported by the v2/v3 servers, but adding that to the v3 server is very simple once we've sorted out this: Generation of stream updates without any active clients would add unnecessary CPU, memory and network load. Streams could be switched on/off using some dedicated command, but a better way is to check for active subscriptions to the stream topic before producing the data. This currently needs polling the MyNotify.HasReaders() method. I would rather introduce events to signal topic subscriptions and unsubscribes. I can easily produce these from the webserver as sub/unsub is handled by the server itself, but we should introduce this with real MQTT subscriptions in mind. Problem with MQTT is (or seems to be?), there is no defined broker standard to get consumer topic sub/unsub updates. Do we need to define a custom topic scheme for this? Or is there a broker standard about to emerge? Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

1 0

GPS distance threshold for "stolen" warning
by Stephen Casner 19 Dec '18

19 Dec '18

Timothy Rodgers sent a note to me saying that as his car was parked today he received the warning notification from OVMS that his car was moving while the hand brake was applied and so should be checked to make sure it was not being trailered and stolen. I know this is a consequence of too much wander in the GPS position. Where is the threshold for that warning set? -- Steve

2 2

Hacking away at the Tesla Roadster ESS bus
by Mark Webb-Johnson 14 Dec '18

14 Dec '18

On the ESS bus, I am seeing voltages on IDs 08A, 092. 09A, 0A2, 0AA, 0B2, 0BA, 0C2, 0CA, 0D2, and 0DA, Temperatures are on IDs 08C, 094, 09C, 0A4, 0AC, 0B4, 0BC, 0C4, 0CC, 0D4 and 0DC. 11 sheets, so we can assume the IDs are offset from 08A (voltages) and 08C (temperatures), spaced 8 apart. Here is my decode for voltages: Voltages ID: 08A, 092. 09A, 0A2, 0AA, 0B2, 0BA, 0C2, 0CA, 0D2, 0DA (11 sheets, 11 IDs) B1 \ Minimum voltage (low 8 bits) B2 / Minimum voltage (high 8 bits), scaled 8192 B3 \ Maximum voltage (low 8 bits) B4 / Maximum voltage (high 8 bits), scale 8192 B5 \ Average voltage (low 8 bits) B6 | Average voltage (mid 8 bits) B7 / Average voltage (high 8 bits), scale 9*8192 (9 bricks per sheet) B8 Minimum brick# (low 4 bits), maximum brick# (high 4 bits) The B7 factor is my best guess, looking at data from just one car. With 9 bricks per sheet, it seems obvious this is 9*8192, and that seems to match the log data the best. For example, I have '08A 67 81 90 81 0f 8e 04 04'. This is: * 08A Sheet #1 (of 11). Presumably ((ID - 08A)/8)+1 is sheet number. * 67 81 33127/8192 = 4.0438v * 90 81 33168/8192 = 4.0488v * 0f 8e 04 298511/(9*8192) = 4.0488v * 04 Minimum brick #4, maximum brick #0 (both relative to sheet #1) So, another way of looking at the average voltage is sheet voltage (36.4393v in the above example). For temperatures, I have: Temperatures ID: 08C, 094, 09C, 0A4, 0AC, 0B4, 0BC, 0C4, 0CC, 0D4, 0DC (11 sheets, 11 IDs) B1 \ Minimum temperature (low 8 bits) B2 / Minimum temperature (high 8 bits), scaled 256 B3 \ Maximum temperature (low 8 bits) B4 / Maximum temperature (high 8 bits), scaled 256 B5 \ Average temperature (low 8 bits) B6 | Average temperature (mid 8 bits) B7 / Average temperature (high 8 bits), scaled 256*9*avgfactor B8 ? For example, I have '08C 6f 24 be 24 8c 92 02 10'. This is: * 08C Sheet #1 (of 11). Presumably ((ID - 08C)/8)+1 is sheet number. * 6f 24 9327/256 = 36.433C * be 24 9406/256 = 36.742C * 8c 92 02 168588/(256*9*2) = 36.585C * 10 This somehow encodes the avgfactor, and perhaps others, but doesn't seem to be obvious I am still working on temperatures B8, and how the avgfactor is determined. I am seeing values 10, 13, 20, 21, 23, 30, 31, and 32 there. It seems to be in general partitioned with bit masks, but not as simple as the high-4 low-4 of voltages. I think this somehow encodes the minimum and maximum bricks (or sensors), and maybe some sensor readings are invalid/discarded (which is why it affects the average and changes over time). If the Average temperature (and perhaps voltage) values are the sums of all the sensor values, then perhaps there are 9 voltage measurements for each sheet (9 bricks), but more temperature sensors? Each brick should have at least one temperature sensor. It doesn't really make sense how they can encode so much in just 8 bits. It does change in subsequent readings, even for one sheet. For example: 1535254858.000033 3R11 08C 6e 24 bb 24 85 92 02 10 1535254858.500541 3R11 08C 6e 24 bb 24 88 92 02 20 1535254858.999948 3R11 08C 6e 24 bc 24 8b 92 02 10 A work in progress for average temperatures, but the others (in particular voltages) seem very clear. Regards, Mark

1 0

Re: [Ovmsdev] OvmsDev Digest, Vol 83, Issue 3
by Olivier 07 Dec '18

07 Dec '18

Hello Mark, It's strange, I have re-clone again to be sure about IDF, $ git describe --tags --dirty v3.1-dev-2835-g151269458 And now both is working, SD read and load dbc I have add my dbc file, and if you want to test the is this git : https://github.com/commaai/opendbc regards, Olivier Le jeu. 6 déc. 2018 à 05:16, <ovmsdev-request(a)lists.openvehicles.com> a écrit : > Send OvmsDev mailing list submissions to > ovmsdev(a)lists.openvehicles.com > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.openvehicles.com/mailman/listinfo/ovmsdev > or, via email, send a message with subject or body 'help' to > ovmsdev-request(a)lists.openvehicles.com > > You can reach the person managing the list at > ovmsdev-owner(a)lists.openvehicles.com > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of OvmsDev digest..." > > > Today's Topics: > > 1. Re: Issue to store en SD Card after upgrade to idf 3.2-Dev > (Pull Request 2# from M4GNV5/master) (Mark Webb-Johnson) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 6 Dec 2018 08:59:57 +0800 > From: Mark Webb-Johnson <mark(a)webb-johnson.net> > To: OVMS Developers <ovmsdev(a)lists.openvehicles.com> > Subject: Re: [Ovmsdev] Issue to store en SD Card after upgrade to idf > 3.2-Dev (Pull Request 2# from M4GNV5/master) > Message-ID: <5B58BB15-BEB4-4B9E-AAFC-E98DFA176748(a)webb-johnson.net> > Content-Type: text/plain; charset="utf-8" > > And related to this, if anyone else has any DBC files, please send them to > me so that I can test them against our DBC support library (to test for > robustness and completeness). > > Regards, Mark > > > On 6 Dec 2018, at 7:54 AM, Mark Webb-Johnson <mark(a)webb-johnson.net> > wrote: > > > > Olivier, > > > > I think this is two different issues. > > > > SD card issue > > > > Are there any system-level errors shown in the logs when you try this? > Please try on local console to see what is shown there. > > > > Are you powered from USB or vehicle power? > > > > Can you show the output of ?config list sdcard? and ?sd status?? > > > > DBC load issue > > > > Can you send me the Vectrix.dbc file you are using, please. Most likely > something in the structure of this file is causing the crash. It seems that > one of the messages (BO_) cannot be parsed correctly. > > > > What version of IDF are you using now? Just master head, right? > > > > Regards, Mark. > > > >> On 6 Dec 2018, at 4:29 AM, Olivier <ogrums(a)gmail.com <mailto: > ogrums(a)gmail.com>> wrote: > >> > >> Hello, > >> > >> I have some issue with SD Card on OVMS 3.1 I don't know how to fix the > "bug" > >> > >> I can't write or read file on SD Card, but I can make directory : > >> > >> OVMS# vfs ls /sd > >> [DIR] 05-Nov-2018 20:46 logs/ > >> 13.5k 23-Nov-2018 19:45 Vectrix_bak.dbc > >> 14.0k 11-Nov-2018 22:04 Vectrix.dbc > >> 13 01-Jan-1980 00:00 FOO.TXT > >> 13.5k 23-Nov-2018 19:45 vx1.dbc > >> > >> OVMS# vfs mkdir /sd/testdir > >> VFS directory created > >> > >> OVMS# vfs ls /sd > >> [DIR] 05-Nov-2018 20:46 logs/ > >> 13.5k 23-Nov-2018 19:45 Vectrix_bak.dbc > >> 14.0k 11-Nov-2018 22:04 Vectrix.dbc > >> [DIR] 05-Dec-2018 21:14 testdir/ > >> 13 01-Jan-1980 00:00 FOO.TXT > >> 13.5k 23-Nov-2018 19:45 vx1.dbc > >> > >> OVMS# config backup /sd/cfg.zip > >> Creating config backup '/sd/cfg.zip'... > >> Error: zip failed: No such file or directory > >> > >> OVMS# vfs rmdir /sd/testdir > >> VFS directory removed > >> > >> And If I try do load dbc file it's crash > >> > >> OVMS# dbc load test /sd/vx1.dbc > >> > >> Guru Meditation Error: Core 1 panic'ed (StoreProhibited). Exception > was unhandled. > >> Core 1 register dump: > >> PC : 0x40271023 PS : 0x00060730 A0 : 0x800e38f1 A1 > : 0x3ffd4540 > >> 0x40271023: dbcMessage::SetID(unsigned int) at > ?????/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/dbc/src/dbc.cpp:935 > >> > >> A2 : 0x00000000 A3 : 0x80feda4d A4 : 0x3ffe5360 A5 > : 0x3ffe5363 > >> A6 : 0x00000000 A7 : 0x00000000 A8 : 0x00000020 A9 > : 0x3f4055b0 > >> A10 : 0x00000001 A11 : 0x3f4061ce A12 : 0x3f81ec50 A13 > : 0x00000000 > >> A14 : 0x3ffd4524 A15 : 0x00000000 SAR : 0x00000008 > EXCCAUSE: 0x0000001d > >> EXCVADDR: 0x0000001c LBEG : 0x4009bd69 LEND : 0x4009bd9d > LCOUNT : 0xffffffff > >> > >> 0x4009bd69: memcpy at > /home/jeroen/esp8266/esp32/newlib_xtensa-2.2.0-bin/newlib_xtensa-2.2.0/xtensa-esp32-elf/newlib/libc/machine/xtensa/../../../../.././newlib/libc/machine/xtensa/memcpy.S:291 > >> 0x4009bd9d: memcpy at > /home/jeroen/esp8266/esp32/newlib_xtensa-2.2.0-bin/newlib_xtensa-2.2.0/xtensa-esp32-elf/newlib/libc/machine/xtensa/../../../../.././newlib/libc/machine/xtensa/memcpy.S:324 > >> > >> Backtrace: 0x40271023:0x3ffd4540 0x400e38ee:0x3ffd4560 > 0x400dfeba:0x3ffd4ea0 0x400dea49:0x3ffd4ee0 0x400dec48:0x3ffd4f80 > 0x400f118a:0x3ffd4fa0 0x400f129b:0x3ffd4fd0 0x400f129b:0x3ffd5000 0x400f12 > >> d1:0x3ffd5030 0x400ecae8:0x3ffd5050 0x4010601d:0x3ffd5070 > 0x4010608e:0x3ffd50d0 0x400ecb1f:0x3ffd5110 0x40271193:0x3ffd5130 > 0x401010a9:0x3ffd5150 0x400fa5cd:0x3ffd5180 0x400fa7e1:0x3ffd51b0 0x401 > >> 00f35:0x3ffd51d0 0x40100f44:0x3ffd51f0 0x400f2489:0x3ffd5210 > >> > >> 0x40271023: dbcMessage::SetID(unsigned int) at > ?????/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/dbc/src/dbc.cpp:935 > >> 0x400e38ee: yyparse(void*) at > ?????/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/dbc/src/dbc_parser.y:306 > >> 0x400dfeba: dbcfile::LoadFile(char const*, __sFILE*) at > ?????/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/dbc/src/dbc.cpp:935 > >> 0x400dea49: dbc::LoadFile(char const*, char const*) at > ?????/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/dbc/src/dbc_app.cpp:198 > >> 0x400dec48: dbc_load(int, OvmsWriter*, OvmsCommand*, int, char const* > const*) at > ?????/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/dbc/src/dbc_app.cpp:62 > >> 0x400f118a: OvmsCommand::Execute(int, OvmsWriter*, int, char const* > const*) at > ?????/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/ovms_command.cpp:73 > >> 0x400f129b: OvmsCommand::Execute(int, OvmsWriter*, int, char const* > const*) at > ?????/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/ovms_command.cpp:73 > >> 0x400f129b: OvmsCommand::Execute(int, OvmsWriter*, int, char const* > const*) at > ?????/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/ovms_command.cpp:73 > >> 0x400f12d1: OvmsCommandApp::Execute(int, OvmsWriter*, int, char const* > const*) at > ?????/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/ovms_command.cpp:73 > >> > >> I Have try my SD Card on a PC is working, I have try example code > "sd_card_example_main.c" from SDK "esp-idf\examples\storage\sd_card\main", > It's working to, no crash. > >> My guest, is the hardware is OK, esp-idf is OK, but they is something > in OVMS main code make this bug. > >> > >> I have delete both esp-idf, and OVMS folder and clone again, compiled > again, but it's the same issue. > >> > >> Thank you for your help. > >> Olivier > >> _______________________________________________ > >> OvmsDev mailing list > >> OvmsDev(a)lists.openvehicles.com <mailto:OvmsDev@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 > >

2 1

Issue to store en SD Card after upgrade to idf 3.2-Dev (Pull Request 2# from M4GNV5/master)
by Olivier 06 Dec '18

06 Dec '18

Hello, I have some issue with SD Card on OVMS 3.1 I don't know how to fix the "bug" I can't write or read file on SD Card, but I can make directory : *OVMS# vfs ls /sd* *[DIR] 05-Nov-2018 20:46 logs/* * 13.5k 23-Nov-2018 19:45 Vectrix_bak.dbc* * 14.0k 11-Nov-2018 22:04 Vectrix.dbc* * 13 01-Jan-1980 00:00 FOO.TXT* * 13.5k 23-Nov-2018 19:45 vx1.dbc* *OVMS# vfs mkdir /sd/testdir* *VFS directory created* *OVMS# vfs ls /sd* *[DIR] 05-Nov-2018 20:46 logs/* * 13.5k 23-Nov-2018 19:45 Vectrix_bak.dbc* * 14.0k 11-Nov-2018 22:04 Vectrix.dbc* *[DIR] 05-Dec-2018 21:14 testdir/* * 13 01-Jan-1980 00:00 FOO.TXT* * 13.5k 23-Nov-2018 19:45 vx1.dbc* *OVMS# config backup /sd/cfg.zip* *Creating config backup '/sd/cfg.zip'...* *Error: zip failed: No such file or directory* *OVMS# vfs rmdir /sd/testdir* *VFS directory removed* And If I try do load dbc file it's crash *OVMS# dbc load test /sd/vx1.dbc* *Guru Meditation Error: Core 1 panic'ed (StoreProhibited). Exception was unhandled.* *Core 1 register dump:* *PC : 0x40271023 PS : 0x00060730 A0 : 0x800e38f1 A1 : 0x3ffd4540* *0x40271023: dbcMessage::SetID(unsigned int) at ?????/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/dbc/src/dbc.cpp:935* *A2 : 0x00000000 A3 : 0x80feda4d A4 : 0x3ffe5360 A5 : 0x3ffe5363* *A6 : 0x00000000 A7 : 0x00000000 A8 : 0x00000020 A9 : 0x3f4055b0* *A10 : 0x00000001 A11 : 0x3f4061ce A12 : 0x3f81ec50 A13 : 0x00000000* *A14 : 0x3ffd4524 A15 : 0x00000000 SAR : 0x00000008 EXCCAUSE: 0x0000001d* *EXCVADDR: 0x0000001c LBEG : 0x4009bd69 LEND : 0x4009bd9d LCOUNT : 0xffffffff* *0x4009bd69: memcpy at /home/jeroen/esp8266/esp32/newlib_xtensa-2.2.0-bin/newlib_xtensa-2.2.0/xtensa-esp32-elf/newlib/libc/machine/xtensa/../../../../.././newlib/libc/machine/xtensa/memcpy.S:291* *0x4009bd9d: memcpy at /home/jeroen/esp8266/esp32/newlib_xtensa-2.2.0-bin/newlib_xtensa-2.2.0/xtensa-esp32-elf/newlib/libc/machine/xtensa/../../../../.././newlib/libc/machine/xtensa/memcpy.S:324* *Backtrace: 0x40271023:0x3ffd4540 0x400e38ee:0x3ffd4560 0x400dfeba:0x3ffd4ea0 0x400dea49:0x3ffd4ee0 0x400dec48:0x3ffd4f80 0x400f118a:0x3ffd4fa0 0x400f129b:0x3ffd4fd0 0x400f129b:0x3ffd5000 0x400f12* *d1:0x3ffd5030 0x400ecae8:0x3ffd5050 0x4010601d:0x3ffd5070 0x4010608e:0x3ffd50d0 0x400ecb1f:0x3ffd5110 0x40271193:0x3ffd5130 0x401010a9:0x3ffd5150 0x400fa5cd:0x3ffd5180 0x400fa7e1:0x3ffd51b0 0x401* *00f35:0x3ffd51d0 0x40100f44:0x3ffd51f0 0x400f2489:0x3ffd5210* *0x40271023: dbcMessage::SetID(unsigned int) at ?????/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/dbc/src/dbc.cpp:935* *0x400e38ee: yyparse(void*) at ?????/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/dbc/src/dbc_parser.y:306* *0x400dfeba: dbcfile::LoadFile(char const*, __sFILE*) at ?????/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/dbc/src/dbc.cpp:935* *0x400dea49: dbc::LoadFile(char const*, char const*) at ?????/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/dbc/src/dbc_app.cpp:198* *0x400dec48: dbc_load(int, OvmsWriter*, OvmsCommand*, int, char const* const*) at ?????/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/dbc/src/dbc_app.cpp:62* *0x400f118a: OvmsCommand::Execute(int, OvmsWriter*, int, char const* const*) at ?????/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/ovms_command.cpp:73* *0x400f129b: OvmsCommand::Execute(int, OvmsWriter*, int, char const* const*) at ?????/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/ovms_command.cpp:73* *0x400f129b: OvmsCommand::Execute(int, OvmsWriter*, int, char const* const*) at ?????/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/ovms_command.cpp:73* *0x400f12d1: OvmsCommandApp::Execute(int, OvmsWriter*, int, char const* const*) at ?????/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/ovms_command.cpp:73* I Have try my SD Card on a PC is working, I have try example code "sd_card_example_main.c" from SDK "esp-idf\examples\storage\sd_card\main", It's working to, no crash. My guest, is the hardware is OK, esp-idf is OK, but they is something in OVMS main code make this bug. I have delete both esp-idf, and OVMS folder and clone again, compiled again, but it's the same issue. Thank you for your help. Olivier

2 2

Re: [Ovmsdev] yacc/lex on component/dbc
by Mark Webb-Johnson 05 Dec '18

05 Dec '18

Craig, I had a look at this, and it doesn’t seem at all easy to resolve. The espressif build system uses component.mk to control the build. In our dbc component, the .hpp and .cpp files in yacclex are dynamically built. Then there is a COMPONENT_SRCDIRS variable that controls which directories the build system will look into for files to compile. I think that what is happening, with concurrent build jobs, is that the component library object is being built at the same time as the yacclex dynamic builds. When the component library build starts, it generates a list of files (.c, .cpp, etc) to compile - but if that is done before the yacclex files are dynamically built, the issue you describe happens. I can see a way to split this into two components (perhaps in the same dbc directory) - the first containing the dynamic content, and the second containing the main dbc component. Then we can set a component dependency for the main component depending on the dynamic content component. But, I can’t see any obvious way of setting an explicit dependency for this dynamic content. Any ‘make’ gurus out there? As an alternative, very hacky, solution, I added this to component.mk: .NOTPARALLEL: :-) Regards, Mark. > On 1 Dec 2018, at 10:28 AM, Craig Leres <leres(a)xse.com> wrote: > > I tried building on FreeBSD and parallel make is broken: > > % make -j8 > [...] > gmake[1]: *** No rule to make target 'yacclex/dbc_parser.o', needed by 'libdbc.a'. Stop. > gmake[1]: *** Waiting for unfinished jobs.... > YACC dbc_parser.y > > If I start a non-parallel build after the above failure it works ok (and probably first builds the things that are missing make dependencies). See appended. > > I flashed it and it runs but this is with my dev module that does not have a modem and is literally on the bench. > > I'm not very experienced with gmake but am willing to try and help if you can't figure out how fix the missing dependency (which might well be in the esp-idf tree). > > Craig > > ice 96 % gmake > LEX dbc_tokeniser.l > CXX /home/ice/u0/leres/src/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/dbc/src/dbc.o > CXX /home/ice/u0/leres/src/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/dbc/yacclex/dbc_tokeniser.o > CXX /home/ice/u0/leres/src/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/dbc/yacclex/dbc_parser.o > AR /home/ice/u0/leres/src/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/dbc/libdbc.a > CC /home/ice/u0/leres/src/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/esp_http_client/esp_http_client.o > CC /home/ice/u0/leres/src/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/esp_http_client/lib/http_utils.o > CC /home/ice/u0/leres/src/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/esp_http_client/lib/http_auth.o > CC /home/ice/u0/leres/src/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/esp_http_client/lib/transport_tcp.o > CC /home/ice/u0/leres/src/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/esp_http_client/lib/transport.o > CC /home/ice/u0/leres/src/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/esp_http_client/lib/transport_ssl.o > CC /home/ice/u0/leres/src/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/esp_http_client/lib/http_header.o > AR /home/ice/u0/leres/src/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/esp_http_client/libesp_http_client.a > CC /home/ice/u0/leres/src/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/ethernet/emac_main.o > CC /home/ice/u0/leres/src/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/ethernet/emac_dev.o > CC /home/ice/u0/leres/src/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/ethernet/eth_phy/phy_tlk110.o > [...]

1 0