- OvmsDev - Open Vehicles

github usability work
by Robert Sharpe (Electric Vehicle Consultant) 06 Jan '19

06 Jan '19

Hi Mark, I wanted to tidy up new issues created related to the usability work I am doing. But cant seem to create or apply labels. Could you apply the labels "enhanced" and "help wanted" to the following https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/181 #181 opened 7 days ago by https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues?q=i… https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/180 #180 opened 7 days ago by https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues?q=i… Also it would be good to categorise issues associated with this work. How do you suggest we do that eg using a "Label" or "Project" Rob

2 3

Android app vs. iOS app
by Geir Øyvind Vælidalo 06 Jan '19

06 Jan '19

Hi guys, I’ve done some assumptions when it comes to how the apps works and I need to know if the Android app disconnects when it is put in the background or if it keeps up the connection to the OVMS unit in the car. The iOS app disconnects for certain when it is put in the background, and I’ve taken for granted that the Android app also do that. Best regards, Geir

2 2

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

29 Dec '18

😱

3 4

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

24 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 18 Dec '18

18 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 13 Dec '18

13 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 06 Dec '18

06 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 05 Dec '18

05 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