- OvmsDev - Open Vehicles

Crash (Illegal Instruction)
by Greg D. 25 Feb '18

25 Feb '18

Hi folks, This is different... I've been playing with the web server, and after closing my browser window, turned the wifi back to client mode. Crash and reboot. Log level was set to Info at the time (see next email for more on that...), and thought it was a stack issue, but rather it appears to have hit an illegal instruction. So, perhaps a stack corruption? I don't recall if the modem was on or not. Only happened the one time, but posting here in case someone else sees it. Greg OVMS > wifi mode client gregnet Starting WIFI as a client to gregnet... I (3940180) ovms-mdns: Stopping MDNS service I (3940190) ovms-server-v2: Network is reconfigured, so disconnect network connection E (3940190) ovms-server-v2: Status: Error: Disconnected from OVMS Server V2 I (3940190) wifi: flush txq I (3940190) wifi: stop sw txq I (3940190) wifi: lmac stop hw txq I (3940190) wifi: Deinit lldesc rx mblock:4 I (3940190) wifi: wifi firmware version: ebd3e5d I (3940190) wifi: config NVS flash: enabled I (3940190) wifi: config nano formating: disabled I (3940210) wifi: Init dynamic tx buffer num: 16 I (3940210) wifi: Init data frame dynamic rx buffer num: 16 I (3940210) wifi: Init management frame dynamic rx buffer num: 16 I (3940210) wifi: wifi driver task: 3ffee104, prio:23, stack:4096 I (3940210) wifi: Init static rx buffer num: 4 I (3940210) wifi: Init dynamic rx buffer num: 16 I (3940210) wifi: wifi power manager task: 0x3ffe6328 prio: 21 stack: 2560 I (3940220) wifi: mode : sta (30:ae:a4:37:1b:64) I (3940220) esp32wifi: AP stopped I (3940440) webserver: Stopping Web Server I (3940440) webserver: Stopping Web Server I (3940440) telnet: Stopping Telnet Server I (3940440) ssh: Stopping SSH Server W (3940450) ovms-server-v2: Connection failedGuru Meditation Error: Core 1 panic'ed (IllegalInstruction) . Exception was unhandled. Core 1 register dump: PC : 0x7ec000e6 PS : 0x00060330 A0 : 0x800e555b A1 : 0x3ffec880 A2 : 0x3ffb3ce4 A3 : 0x00000000 A4 : 0x00000000 A5 : 0x3ffc7724 A6 : 0x3ffc7724 A7 : 0x3ffec830 A8 : 0x800f45e5 A9 : 0x3ffec860 A10 : 0x3ffdfc84 A11 : 0x00000000 A12 : 0x00000002 A13 : 0x00000000 A14 : 0x00000001 A15 : 0x706f7473 SAR : 0x00000004 EXCCAUSE: 0x00000000 EXCVADDR: 0x00000000 LBEG : 0x4000c46c LEND : 0x4000c477 LCOUNT : 0x00000000 Backtrace: 0x7ec000e6:0x3ffec880 0x400e5558:0x3ffec8a0 0x400e5569:0x3ffec8f0 0x400e5558: OvmsNetManager::MongooseTask() at /home/greg/greg/ovms/Open-Vehicle-Monitoring-System-3-master/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_netmanager.cpp:68 0x400e5569: MongooseRawTask(void*) at /home/greg/greg/ovms/Open-Vehicle-Monitoring-System-3-master/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_netmanager.cpp:68 Rebooting...

1 0

mDNS crash
by Stephen Casner 23 Feb '18

23 Feb '18

I updated esp-idf and OVMS to get the new MDNS API. I started OVMS and my startup script brought up wifi, then all I did was type a '?' command to get a command list. Shortly thereafter the system crashed with a context as shown below (edited). This looks like an action the mDNS server took in response to receiving a packet that may have come from one of my Mac computers or from the DEVKIT-C. That is, it's not a crash resulting from a call to the kernel from ovms_mdns. Unwisely I did not dig further into this crash and it has not repeated so far. So I guess I'm just recording this for posterity at this point. -- Steve OVMS > Guru Meditation Error: Core 0 panic'ed (LoadProhibited) . Exception was unhandled. Core 0 register dump: PC : 0x401e690f PS : 0x00060f30 A0 : 0x801e8c6c A1 : 0x3fff2e30 A2 : 0x3ffb9260 A3 : 0x3fff2e60 A4 : 0xbaad5678 A5 : 0x00000001 A6 : 0x00060f23 A7 : 0x00000000 A8 : 0x00060023 A9 : 0x3ffe623c A10 : 0x00000000 A11 : 0x00000000 A12 : 0x8008b35b A13 : 0x3ffaf8c0 A14 : 0x00000003 A15 : 0x00060023 SAR : 0x00000019 EXCCAUSE: 0x0000001c EXCVADDR: 0xbaad5680 LBEG : 0x4000c2e0 LEND : 0x4000c2f6 LCOUNT : 0xffffffff Entering gdb stub now. Remote debugging using /dev/cu.SLAB_USBtoUART38 _mdns_append_question (packet=0x3ffb9260 <packet> "", index=0x3fff2e60, q=0xbaad5678) at /Users/casner/src/github/my-esp-idf/components/mdns/./mdns.c:988 988 if (q->host) { (gdb) bt #0 _mdns_append_question (packet=0x3ffb9260 <packet> "", index=0x3fff2e60, q=0xbaad5678) at /Users/casner/src/github/my-esp-idf/components/mdns/./mdns.c:988 #1 0x401e8c6c in _mdns_dispatch_tx_packet (p=0x3ffe6524) at /Users/casner/src/github/my-esp-idf/components/mdns/./mdns.c:1156 #2 0x401e91ac in _mdns_tx_handle_packet (p=0x3ffe6524) at /Users/casner/src/github/my-esp-idf/components/mdns/./mdns.c:3627 #3 0x401ea3f1 in _mdns_execute_action (action=0x3ffe6a90) at /Users/casner/src/github/my-esp-idf/components/mdns/./mdns.c:3889 #4 0x401ea45a in _mdns_service_task (pvParameters=<optimized out>) at /Users/casner/src/github/my-esp-idf/components/mdns/./mdns.c:3994 (gdb)

1 0

Moving stuff to SPI RAM
by Mark Webb-Johnson 19 Feb '18

19 Feb '18

I’ve committed (and pushed) an experimental extension to allow C++ objects to be optionally moved to SPI RAM. The code is in ovms.h, so should be easily accessible to everything. It is pretty simple: We have a new class ‘ExternalRamAllocated’. That does nothing except override the new and new[] operators. Those operators try to malloc from SPI RAM first. If that doesn’t succeed then they fall back to standard internal RAM. The definition of a C++ class can then be changed to make it “: public ExternalRamAllocated”. Once that is done, any objects of that class allocated will try to be placed in external (SPI) RAM. For other malloc uses, a general purpose 'void* ExternalRamMalloc(std::size_t sz)’ function is also provided. To test this, I’ve made a one line change to the OvmsCommand class: -class OvmsCommand +class OvmsCommand : public ExternalRamAllocated Here is what the memory usage looks like: With SPI RAM disabled (in menuconfig): Free 8-bit 120844/284304, 32-bit 30508/57680, SPIRAM 0/0 --Task-- Total DRAM D/IRAM IRAM SPIRAM +/- DRAM D/IRAM IRAM SPIRAM no task 5312 0 0 0 +5312 +0 +0 +0 esp_timer 52328 0 644 0 +52328 +0 +644 +0 main 16448 0 0 0 +16448 +0 +0 +0 ipc0 11096 0 0 0 +11096 +0 +0 +0 Housekeeping 40576 5120 0 0 +40576 +5120 +0 +0 tiT 128 0 0 0 +128 +0 +0 +0 Tmr Svc 884 6444 0 0 +884 +6444 +0 +0 ipc1 12 0 0 0 +12 +0 +0 +0 AsyncConsole 20 0 26404 0 +20 +0 +26404 +0 Without deriving OvmsCommand from ExternalRamAllocated: Free 8-bit 119240/282436, 32-bit 424/27596, SPIRAM 4193924/4194252 --Task-- Total DRAM D/IRAM IRAM SPIRAM +/- DRAM D/IRAM IRAM SPIRAM tiT 0 0 0 128 +0 +0 +0 +128 Housekeeping 40564 5120 0 12 +40564 +5120 +0 +12 no task 5348 0 0 0 +5348 +0 +0 +0 esp_timer 52328 0 644 0 +52328 +0 +644 +0 main 16448 0 0 0 +16448 +0 +0 +0 ipc0 11096 0 0 0 +11096 +0 +0 +0 ipc1 12 0 0 0 +12 +0 +0 +0 Tmr Svc 884 6444 0 0 +884 +6444 +0 +0 AsyncConsole 20 0 26404 0 +20 +0 +26404 +0 After deriving OvmsCommand from ExternalRamAllocated: OVMS > module memory Free 8-bit 152308/282432, 32-bit 424/27596, SPIRAM 4160852/4194252 --Task-- Total DRAM D/IRAM IRAM SPIRAM +/- DRAM D/IRAM IRAM SPIRAM esp_timer 31664 0 644 20664 +31664 +0 +644 +20664 tiT 0 0 0 128 +0 +0 +0 +128 Housekeeping 39636 0 0 6060 +39636 +0 +0 +6060 no task 5348 0 0 0 +5348 +0 +0 +0 main 16448 0 0 0 +16448 +0 +0 +0 ipc0 11096 0 0 0 +11096 +0 +0 +0 ipc1 12 0 0 0 +12 +0 +0 +0 Tmr Svc 7328 0 0 0 +7328 +0 +0 +0 AsyncConsole 20 0 26404 0 +20 +0 +26404 +0 The advantage of SPI RAM is obvious. 30KB of internal RAM saved with just one line changed in a header file. Most of our other objects like that (metrics, configs, etc) could be equally easily moved to SPI RAM. We can make the decision on a class-by-class basis. I think this is a pretty good solution. It puts the onus of the decision of whether to put into SPI RAM into the object itself (as presumably the object knows best whether it can actually be put in SPI RAM). It is also extremely simple to define that. But, it is an experiment. Please let me know what you think. Regards, Mark.

3 7

Re: [Ovmsdev] Flash reset?
by Mark Webb-Johnson 19 Feb '18

19 Feb '18

Copying ovms developers in, and some useful information here… To get a copy of the FAT filesystem: $ cat partitions.csv # OVMS 16MB flash ESP32 Partition Table # Name, Type, SubType, Offset, Size nvs, data, nvs, 0x9000, 0x4000 otadata, data, ota, 0xd000, 0x2000 phy_init, data, phy, 0xf000, 0x1000 factory, app, factory, 0x10000, 4M ota_0, app, ota_0, , 4M ota_1, app, ota_1, , 4M store, data, fat, , 1M $ bc 65536+(3*4*1024*1024) ==> 12648448 1024*1024 ==> 1048576 $ ~/esp/esp-idf/components/esptool_py/esptool/esptool.py --port /dev/tty.SLAB_USBtoUART --baud 921600 read_flash 12648448 1048576 fatty esptool.py v2.2.1 … 1048576 (100 %) Read 1048576 bytes at 0xc10000 in 12.9 seconds (649.4 kbit/s)… $ file fatty fatty: DOS/MBR boot sector, code offset 0xfe+2, OEM-ID "MSDOS5.0", Bytes/sector 4096, FAT 1, root entries 512, sectors 250 (volumes <=32 MB) , Media descriptor 0xf8, sectors/FAT 1, sectors/track 63, heads 255, serial number 0x210000, unlabeled, FAT (1Y bit by descriptor) $ mkdir f $ losetup /dev/loop0 fatty $ mount -t vfat /dev/loop0 f $ ls -l f drwxr-xr-x 0 root root 4096 Jan 1 1980 ovms_config $ umount f $ losetup -d /dev/loop0 The above _should_ work, but I haven’t done much testing on it. To wipe the entire flash, and re-flash with latest: make erase_flash make flash You could probably just erase that one flash partition, but the above is quick and simple. Regards, Mark.

1 0

Multiple OVMS devices
by Stephen Casner 19 Feb '18

19 Feb '18

Perhaps none of you (other than Mark) have multiple OVMS v3 devices to connect to your computer. I have an OVMS v3.0 plus a smaller DEVKIT-C module that Mark sent to me to begin the infrastructure work before the developer boards were available. I want to run some other code on the DEVKIT-C module, so I plugged it into my Mac laptop via the same powered hub that I bought to support the OVMS v3.0 board. I discovered that the driver for the Silicon Labs CP2102 USB-to-UART bridge controller assigns a device name like /dev/tty.SLAB_USBtoUART19 to the second device that is connected. The number 19 represents how many times one of these devices has been connected, so if I unplug the second device and plug it back in again its device name will change to /dev/tty.SLAB_USBtoUART20. Since that device name is configured into sdkconfig that means a reconfig and full rebuild each time I need to unplug! Bah. So I went searching on the Silicon Labs forum and found that a support request to do something more sane was filed three years ago and has yet to be addressed. But one post included a workaround which is to use a python script to scan the system information about the USB hierarchy to find the location ID corresponding to each of these device names. The location ID of the port where the device is plugged in remains constant. Depending upon how the devices are being used, that can allow using a script to learn the device name currently assigned to each of the physical devices (assuming that a given physical device is always plugged into the same port). I took this idea and modified components/esptool_py/Makefile.projbuild to invoke an added program tools/findcp2102.py to look up the serial port as a location ID and translate it to the current device name. For example, in the sdkconfig file in my work tree for the DEVKIT-C I have changed CONFIG_ESPTOOLPY_PORT="20-2.1" which (currently) gets translated to /dev/tty.SLAB_USBtoUART20 when I run make (or make flash or make monitor). If the tools/findcp2102.py program is run with no argument it will list the location ID and device name for all the connected CP2102 devices. I can know which device name belongs to each physical device according to the order in which I plugged them in, so that gives me the associated location ID. It is also possible to see these location IDs in the Mac's System Report, but the numbering scheme is different. I've committed this change to the openvehicles/esp-idf repository. The change is implemented such that is has no effect if the serial port spec is not found as a USB location ID, so it should cause no harm. -- Steve

2 1

Prolonging traction battery life feature
by Robert Sharpe 18 Feb '18

18 Feb '18

Hi All, I have an idea that will help prolong the life of EV batteries and maximise vehicle resale value. In summary it involves implementing intelligent charging that keeps the battery at 50% (the best soc for long term storage) for as long a possible and minimises depth of charge and discharge. For example as soon as you get to a charge point (eg home or work), the OVMS will detect if it is below 50% and charge it until 50% is achieved the OVMS will be told the minimum required soc and when this should be achieved it will then wait until the last moment to start charging to achieving the required min soc a later version could receive a notification from your Google calendar with required mileage via IFTT, etc Unfortunately, I don't have the coding skills to implement it but would be happy to do all the non-coding stuff like requirements, design, documentation, testing, etc. If this sounds interesting and you would like to find out more please feel free to get back to me for a chat. Regards, Robert Sharpe (Managing Director) 07711 252971 Skype: arsharpe Your Plugged-in Partner Evergreen Consulting is the trading name of Sharpe Consultants Ltd

3 4

3.1
by Mark Webb-Johnson 15 Feb '18

15 Feb '18

Getting there. Just finished hand-soldering this 3.1 board. Removed the WROVER module, 1.8v voltage regulator, external 16MB flash, and 3.3/1.8v level converter components. Also removed the GSM and GPS antennas because they were just in the way. Removed the shield off a new WROVER module, de-soldered the 4MB 1.8v flash, and replaced it with a 16MB 1.8v flash. Then, soldered the new WROVER module onto the board. Then I re-soldered a couple of tiny resistors that came loose from all that messing around with the SMD heat gun :-) My eyes hurt… Too old for this SMD stuff. Here is what I get: OVMS > module memory Free 8-bit 127912/283860, 32-bit 912/16064, SPIRAM 4182228/4194252 --Task-- Total DRAM D/IRAM IRAM SPIRAM +/- DRAM D/IRAM IRAM SPIRAM AsyncConsole 988 6444 14404 12000 +988 +6444 +14404 +12000 no task 5348 0 0 0 +5348 +0 +0 +0 esp_timer 50848 0 644 0 +50848 +0 +644 +0 main 13052 0 0 0 +13052 +0 +0 +0 ipc0 11096 0 0 0 +11096 +0 +0 +0 Housekeeping 44924 0 0 0 +44924 +0 +0 +0 tiT 128 0 0 0 +128 +0 +0 +0 ipc1 12 0 0 0 +12 +0 +0 +0 Tmr Svc 20 0 0 0 +20 +0 +0 +0 It seems to work fine. I’ve got 4MB PSRAM, 16MB flash, and SD CARD all working together properly. Thanks Steve, for all that 'module memory' work - I hope Espressif accept it upstream because it is incredibly useful. We’ve also sourced a WROVER module already manufactured with 1.8v 16MB flash (to avoid all that nasty hacking around) - it is significantly more expensive, and long lead-time, but we’ll swallow the cost for the first batch (and hope to find a cheaper source for subsequent production runs). The 3.1 board itself doesn’t need modifying (just leave the external flash pads unpopulated). Side Note: The forums have got quite a few people asking for 16MB modules, but nobody making these as standard products. Given that the design is open source, we are now talking about going into the business of making 16MB WROVER modules :-) So, we should be good to go. I’ll just test all the other components, and make sure power consumption is still on track. My China contact gets back from Chinese New Year holidays at the end of this month. Should be good to start production early March. Mark

1 0

Compilation fails with newest version
by Geir Øyvind Vælidalo 05 Feb '18

05 Feb '18

Hi guys, I just synced and I get this error now: CXX build/console_ssh/src/console_ssh.o In file included from /Users/goev/Prosjekter/ovms3/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/console_ssh/src/console_ssh.cpp:38:0: /Users/goev/Prosjekter/ovms3/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_netmanager.h:40:22: fatal error: mongoose.h: No such file or directory compilation terminated. make[1]: *** [src/console_ssh.o] Error 1 make: *** [component-console_ssh-build] Error 2 Missing a file? Best regards, Geir

3 3

Roadster TPMS metrics fix
by Greg D. 03 Feb '18

03 Feb '18

Hi Mark, When you have time / desire for a distraction, I fixed a pair of typos in the Roadster TPMS code that prevented the rear metrics from being properly populated. Fix pushed to my fork; pull request created. Greg

1 0

OVMS Hardware v3.1
by Mark Webb-Johnson 30 Jan '18

30 Jan '18

Production… Analog Lamb, while interesting, is just (a) too expensive (double the price), (b) unproven, (c) uncertified, and (d) has long lead times. Using proven Espressif certified modules seems the safer way to go. So, we’ve decided to go with a switch to a standard certified ESP WROVER module, and external 16MB flash memory. The circuit board footprint for this is a little larger than the WROOM-32 module we’ve been using, and requires one more 3.3V->1.8V power conversion, but seems the safest way to go. Accordingly, I’ve agreed with the China guys to proceed along these lines for the main board: Change WROOM-32 to WROVER (on circuit antenna version, similar to WROOM-32). We can free IO12 (SD_D2), IO13 (SD_D3), and IO4 (SD_D1), by using just 1-line SDCARD. I don’t really want to use IO12 as that is a bootstrapping pin. WROVER PSRAM uses IO16 and IO17, so we can’t use that for modem. Move modem to IO4 and IO13. Change to 1.8V 16MB flash chip (W25Q128FW?). As SDD_VDIO is not exposed, add a simple regulator 3.3V->1.8V for external flash? When burning e-fuses, need to take care with 1.8V/3.3V SDD_SDIO fuse - leave at 1.8V. Add capacitors for SD CARD and external Flash, as per Espressif example. Increase size of solder pad for big capacitors, and USB connector, to make it stronger. For the data lines of circuit traces SDCARD, SPI bus, external flash, take care to keep away from power traces or other sources of interference and keep the traces as short as possible. The change to WROVER is a PITA at this stage, but that 4MB PSRAM should give us more headroom and the extra bill-of-materials costs is just a couple of US$. For the modem, we’re double-checking the power (which seems ok, but check to be sure), and changing passive -> active antenna. At the moment, it seems to be just a couple of passive components soldered inline between two easily accessible points. For existing developer modems in the field, we’ll try to make a simple upgrade kit (passive->active) for GPS, and post them out. If you don’t need GPS (such as Roadster users), the modem boards are functionally the same as the production ones. Existing developer OVMS v3 boards (with WROOM-32 module) will continue to be called v3.0. New production OVMS v3 boards (with WROVER module) will be called v3.1. We have conditional compilation in the firmware, to switch the pin assignments and whatever else is required. Branch: refs/heads/for-v3.0 Home: https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3 <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3> Commit: 9504df70be78b6626970ec0ea53d2c2470e90afa https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/950… <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/950…> Author: Mark Webb-Johnson <mark(a)webb-johnson.net <mailto:mark@webb-johnson.net>> Date: 2018-01-10 (Wed, 10 Jan 2018) Changed paths: M vehicle/OVMS.V3/main/Kconfig M vehicle/OVMS.V3/main/ovms_peripherals.h Log Message: ----------- Support for OVMS hardware v3.1 Converting developer v3.0 boards to v3.1 is not really feasible (a skilled solderer could probably use a 16MB Analog Lamb WROOM-32+PSRAM module; that would be a relatively simple de-solder + re-solder of the module, a not-so-simple re-arrange of the traces for IO16->IO4 and IO17->IO13, and disabling of external 16MB flash). Anyway, those existing developer modules should be fine to continue to use (just without the extra PSRAM). We are today finalising the circuit schematic and board layout for the above, and building a couple of test boards (with WROVER modules). I should have one in about a week’s time (assuming all the components are available). In that time, we’ll finish the ESP IDF v3.0 support, and test late next week / over next weekend (20th/21st Jan). Assuming no problems, we should be able to give factory the go-ahead to produce early the week after. Given that timing, I doubt if we are going to be able to get these boards made before the Chinese New Year holidays. Even if we can get them made, FastTech distribution may not be able to get them out during the holidays. Manufacturing in China starts to close down around the end of January / early February this year. New Year itself is mid-February. Anyway, we’ll get this all finalised, payment and instruction to start manufacturing in place, then do the best we can and get these out available during February. A big warning is going to go with them that this is for early adopters only, and firmware is changing on a daily basis. Updating firmware via wifi / sd card should be fine. I’m seeing a light at the end of a long dark tunnel. Regards, Mark.

3 8