- OvmsDev - Open Vehicles

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 18 Jan '18

18 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. 17 Jan '18

17 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 16 Jan '18

16 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 16 Jan '18

16 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

OVMS v3 CAN testing
by Mark Webb-Johnson 13 Jan '18

13 Jan '18

FYI: this is what I use for CAN bus testing: DB9 wired with all three -L lines together, and all three -H lines together, then a 120R termination resistor across CAN1. I also have external 12V power wired to a socket, but that is optional. With this in place, a TX and CAN1 produces RX on CAN2 and CAN3, etc. Regards, Mark

1 0

HUD Demo
by Greg D. 12 Jan '18

12 Jan '18

Hi folks, Our first sunny day here in quite a while, so I thought it would be a good time to take a quick video of the obd2ecu task (OBDII ECU translator) driving a HUD display. This is a rough draft - I'll make a more polished video when my kids visit in a few weeks and can help with the camera work. https://www.youtube.com/watch?v=AEyjckZBgOs Enjoy! Greg

2 2

Playing with SPI RAM
by Mark Webb-Johnson 12 Jan '18

12 Jan '18

Before: OVMS > module memory ============================ Free 8-bit 4291676/4507468, 32-bit 1608/16760, blocks dumped = 0 task=no task total= 38116 0 0 0 change= +38116 +0 +0 +0 task=esp_timer total= 49628 0 644 0 change= +49628 +0 +644 +0 task=main total= 9868 0 0 26924 change= +9868 +0 +0 +26924 task=ipc0 total= 11096 0 0 0 change= +11096 +0 +0 +0 task=Housekeeping total= 44032 0 0 12 change= +44032 +0 +0 +12 task=ipc1 total= 12 0 0 0 change= +12 +0 +0 +0 task=Tmr Svc total= 16 0 0 0 change= +16 +0 +0 +0 task=tiT total= 0 0 0 128 change= +0 +0 +0 +128 task=AsyncConsole total= 20 0 14404 12000 change= +20 +0 +14404 +12000 ============================ The change: class OvmsCommand { public: void* operator new(size_t sz) { return heap_caps_malloc(sz, MALLOC_CAP_SPIRAM); } void operator delete (void* ptr) { return free(ptr); } After: OVMS > module memory ============================ Free 8-bit 4291676/4507468, 32-bit 1608/16760, blocks dumped = 0 task=no task total= 38116 0 0 0 change= +38116 +0 +0 +0 task=esp_timer total= 28708 0 644 20916 change= +28708 +0 +644 +20916 task=main total= 9868 0 0 26924 change= +9868 +0 +0 +26924 task=ipc0 total= 11096 0 0 0 change= +11096 +0 +0 +0 task=Housekeeping total= 37984 0 0 6060 change= +37984 +0 +0 +6060 task=ipc1 total= 12 0 0 0 change= +12 +0 +0 +0 task=Tmr Svc total= 16 0 0 0 change= +16 +0 +0 +0 task=tiT total= 0 0 0 128 change= +0 +0 +0 +128 task=AsyncConsole total= 12020 0 14404 0 change= +12020 +0 +14404 +0 ============================ So, simply moving OvmsCommand objects to SPI RAM saves us about 26KB of internal RAM. Our goal would be to move as much of our infrequently accessed stuff as possible to SPI RAM. This would free up as much internal ram as possible for things like stacks, DMA, etc. Here are the restrictions on SPI RAM that Espressif point out: The use of external RAM has a few restrictions: When disabling flash cache (for example, because the flash is being written to), the external RAM also becomes inaccessible; any reads from or writes to it will lead to an illegal cache access exception. This is also the reason that ESP-IDF will never allocate a tasks stack in external RAM. External RAM cannot be used as a place to store DMA transaction descriptors or as a buffer for a DMA transfer to read from or write into. Any buffers that will be used in combination with DMA must be allocated using heap_caps_malloc(size, MALLOC_CAP_DMA) (and can be freed using a standard free() call.) External RAM uses the same cache region as the external flash. This means that often accessed variables in external RAM can be read and modified almost as quickly as in internal ram. However, when accessing large chunks of data (>32K), the cache can be insufficient and speeds will fall back to the access speed of the external RAM. Moreover, accessing large chunks of data can ‘push out’ cached flash, possibly making execution of code afterwards slower. External RAM cannot be used as task stack memory; because of this, xTaskCreate and similar functions will always allocate internal memory for stack and task TCBs and xTaskCreateStatic-type functions will check if the buffers passed are internal. However, for tasks not calling on code in ROM in any way, directly or indirectly, the menuconfig option SPIRAM_ALLOW_STACK_EXTERNAL_MEMORY <http://esp-idf.readthedocs.io/en/latest/api-reference/kconfig.html#config-s…> will eliminate the check in xTaskCreateStatic, allowing task stack in external RAM. Using this is not advised, however. Because there are a fair few situations that have a specific need for internal memory, but it is also possible to use malloc() to exhaust internal memory, there is a pool reserved specifically for requests that cannot be resolved from external memory; allocating task stack, DMA buffers and memory that stays accessible when cache is disabled is drawn from this pool. The size of this pool is configurable in menuconfig. I’m not having much luck trying to globally override the new() and delete() memory allocators, so I’m now thinking of making a base class with new and delete operators, plus some other utility functions to make spi ram allocation easier. Then whenever we want to make one of our objects allocatable from spiram we simply derive from that base class. That class could pickup on the menuconfig hardware version (3.0 WROOM-32 vs 3.1 WROVER) and turn on/off SPIRAM appropriately. Here is how Espressif do it: IRAM_ATTR void *heap_caps_malloc_default( size_t size ) { if (malloc_alwaysinternal_limit==MALLOC_DISABLE_EXTERNAL_ALLOCS) { return heap_caps_malloc( size, MALLOC_CAP_DEFAULT | MALLOC_CAP_INTERNAL); } else { void *r; if (size <= malloc_alwaysinternal_limit) { r=heap_caps_malloc( size, MALLOC_CAP_DEFAULT | MALLOC_CAP_INTERNAL ); } else { r=heap_caps_malloc( size, MALLOC_CAP_DEFAULT | MALLOC_CAP_SPIRAM ); } if (r==NULL) { //try again while being less picky r=heap_caps_malloc( size, MALLOC_CAP_DEFAULT ); } return r; } } We want to do the opposite - try to allocate from SPIRAM if it is available. There is a heap_caps_malloc_prefer that could do it for us. Thoughts? Regards, Mark.

2 2

Stack sizes
by Mark Webb-Johnson 12 Jan '18

12 Jan '18

It seems that we are continuously having to increase stack sizes. So, I went on a hunt to try to find out why… I put a abort() in the metrics_list() function. Spun up a wifi connection, an ovms_server_v2 connection, and then 'cmd.pl 7 'metric list’. Here are the stack frame details: (gdb) bt #0 0x40088dac in invoke_abort () at /Users/mark/esp/esp-idf/components/esp32/./panic.c:125 #1 0x40088e7a in abort () at /Users/mark/esp/esp-idf/components/esp32/./panic.c:134 #2 0x40123765 in metrics_list (verbosity=1024, writer=0x3fff6b94, cmd=0x3ffb6584, argc=0, argv=0x0) at /Users/mark/Documents/ovms/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_metrics.cpp:49 #3 0x4011e1a9 in OvmsCommand::Execute (this=0x3ffb6584, verbosity=1024, writer=0x3fff6b94, argc=0, argv=0x0) at /Users/mark/Documents/ovms/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_command.cpp:257 #4 0x4011e29d in OvmsCommand::Execute (this=0x3ffb64f0, verbosity=1024, writer=0x3fff6b94, argc=1, argv=0x3fff54d4) at /Users/mark/Documents/ovms/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_command.cpp:302 #5 0x4011e290 in OvmsCommand::Execute (this=0x3ffc3cc4 <MyCommandApp+4>, verbosity=1024, writer=0x3fff6b94, argc=2, argv=0x3fff54d4) at /Users/mark/Documents/ovms/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_command.cpp:298 #6 0x4011e2c4 in OvmsCommandApp::Execute (this=0x3ffc3cc0 <MyCommandApp>, verbosity=1024, writer=0x3fff6b94, argc=2, argv=0x3fff54d0) at /Users/mark/Documents/ovms/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_command.cpp:507 #7 0x401292a8 in Execute (rl=0x3fff6b9c, argc=2, argv=0x3fff54d0) at /Users/mark/Documents/ovms/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_shell.cpp:47 #8 0x400db2cd in new_line_handler (pThis=0x3fff6b9c) at /Users/mark/Documents/ovms/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/microrl/./microrl.c:626 #9 0x400db333 in microrl_insert_char (pThis=0x3fff6b9c, ch=10) at /Users/mark/Documents/ovms/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/microrl/./microrl.c:674 #10 0x401292f7 in OvmsShell::ProcessChar (this=0x3fff6b94, c=10 '\n') at /Users/mark/Documents/ovms/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_shell.cpp:62 #11 0x400f57d8 in OvmsServerV2::ProcessCommand (this=0x3fff433c, payload=<optimized out>) at /Users/mark/Documents/ovms/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/ovms_server_v2/src/ovms_server_v2.cpp:411 #12 0x400f9b54 in OvmsServerV2::ProcessServerMsg (this=0x3fff433c) at /Users/mark/Documents/ovms/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/ovms_server_v2/src/ovms_server_v2.cpp:336 #13 0x400fa263 in OvmsServerV2::ServerTask (this=0x3fff433c) at /Users/mark/Documents/ovms/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/ovms_server_v2/src/ovms_server_v2.cpp:244 #14 0x400f4325 in OvmsServer_task (pvParameters=0x3fff433c) at /Users/mark/Documents/ovms/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/ovms_server/./ovms_server.cpp:43 Stack level 0, frame at 0x3fff53f0: pc = 0x40088dac in invoke_abort (/Users/mark/esp/esp-idf/components/esp32/./panic.c:125); saved pc = 0x40088e7a called by frame at 0x3fff5410 source language c. Arglist at 0x3fff53d0, args: Locals at 0x3fff53d0, Previous frame's sp is 0x3fff53f0 Saved registers: ar56 at 0x3fff53c0, ar57 at 0x3fff53c4, ar58 at 0x3fff53c8, ar59 at 0x3fff53cc, ar60 at 0x3fff53f0, ar61 at 0x3fff53f4, ar62 at 0x3fff53f8, ar63 at 0x3fff53fc, a0 at 0x3fff53c0, a2 at 0x3fff53c8, a3 at 0x3fff53cc, a4 at 0x3fff53f0, a5 at 0x3fff53f4, a6 at 0x3fff53f8, a7 at 0x3fff53fc Stack level 1, frame at 0x3fff5410: pc = 0x40088e7a in abort (/Users/mark/esp/esp-idf/components/esp32/./panic.c:134); saved pc = 0x40123765 called by frame at 0x3fff5430, caller of frame at 0x3fff53f0 source language c. Arglist at 0x3fff53f0, args: Locals at 0x3fff53f0, Previous frame's sp is 0x3fff5410 Saved registers: ar48 at 0x3fff53e0, ar49 at 0x3fff53e4, ar50 at 0x3fff53e8, ar51 at 0x3fff53ec, ar52 at 0x3fff5410, ar53 at 0x3fff5414, ar54 at 0x3fff5418, ar55 at 0x3fff541c, a0 at 0x3fff53e0, a2 at 0x3fff53e8, a3 at 0x3fff53ec, a4 at 0x3fff5410, a5 at 0x3fff5414, a6 at 0x3fff5418, a7 at 0x3fff541c Stack level 2, frame at 0x3fff5430: pc = 0x40123765 in metrics_list (/Users/mark/Documents/ovms/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_metrics.cpp:49); saved pc = 0x4011e1a9 called by frame at 0x3fff5450, caller of frame at 0x3fff5410 source language c++. Arglist at 0x3fff5410, args: verbosity=1024, writer=0x3fff6b94, cmd=0x3ffb6584, argc=0, argv=0x0 Locals at 0x3fff5410, Previous frame's sp is 0x3fff5430 Saved registers: ar40 at 0x3fff5400, ar41 at 0x3fff5404, ar42 at 0x3fff5408, ar43 at 0x3fff540c, ar44 at 0x3fff5430, ar45 at 0x3fff5434, ar46 at 0x3fff5438, ar47 at 0x3fff543c, a0 at 0x3fff5400, a2 at 0x3fff5408, a3 at 0x3fff540c, a4 at 0x3fff5430, a5 at 0x3fff5434, a6 at 0x3fff5438, a7 at 0x3fff543c Stack level 3, frame at 0x3fff5450: pc = 0x4011e1a9 in OvmsCommand::Execute (/Users/mark/Documents/ovms/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_command.cpp:257); saved pc = 0x4011e29d called by frame at 0x3fff5470, caller of frame at 0x3fff5430 source language c++. Arglist at 0x3fff5430, args: this=0x3ffb6584, verbosity=1024, writer=0x3fff6b94, argc=0, argv=0x0 Locals at 0x3fff5430, Previous frame's sp is 0x3fff5450 Saved registers: ar32 at 0x3fff5420, ar33 at 0x3fff5424, ar34 at 0x3fff5428, ar35 at 0x3fff542c, ar36 at 0x3fff5450, ar37 at 0x3fff5454, ar38 at 0x3fff5458, ar39 at 0x3fff545c, a0 at 0x3fff5420, a2 at 0x3fff5428, a3 at 0x3fff542c, a4 at 0x3fff5450, a5 at 0x3fff5454, a6 at 0x3fff5458, a7 at 0x3fff545c Stack level 4, frame at 0x3fff5470: pc = 0x4011e29d in OvmsCommand::Execute (/Users/mark/Documents/ovms/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_command.cpp:302); saved pc = 0x4011e290 called by frame at 0x3fff5490, caller of frame at 0x3fff5450 source language c++. Arglist at 0x3fff5450, args: this=0x3ffb64f0, verbosity=1024, writer=0x3fff6b94, argc=1, argv=0x3fff54d4 Locals at 0x3fff5450, Previous frame's sp is 0x3fff5470 Saved registers: ar24 at 0x3fff5440, ar25 at 0x3fff5444, ar26 at 0x3fff5448, ar27 at 0x3fff544c, ar28 at 0x3fff5470, ar29 at 0x3fff5474, ar30 at 0x3fff5478, ar31 at 0x3fff547c, a0 at 0x3fff5440, a2 at 0x3fff5448, a3 at 0x3fff544c, a4 at 0x3fff5470, a5 at 0x3fff5474, a6 at 0x3fff5478, a7 at 0x3fff547c Stack level 5, frame at 0x3fff5490: pc = 0x4011e290 in OvmsCommand::Execute (/Users/mark/Documents/ovms/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_command.cpp:298); saved pc = 0x4011e2c4 called by frame at 0x3fff54b0, caller of frame at 0x3fff5470 source language c++. Arglist at 0x3fff5470, args: this=0x3ffc3cc4 <MyCommandApp+4>, verbosity=1024, writer=0x3fff6b94, argc=2, argv=0x3fff54d4 Locals at 0x3fff5470, Previous frame's sp is 0x3fff5490 Saved registers: ar16 at 0x3fff5460, ar17 at 0x3fff5464, ar18 at 0x3fff5468, ar19 at 0x3fff546c, ar20 at 0x3fff5490, ar21 at 0x3fff5494, ar22 at 0x3fff5498, ar23 at 0x3fff549c, a0 at 0x3fff5460, a2 at 0x3fff5468, a3 at 0x3fff546c, a4 at 0x3fff5490, a5 at 0x3fff5494, a6 at 0x3fff5498, a7 at 0x3fff549c Stack level 6, frame at 0x3fff54b0: pc = 0x4011e2c4 in OvmsCommandApp::Execute (/Users/mark/Documents/ovms/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_command.cpp:507); saved pc = 0x401292a8 called by frame at 0x3fff54d0, caller of frame at 0x3fff5490 source language c++. Arglist at 0x3fff5490, args: this=0x3ffc3cc0 <MyCommandApp>, verbosity=1024, writer=0x3fff6b94, argc=2, argv=0x3fff54d0 Locals at 0x3fff5490, Previous frame's sp is 0x3fff54b0 Saved registers: ar8 at 0x3fff5480, ar9 at 0x3fff5484, ar10 at 0x3fff5488, ar11 at 0x3fff548c, ar12 at 0x3fff54b0, ar13 at 0x3fff54b4, ar14 at 0x3fff54b8, ar15 at 0x3fff54bc, a0 at 0x3fff5480, a2 at 0x3fff5488, a3 at 0x3fff548c, a4 at 0x3fff54b0, a5 at 0x3fff54b4, a6 at 0x3fff54b8, a7 at 0x3fff54bc Stack level 7, frame at 0x3fff54d0: pc = 0x401292a8 in Execute (/Users/mark/Documents/ovms/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_shell.cpp:47); saved pc = 0x400db2cd called by frame at 0x3fff5530, caller of frame at 0x3fff54b0 source language c++. Arglist at 0x3fff54b0, args: rl=0x3fff6b9c, argc=2, argv=0x3fff54d0 Locals at 0x3fff54b0, Previous frame's sp is 0x3fff54d0 Saved registers: ar0 at 0x3fff54a0, ar1 at 0x3fff54a4, ar2 at 0x3fff54a8, ar3 at 0x3fff54ac, ar4 at 0x3fff5510, ar5 at 0x3fff5514, ar6 at 0x3fff5518, ar7 at 0x3fff551c, a0 at 0x3fff54a0, a2 at 0x3fff54a8, a3 at 0x3fff54ac, a4 at 0x3fff5510, a5 at 0x3fff5514, a6 at 0x3fff5518, a7 at 0x3fff551c Stack level 8, frame at 0x3fff5530: pc = 0x400db2cd in new_line_handler (/Users/mark/Documents/ovms/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/microrl/./microrl.c:626); saved pc = 0x400db333 called by frame at 0x3fff5560, caller of frame at 0x3fff54d0 source language c. Arglist at 0x3fff54d0, args: pThis=0x3fff6b9c Locals at 0x3fff54d0, Previous frame's sp is 0x3fff5530 Saved registers: ar56 at 0x3fff54c0, ar57 at 0x3fff54c4, ar58 at 0x3fff54c8, ar59 at 0x3fff54cc, ar60 at 0x3fff5540, ar61 at 0x3fff5544, ar62 at 0x3fff5548, ar63 at 0x3fff554c, a0 at 0x3fff54c0, a2 at 0x3fff54c8, a3 at 0x3fff54cc, a4 at 0x3fff5540, a5 at 0x3fff5544, a6 at 0x3fff5548, a7 at 0x3fff554c Stack level 9, frame at 0x3fff5560: pc = 0x400db333 in microrl_insert_char (/Users/mark/Documents/ovms/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/microrl/./microrl.c:674); saved pc = 0x401292f7 called by frame at 0x3fff5580, caller of frame at 0x3fff5530 source language c. Arglist at 0x3fff5530, args: pThis=0x3fff6b9c, ch=10 Locals at 0x3fff5530, Previous frame's sp is 0x3fff5560 Saved registers: ar48 at 0x3fff5520, ar49 at 0x3fff5524, ar50 at 0x3fff5528, ar51 at 0x3fff552c, ar52 at 0x3fff5560, ar53 at 0x3fff5564, ar54 at 0x3fff5568, ar55 at 0x3fff556c, a0 at 0x3fff5520, a2 at 0x3fff5528, a3 at 0x3fff552c, a4 at 0x3fff5560, a5 at 0x3fff5564, a6 at 0x3fff5568, a7 at 0x3fff556c Stack level 10, frame at 0x3fff5580: pc = 0x401292f7 in OvmsShell::ProcessChar (/Users/mark/Documents/ovms/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_shell.cpp:62); saved pc = 0x400f57d8 called by frame at 0x3fff5e20, caller of frame at 0x3fff5560 source language c++. Arglist at 0x3fff5560, args: this=0x3fff6b94, c=10 '\n' Locals at 0x3fff5560, Previous frame's sp is 0x3fff5580 Saved registers: ar40 at 0x3fff5550, ar41 at 0x3fff5554, ar42 at 0x3fff5558, ar43 at 0x3fff555c, ar44 at 0x3fff5e00, ar45 at 0x3fff5e04, ar46 at 0x3fff5e08, ar47 at 0x3fff5e0c, a0 at 0x3fff5550, a2 at 0x3fff5558, a3 at 0x3fff555c, a4 at 0x3fff5e00, a5 at 0x3fff5e04, a6 at 0x3fff5e08, a7 at 0x3fff5e0c Stack level 11, frame at 0x3fff5e20: pc = 0x400f57d8 in OvmsServerV2::ProcessCommand (/Users/mark/Documents/ovms/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/ovms_server_v2/src/ovms_server_v2.cpp:411); saved pc = 0x400f9b54 called by frame at 0x3fff5ee0, caller of frame at 0x3fff5580 source language c++. Arglist at 0x3fff5580, args: this=0x3fff433c, payload=<optimized out> Locals at 0x3fff5580, Previous frame's sp is 0x3fff5e20 Saved registers: ar32 at 0x3fff5570, ar33 at 0x3fff5574, ar34 at 0x3fff5578, ar35 at 0x3fff557c, ar36 at 0x3fff5ec0, ar37 at 0x3fff5ec4, ar38 at 0x3fff5ec8, ar39 at 0x3fff5ecc, a0 at 0x3fff5570, a2 at 0x3fff5578, a3 at 0x3fff557c, a4 at 0x3fff5ec0, a5 at 0x3fff5ec4, a6 at 0x3fff5ec8, a7 at 0x3fff5ecc Stack level 12, frame at 0x3fff5ee0: pc = 0x400f9b54 in OvmsServerV2::ProcessServerMsg (/Users/mark/Documents/ovms/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/ovms_server_v2/src/ovms_server_v2.cpp:336); saved pc = 0x400fa263 called by frame at 0x3fff5f80, caller of frame at 0x3fff5e20 source language c++. Arglist at 0x3fff5e40, args: this=0x3fff433c Locals at 0x3fff5e40, Previous frame's sp is 0x3fff5ee0 Saved registers: ar24 at 0x3fff5e10, ar25 at 0x3fff5e14, ar26 at 0x3fff5e18, ar27 at 0x3fff5e1c, ar28 at 0x3fff5f60, ar29 at 0x3fff5f64, ar30 at 0x3fff5f68, ar31 at 0x3fff5f6c, a0 at 0x3fff5e10, a2 at 0x3fff5e18, a3 at 0x3fff5e1c, a4 at 0x3fff5f60, a5 at 0x3fff5f64, a6 at 0x3fff5f68, a7 at 0x3fff5f6c Stack level 13, frame at 0x3fff5f80: pc = 0x400fa263 in OvmsServerV2::ServerTask (/Users/mark/Documents/ovms/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/ovms_server_v2/src/ovms_server_v2.cpp:244); saved pc = 0x400f4325 called by frame at 0x0, caller of frame at 0x3fff5ee0 source language c++. Arglist at 0x3fff5ee0, args: this=0x3fff433c Locals at 0x3fff5ee0, Previous frame's sp is 0x3fff5f80 Saved registers: ar16 at 0x3fff5ed0, ar17 at 0x3fff5ed4, ar18 at 0x3fff5ed8, ar19 at 0x3fff5edc, ar20 at 0x3fff5f80, ar21 at 0x3fff5f84, ar22 at 0x3fff5f88, ar23 at 0x3fff5f8c, a0 at 0x3fff5ed0, a2 at 0x3fff5ed8, a3 at 0x3fff5edc, a4 at 0x3fff5f80, a5 at 0x3fff5f84, a6 at 0x3fff5f88, a7 at 0x3fff5f8c Stack level 14, frame at 0x0: pc = 0x400f4325 in OvmsServer_task (/Users/mark/Documents/ovms/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/ovms_server/./ovms_server.cpp:43); saved pc = 0x40000000 Outermost frame: outermost caller of frame at 0x3fff5f80 source language c++. Arglist at 0x3fff5f80, args: pvParameters=0x3fff433c Locals at 0x3fff5f80, Previous frame's sp is 0x0 Saved registers: ar16 at 0x3fff5f70, ar17 at 0x3fff5f74, ar18 at 0x3fff5f78, ar19 at 0x3fff5f7c, a0 at 0x3fff5f70, a2 at 0x3fff5f78, a3 at 0x3fff5f7c Here are the stack frame pointers: OvmsServer_task Stack level 14, frame at 0x0: OvmsServerV2::ServerTask Stack level 13, frame at 0x3fff5f80: 160 bytes OvmsServerV2::ProcessServerMsg Stack level 12, frame at 0x3fff5ee0: 192 bytes OvmsServerV2::ProcessCommand Stack level 11, frame at 0x3fff5e20: 2208 bytes OvmsShell::ProcessChar Stack level 10, frame at 0x3fff5580: 32 bytes microrl_insert_char Stack level 9, frame at 0x3fff5560: 48 bytes new_line_handler Stack level 8, frame at 0x3fff5530: 92 bytes Execute Stack level 7, frame at 0x3fff54d0: 32 bytes OvmsCommandApp::ExecuteStack level 6, frame at 0x3fff54b0: 32 bytes OvmsCommand::Execute Stack level 5, frame at 0x3fff5490: 32 bytes OvmsCommand::Execute Stack level 4, frame at 0x3fff5470: 32 bytes OvmsCommand::Execute Stack level 3, frame at 0x3fff5450: 32 bytes metrics_list Stack level 2, frame at 0x3fff5430: 32 bytes abort Stack level 1, frame at 0x3fff5410: 32 bytes invoke_abort Stack level 0, frame at 0x3fff53f0 That frame #11 stands out like a sore thumb. Here are the details: (gdb) info frame Stack level 11, frame at 0x3fff5e20: pc = 0x400f57d8 in OvmsServerV2::ProcessCommand (/Users/mark/Documents/ovms/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/ovms_server_v2/src/ovms_server_v2.cpp:411); saved pc = 0x400f9b54 called by frame at 0x3fff5ee0, caller of frame at 0x3fff5580 source language c++. Arglist at 0x3fff5580, args: this=0x3fff433c, payload=<optimized out> Locals at 0x3fff5580, Previous frame's sp is 0x3fff5e20 Saved registers: ar32 at 0x3fff5570, ar33 at 0x3fff5574, ar34 at 0x3fff5578, ar35 at 0x3fff557c, ar36 at 0x3fff5ec0, ar37 at 0x3fff5ec4, ar38 at 0x3fff5ec8, ar39 at 0x3fff5ecc, a0 at 0x3fff5570, a2 at 0x3fff5578, a3 at 0x3fff557c, a4 at 0x3fff5ec0, a5 at 0x3fff5ec4, a6 at 0x3fff5ec8, a7 at 0x3fff5ecc (gdb) info locals bs = 0x3fff6b94 val = {static npos = <optimized out>, _M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0x9c85f1ef '\377' <repeats 200 times>...}, _M_string_length = 2512534878, {_M_local_buf = "\377\377\377\377\063\234\351\347W\243\303*\242\004\000\017", _M_allocated_capacity = 4294967295}} command = <optimized out> sep = 1 vehicle = 0x0 buffer = {<std::basic_ostream<char, std::char_traits<char> >> = {<std::basic_ios<char, std::char_traits<char> >> = {<std::ios_base> = { _vptr$ios_base = 0x3f4168bc <vtable for std::__cxx11::basic_ostringstream<char, std::char_traits<char>, std::allocator<char> >+32>, static boolalpha = std::_S_boolalpha, static dec = std::_S_dec, static fixed = std::_S_fixed, static hex = std::_S_hex, static internal = std::_S_internal, static left = std::_S_left, static oct = std::_S_oct, static right = std::_S_right, static scientific = std::_S_scientific, static showbase = std::_S_showbase, static showpoint = std::_S_showpoint, static showpos = std::_S_showpos, static skipws = std::_S_skipws, static unitbuf = std::_S_unitbuf, static uppercase = std::_S_uppercase, static adjustfield = std::_S_adjustfield, static basefield = std::_S_basefield, static floatfield = std::_S_floatfield, static badbit = std::_S_badbit, static eofbit = std::_S_eofbit, static failbit = std::_S_failbit, static goodbit = std::_S_goodbit, static app = std::_S_app, static ate = std::_S_ate, static binary = std::_S_bin, static in = std::_S_in, static out = std::_S_out, static trunc = std::_S_trunc, static beg = std::_S_beg, static cur = std::_S_cur, static end = std::_S_end, _M_precision = 6, _M_width = 0, _M_flags = 4098, _M_exception = std::_S_goodbit, _M_streambuf_state = std::_S_goodbit, _M_callbacks = 0x0, _M_word_zero = {_M_pword = 0x0, _M_iword = 0}, _M_local_word = {{_M_pword = 0x0, _M_iword = 0}, {_M_pword = 0x0, _M_iword = 0}, {_M_pword = 0x0, _M_iword = 0}, {_M_pword = 0x0, _M_iword = 0}, { _M_pword = 0x0, _M_iword = 0}, {_M_pword = 0x0, _M_iword = 0}, {_M_pword = 0x0, _M_iword = 0}, {_M_pword = 0x0, _M_iword = 0}}, _M_word_size = 8, _M_word = 0x3fff5c84, _M_ios_locale = { static none = 0, static ctype = 1, static numeric = 2, static collate = 4, static time = 8, static monetary = 16, static messages = 32, static all = 63, _M_impl = 0x3ffc4c2c <(anonymous namespace)::c_locale_impl>, static _S_classic = 0x3ffc4c2c <(anonymous namespace)::c_locale_impl>, static _S_global = 0x3ffc4c2c <(anonymous namespace)::c_locale_impl>, static _S_categories = <optimized out>, static _S_twinned_facets = 0x3f415488 <std::locale::_S_twinned_facets>}}, _M_tie = 0x0, _M_fill = 0 '\000', _M_fill_init = false, _M_streambuf = 0x3fff5c24, _M_ctype = 0x3ffc4878 <(anonymous namespace)::ctype_c>, _M_num_put = 0x3ffc4850 <(anonymous namespace)::num_put_c>, _M_num_get = 0x3ffc4858 <(anonymous namespace)::num_get_c>}, _vptr$basic_ostream = 0x3f4168a8 <vtable for std::__cxx11::basic_ostringstream<char, std::char_traits<char>, std::allocator<char> >+12>}, _M_stringbuf = {<std::basic_streambuf<char, std::char_traits<char> >> = { _vptr$basic_streambuf = 0x3f4167cc <vtable for std::__cxx11::basic_stringbuf<char, std::char_traits<char>, std::allocator<char> >+8>, _M_in_beg = 0x0, _M_in_cur = 0x0, _M_in_end = 0x0, _M_out_beg = 0x0, _M_out_cur = 0x0, _M_out_end = 0x0, _M_buf_locale = {static none = 0, static ctype = 1, static numeric = 2, static collate = 4, static time = 8, static monetary = 16, static messages = 32, static all = 63, _M_impl = 0x3ffc4c2c <(anonymous namespace)::c_locale_impl>, static _S_classic = 0x3ffc4c2c <(anonymous namespace)::c_locale_impl>, static _S_global = 0x3ffc4c2c <(anonymous namespace)::c_locale_impl>, static _S_categories = <optimized out>, static _S_twinned_facets = 0x3f415488 <std::locale::_S_twinned_facets>}}, _M_mode = std::_S_out, _M_string = {static npos = <optimized out>, _M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0x3fff5c50 ""}, _M_string_length = 0, {_M_local_buf = "\000\377\377\377y\031\b@\000\000\000\000\250\177\b@", _M_allocated_capacity = 4294967040}}}} (gdb) info args this = 0x3fff433c payload = <optimized out> Also frame #12: (gdb) info frame Stack level 12, frame at 0x3fff5ee0: pc = 0x400f9b54 in OvmsServerV2::ProcessServerMsg (/Users/mark/Documents/ovms/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/ovms_server_v2/src/ovms_server_v2.cpp:336); saved pc = 0x400fa263 called by frame at 0x3fff5f80, caller of frame at 0x3fff5e20 source language c++. Arglist at 0x3fff5e40, args: this=0x3fff433c Locals at 0x3fff5e40, Previous frame's sp is 0x3fff5ee0 Saved registers: ar24 at 0x3fff5e10, ar25 at 0x3fff5e14, ar26 at 0x3fff5e18, ar27 at 0x3fff5e1c, ar28 at 0x3fff5f60, ar29 at 0x3fff5f64, ar30 at 0x3fff5f68, ar31 at 0x3fff5f6c, a0 at 0x3fff5e10, a2 at 0x3fff5e18, a3 at 0x3fff5e1c, a4 at 0x3fff5f60, a5 at 0x3fff5f64, a6 at 0x3fff5f68, a7 at 0x3fff5f6c (gdb) info locals line = {static npos = <optimized out>, _M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0x3fff68a8 "MP-0 C7,metric list"}, _M_string_length = 19, {_M_local_buf = "\023\000\000\000\000\000\000\000\270^\377?\270^\377?", _M_allocated_capacity = 19}} b = 0x3fff5e20 "MP-0 C7,metric list" len = <optimized out> code = 67 'C' payload = {static npos = <optimized out>, _M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0x3fff5ea8 "7,metric list"}, _M_string_length = 13, {_M_local_buf = "7,metric list\000\000", _M_allocated_capacity = 1701653559}} (gdb) info args this = 0x3fff433c Here is the size of that std::ostringstream: std::ostringstream buffer; ESP_LOGI(TAG,"std::ostringstream buffer is %d bytes",sizeof(buffer)); I (41478) ovms-server-v2: std::ostringstream buffer is 200 bytes 200 bytes, not 2,000 bytes, so something else is going on here. Anyway, changing it to a dynamically (new/delete) allocated buffer, drops stack usage of that frame to 1,824 bytes (was 2,208 so that is 384 bytes saved). That uint8_t b[line.length()+1] in OvmsServerV2::ProcessServerMsg() is also nasty - it will grow stack usage depending on line length. So, we’ll fix that as well. 192 bytes -> 160 bytes. Things to note: Each stack call is a minimum of 32 bytes. Not so bad, really - we’d need to nest calls 32 deep to get 1KB stack usage. Local variables are scary. They can be unexpectedly large. Best to new/free them, to guarantee just 4 bytes each. The OvmsCommand::Execute recursion I was worried about is not so bad. Probably 100 bytes of stack, or so, for most commands. We could improve that by getting rid of the recursion (it is elegant, but not strictly necessary), but it doesn’t seem to be a big win. I’m still looking for 150+ bytes in OvmsServerV2::ProcessServerMsg(), and 1,900+ bytes in OvmsServerV2::ProcessCommand(). Those would be big. Regards, Mark.

3 5

<enter> not working with vfs edit?
by Greg D. 11 Jan '18

11 Jan '18

Is anyone else having trouble with the vfs editor? I can't seem to enter a newline anymore. The status line at the bottom complains of an unknown command 10 (presumably control-J). If I try an explicit control-M, it says the same. Did I fat-finger something in my config (I removed SSH, Telnet, and several other items to save RAM recently), or did something else change? This is with two different terminals - make monitor on the development laptop, and putty on my in-car Raspberry Pi. Greg

4 3