January 2018 - OvmsDev - Open Vehicles

Boot Loop
by Tom Parker 22 Jan '18

22 Jan '18

The following script reliably puts the ovms into a boot loop: vfs mkdir /store/events vfs mkdir /store/events/system.start vfs rm /store/events/system.start/startmeup vfs append "log level debug" /store/events/system.start/startmeup vfs append "server v2 start" /store/events/system.start/startmeup Press the reset button and it loops with the log below. It can be fixed by "make erase_flash flash" but this obviously erases your config. If you swap the order of the two commands in the script, or if the script only contains on or other of the commands then it doesn't boot loop. ets Jun 8 2016 00:22:57 rst:0x1 (POWERON_RESET),boot:0x1f (SPI_FAST_FLASH_BOOT) configsip: 156795334, 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:4456 load:0x40078000,len:0 ho 12 tail 0 room 4 load:0x40078000,len:12988 entry 0x40078d14 I (168) ovms_main: Set default logging level for * to WARN Welcome to the Open Vehicle Monitoring System (OVMS) - Async Console OVMS > ***ERROR*** A stack overflow in task Housekeeping has been detected. abort() was called at PC 0x4008a824 on core 1 0x4008a824: vApplicationStackOverflowHook at /home/ubuntu/esp/esp-idf/components/esp32/./panic.c:572 Backtrace: 0x4008a70c:0x3ffcea70 0x4008a80b:0x3ffcea90 0x4008a824:0x3ffceab0 0x4008791c:0x3ffcead0 0x4008921c:0x3ffceaf0 0x400891d2:0x632e6769 0x4008a70c: invoke_abort at /home/ubuntu/esp/esp-idf/components/esp32/./panic.c:572 0x4008a80b: abort at /home/ubuntu/esp/esp-idf/components/esp32/./panic.c:572 0x4008a824: vApplicationStackOverflowHook at /home/ubuntu/esp/esp-idf/components/esp32/./panic.c:572 0x4008791c: vTaskSwitchContext at /home/ubuntu/esp/esp-idf/components/freertos/./tasks.c:4837 0x4008921c: _frxt_dispatch at /home/ubuntu/esp/esp-idf/components/freertos/./portasm.S:406 0x400891d2: _frxt_int_exit at /home/ubuntu/esp/esp-idf/components/freertos/./portasm.S:206 Rebooting... ets Jun 8 2016 00:22:57

2 1

Server v3, proof-of-concept
by Mark Webb-Johnson 22 Jan '18

22 Jan '18

I’ve committed a proof-of-concept for the server v3. Trying to keep this to just simple pure MQTT, so it can operate with any standard MQTT server. Of course, we’ll need our own api conventions on top of MQTT, but the basic metrics should work with any standard client/server. Screenshot below is from MQTTInspector on iPad, and I’m using a mosquito server. Don’t try this over cellular, as it currently sends metrics in real time as they change. For the final implementation, we’ll poll them in a similar way to v2 and only send changed ones once every N minutes. Regards, Mark

2 5

OVMS v3.0 modem active antenna modification:
by Mark Webb-Johnson 20 Jan '18

20 Jan '18

Here is the modification for active GPS antenna on OVMS v3.0 modems. I’m having a bunch made up pre-soldered and pre-tinned, so just need to be soldered at two points. I will send those out by post when I get them. Regards, Mark.

2 2

DB29 expansion GPIO
by Michael Balzer 20 Jan '18

20 Jan '18

Mark, I'm currently planning the SimpleConsole connection to v3.x. Given the schemes, it seems the DB29 connector does not offer direct connections to the GPIO lines -- is that correct? GEP_1…7 are not the GPIO lines but currently unused expansion pins on the piggy board connectors? So without additional expansion boards only EXP_1 & _2 are available as general purpose IO pins on the connector? Thanks, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

2 1

Missing File?
by Tom Parker 20 Jan '18

20 Jan '18

I just updated to the latest IDF and I'm getting this error: CXX build/main/ovms_module.o /vagrant/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_module.cpp:40:28: fatal error: esp_heap_debug.h: No such file or directory compilation terminated. /home/ubuntu/esp/esp-idf/make/component_wrapper.mk:273: recipe for target 'ovms_module.o' failed make[1]: *** [ovms_module.o] Error 1 If I delete line 40 of ovms_module.cpp to avoid trying to import this file then everything compiles. Well it compiles if I turn off the mdns server in menuconfig. If I leave that as the sdkconfig.default.hw30 values then I get this error: CXX build/ovms_mdns/src/ovms_mdns.o In file included from /vagrant/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/ovms_mdns/src/ovms_mdns.cpp:36:0: /vagrant/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/ovms_mdns/src/ovms_mdns.h:48:5: error: 'mdns_server_t' does not name a type mdns_server_t *m_mdns;

3 4

Add support for "log file ..." to log to the specified vfs file
by Mark Webb-Johnson 19 Jan '18

19 Jan '18

I’ve restructured the log commands a bit: The old "level <severity>” command has moved to "log level <severity>" A new “log file <path>” command has been added. For example “log file /sd/log.txt” will mean that anything that gets logged to the console will also get appended to /sd/log.txt as well, until reboot. You can use /sd (if SD CARD is working for you), or /store (but take care - that is system flash). You should be able to hook this in at the “sd.mounted” event script, to turn on logging to sd card on boot (again, if SD CARD is working for you). Enjoy, Mark > Branch: refs/heads/master > Home: https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3 > Commit: 6947670e33823dd68d4bf76b7872518fc8398264 > https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/694… > Author: Mark Webb-Johnson <mark(a)webb-johnson.net> > Date: 2018-01-08 (Mon, 08 Jan 2018) > > Changed paths: > M vehicle/OVMS.V3/main/console_async.cpp > M vehicle/OVMS.V3/main/ovms_command.cpp > M vehicle/OVMS.V3/main/ovms_log.h > M vehicle/OVMS.V3/main/ovms_main.cpp > > Log Message: > ----------- > Add support for "log file ..." to log to the specified vfs file

3 14

Re: [Ovmsdev] OVMS Hardware v3.1
by Mark Webb-Johnson 19 Jan '18

19 Jan '18

We hit a snag with the 3.1 hardware design. The flash voltage (VDD_SDIO) in WROVER module is 1.8V. In WROOM-32 module, VDD_SDIO was 3.3V. Also, as previously mentioned, the WROOM-32 modules uses GPIO16 and GPIO17 for external PSRAM (SPI CLK and CS signals). What wasn’t clear was _why_ they chose those pins. It now is… The ESP32 design is that some pins (GPIO16, GPIO17, FL_DATA_2, FL_DATA_3, FL_CMD, FL_CLK, FL_DATA_0, FL_DATA_1, and of course VDD_SDIO) operate in the VDD_SDIO domain, and the rest operate in the 3V3 domain. So, switching VDD_SDIO to 1.8V (is 3.3V in OVMS v3) also switches those eight GPIOs to 1.8V. Another complication is that VDD_SDIO is not exposed (not a problem for 3.3v, but an issue if we want 1.8v to power the external flash). I attach spreadsheet with ESP32, WROOM-32, and WROVER pinouts, along with strapping pins used and power domains (3.3V, SDIO/1.8V, etc). I think this makes things much clearer. The WROVER pins are essentially the same as WROOM-32. No more, no less. But, VDD_SDIO changes from 3.3V to 1.8V. It seems that the simplest approach is: Free GPIO4 (SD_DATA1), GPIO12 (SD_DATA2), and GPIO13 (SD_DATA3) and make SDCARD 1-line protocol. Note that GPIO12 is MTDI and is a strapping pin for 1.8V/3.3V, so we’ll try not to use that. GPIO16 and GPIO17 are now used by PSRAM (CS and CLK), and not exposed. So: Move UART 2 (TX to modem) to GPIO13. Move UART 2 (TX from modem) to GPIO4. Leave GPIO16 and GPIO17 unconnected (used internally by WROVER). That leaves the problem of GPIO22 (FL_CS2) for our external flash. All the other (shared) pins are VDD_SDIO (1.8v), but that pin is in the 3.3v domain, and we need it to drive an external 1.8v flash chip (which is not 3.3v tolerant). From what I can see, there are no free VDD_SDIO domain pins. #17 through #22 are used for SPI flash HSI, and the last two GPIO16 and GPIO17 are used for the PSRAM (and are not exposed outside WROVER so nothing we can do about it anyway). The only solution we can see is to continue to use GPIO22 for FL_CS2 external flash, but use a level converter 3.3V -> 1.8V. We only need uni-directional, but it must operate fast enough not to interfere with a 40MHz SPI bus. Maybe a resistor voltage divider would be too slow / interfere too much, so safer to use a simple single channel uni-directional 3.3V->1.8V logic level shifter chip. Trying to find a flash chip that is 3.3V tolerant, and test it, would just introduce more delays (for the sake of one extra 9cent component). Regarding the SDCARD. According to the specs, this is driven at 3.3V and our circuit has this on 3.3V pins, so that should be ok. The only issue is strapping pins GPIO2 and GPIO12. I can’t get this to work with Analog Lamb’s WROOM-32+PSRAM module at all, but it works fine on the Espressif WROVER-KIT I have (in both 1 line and 4 line modes). So we just use the capacitors and pull-up resistors from the WROVER-KIT arrangement, along with our existing GPIO2-GPIO0 link (as per Espressif SDCARD documentation): The changes to support this now include: Swap the GPIOs around, as above (freeing some pins from moving SDCARD 4-line to 1-line, and staying clear of the nasty GPIO12). Add a new small 3.3v->1.8v regulator, to power just our 16MB external flash chip (and level converter). Add a new unidirectional 3.3v->1.8 level converter for CS line of 16MB external flash. Switch external 16MB flash to a 1.8v component. Add a few capacitors on the power lines near external flash and SD CARD, to help with peak power draws. Re-work SD CARD pull-ups and protection circuitry (as per latest Espressif WROVER-KIT design). Minimising length of SPI and SD bus lines, and keeping them away from sources of interference (where possible). Increasing size of solder pad for USB connector, and large capacitors, to make stronger. I’m triple checking this tonight (as it goes to make boards tomorrow). I would appreciate any feedback from electrical engineers on this list. Regards, Mark. > Begin forwarded message: > > From: Mark Webb-Johnson <mark(a)webb-johnson.net> > Subject: [Ovmsdev] OVMS Hardware v3.1 > Date: 10 January 2018 at 2:41:58 PM HKT > To: OVMS Developers <OvmsDev(a)lists.teslaclub.hk> > Reply-To: OVMS Developers <ovmsdev(a)lists.teslaclub.hk> > > > 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. > > _______________________________________________ > OvmsDev mailing list > OvmsDev(a)lists.teslaclub.hk > http://lists.teslaclub.hk/mailman/listinfo/ovmsdev > Begin forwarded message: > > From: Mark Webb-Johnson <mark(a)webb-johnson.net> > Subject: OVMS Hardware v3.1 > Date: 10 January 2018 at 2:41:58 PM HKT > To: OVMS Developers <OvmsDev(a)lists.teslaclub.hk> > > > 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 5

CAN-3 broken again?
by Greg D. 18 Jan '18

18 Jan '18

Hi folks, I just resync'd with the main repository, and am not receiving frames on CAN-3 anymore. I see there were changes to the chip driver... I'm also seeing crashes right after getting connected to WiFi, immediately after the system tries to start SSH. Seems like we just took a big step backward. What happened? Greg

5 65

Fwd: Open Vehicle Monitoring System
by Mark Webb-Johnson 17 Jan '18

17 Jan '18

I have an OVMS user asking about this: What is the “100%: ~00:21” in the bottom (just above blue bar)? Also, what is the clock like symbol there? I guess it is time to charge to 100%? But with a roadster battery at 45% SOC, that is not possible. Also, car is not actually plugged in or charging. Regards, Mark.

2 1

One more WiFi mode off crash
by Greg D 17 Jan '18

17 Jan '18

I managed to get another WiFi related crash... As before, this was an attempt to turn it off right after the system starts (just before the first scan completed with the usual "incorrect scan type" message), but doing so at that time doesn't always seem to cause the crash. This is on the old 2.1 environment, if that matters. Greg OVMS > wifi mode off Stopping wifi station... ESP_ERROR_CHECK failed: esp_err_t 0x3002 at 0x400d8e2d 0x400d8e2d: _ZN9esp32wifi12EventTimer10ENSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEPv at /home/greg/greg/ovms/Open-Vehicle-Monitoring-System-3-master/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/esp32wifi/./esp32wifi.cpp:453 (discriminator 1) file: "/home/greg/greg/ovms/Open-Vehicle-Monitoring-System-3-master/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/esp32wifi/./esp32wifi.cpp" line 453 func: void esp32wifi::EventTimer10(std::__cxx11::string, void*) expression: esp_wifi_scan_start(&scanConf, false) Backtrace: 0x40088a70:0x3ffc9380 0x40088ded:0x3ffc93a0 0x400d8e2d:0x3ffc93c0 0x400da3f8:0x3ffc9400 0x40104a59:0x3ffc9440 0x40104cb2:0x3ffc9470 0x4010474d:0x3ffc94c0 0x40104887:0x3ffc9570 0x40087df6:0x3ffc9590 0x40087e29:0x3ffc95b0 0x40087f34:0x3ffc95e0 0x40088a70: invoke_abort at /home/greg/esp/esp-idf/components/esp32/./panic.c:519 0x40088ded: _esp_error_check_failed at /home/greg/esp/esp-idf/components/esp32/./panic.c:531 0x400d8e2d: _ZN9esp32wifi12EventTimer10ENSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEPv at /home/greg/greg/ovms/Open-Vehicle-Monitoring-System-3-master/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/esp32wifi/./esp32wifi.cpp:453 (discriminator 1) 0x400da3f8: _ZNKSt12_Mem_fn_baseIM9esp32wifiFvNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEPvELb1EEclIJS6_S7_EvEEvPS0_DpOT_ at /home/greg/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/functional:600 (inlined by) _ZNSt5_BindIFSt7_Mem_fnIM9esp32wifiFvNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEPvEEPS1_St12_PlaceholderILi1EESD_ILi2EEEE6__callIvJOS7_OS8_EJLj0ELj1ELj2EEEET_OSt5tupleIJDpT0_EESt12_Index_tupleIJXspT1_EEE at /home/greg/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/functional:1074 (inlined by) _ZNSt5_BindIFSt7_Mem_fnIM9esp32wifiFvNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEPvEEPS1_St12_PlaceholderILi1EESD_ILi2EEEEclIJS7_S8_EvEET0_DpOT_ at /home/greg/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/functional:1133 (inlined by) _ZNSt17_Function_handlerIFvNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEPvESt5_BindIFSt7_Mem_fnIM9esp32wifiFvS5_S6_EEPSA_St12_PlaceholderILi1EESF_ILi2EEEEE9_M_invokeERKSt9_Any_dataOS5_OS6_ at /home/greg/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/functional:1871 0x40104a59: _ZNKSt8functionIFvNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEPvEEclES5_S6_ at /home/greg/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/functional:2271 0x40104cb2: _ZN10OvmsEvents11SignalEventENSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEPv at /home/greg/greg/ovms/Open-Vehicle-Monitoring-System-3-master/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_events.cpp:144 0x4010474d: _ZN12Housekeeping7Ticker1Ev at /home/greg/greg/ovms/Open-Vehicle-Monitoring-System-3-master/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_housekeeping.cpp:184 0x40104887: _Z19HousekeepingTicker1Pv at /home/greg/greg/ovms/Open-Vehicle-Monitoring-System-3-master/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_housekeeping.cpp:57 0x40087df6: prvProcessExpiredTimer at /home/greg/esp/esp-idf/components/freertos/./timers.c:839 0x40087e29: prvProcessTimerOrBlockTask at /home/greg/esp/esp-idf/components/freertos/./timers.c:839 0x40087f34: prvTimerTask at /home/greg/esp/esp-idf/components/freertos/./timers.c:839 Rebooting...

2 1