On 1/23/21 10:25 AM, Michael Balzer wrote:

that's a very tempting option indeed, if compatible. I'm having no issues with Wifi, but the ESP32 V3 is very attractive (no more PSRAM issues…).

I have an arduino project that polls buttons and can send ir codes, update mqtt, and post json to a rest api https server. It also has mono and color displays. It uses the "comet protocol" to keep the data on the display current so it always has a http transaction open. I was having trouble with random hangs and upgrading to esp32-devkit V3 modules has almost completely eliminated this problem.

I don't have the equipment to desolder the module though… or any experience with that.

I have a little! I got a quick 861DW and successfully swapped a SIM7600A onto a ovms modem board. That is, I can talk to it but haven't done any work on adding support for it. (Like many of us, I have way too many projects in progress...) I also swapped a CP2102 (tiny little bugger).

Something I wasn't expecting is that the quick is an excellent tool for heating heat shrink! Gone are the days of using a lighter (and leaving charcoal marks on the tubing).

I think swapping the wroom module will actually be easier than the simcom, it has fewer pins. On the other hand it looks like I would have to remove one or both of the sma jacks and I know from experience that is not easy, they have a lot of thermal mass. I think I'll order a module and see if I can manage to remove the module with them in place, hopefully I can hold them out of the way (and protect the cables from heat, I have plenty of kynar tape).

	Craig

Success!

After protecting nearby components with kynar tape my hot air rework made "quick" work of removing the V1 module, including the ground pads on the back of the module. Then I hand soldered the new module in. (I wasn't sure if re-soldering the ground pads was important but I put a little solder paste on it and hit the back side of the board with a little hot air afterwards until the TPs flowed so there's some chance it's back to its original state.)

I repurposed an SMA/U.FL cable and wifi antenna from an old foxconn netbox and once I had flashed it and restore the config my wifi signal improved from -80.7 to -53.6 dBm. I'm pretty sure my (brick) chimney is inbetween my ruckus ap and this vehicle and had been thinking about relocating the ap but no need now.

 OVMS# module sum
 OVMS MODULE SUMMARY

 Module
   Version:  3.2.015-550-g49f7b669/factory/main (build idf 

v3.3.4-845-gd59ed8bba-dirty Jan 30 2021 18:31:40) Hardware: OVMS WIFI BLE BT cores=2 rev=ESP32/3

It doesn't look like ovms knows there is extra memory?

 OVMS# module memory
 Free 8-bit 83756/277928, 32-bit 6836/11192, SPIRAM 3826192/4194252

Also when I was bootstrapping the old config a wifi scan listed my WPA3 ssid but the module couldn't associate with it. But I do see an option with newer versions of the idf:

https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/kc... CONFIG_ESP32_WIFI_ENABLE_WPA3_SAE

 Select this option to allow the device to establish a WPA3-Personal
 connection with eligible AP's. PMF (Protected Management Frames)
 is a prerequisite feature for a WPA3 connection, it needs to
 be explicitly configured before attempting connection. Please
 refer to the Wi-Fi Driver API Guide for details.

I'm not sure if WPA3 requires V3 hardware or if it's purely an idf thing but it's something fun for the future.

	Craig

Craig,

congratulations to a successful heart transplantation :-)

Regarding RAM, I think you need to enable bank switching (CONFIG_SPIRAM_BANKSWITCH_ENABLE).

Please also disable the PSRAM bug workaround and maybe do some performance comparison. SPIRAM operations should run much faster without the workaround.

Regards, Michael

Am 31.01.21 um 08:29 schrieb Craig Leres:

On 1/30/21 9:47 PM, Craig Leres wrote:

...

It doesn't look like ovms knows there is extra memory?

I think actually the idf assumes 4 MB of SPIRAM and a future version will allow use of more memory.

I also figured out that my oldest ovms module has 16 MB of flash.

        Craig

ice 6540 % python esptool_py/esptool/esptool.py
--chip esp32
--port /dev/tty.SLAB_USBtoUART
--baud 921600
flash_id esptool.py v2.8 Serial port /dev/ovms-dev Connecting........_ Chip is ESP32D0WDQ6 (revision 1) Features: WiFi, BT, Dual Core, Coding Scheme None Crystal is 40MHz MAC: 30:ae:a4:??:??:?? Uploading stub... Running stub... Stub running... Changing baud rate to 921600 Changed. Manufacturer: ef Device: 6018 Detected flash size: 16MB Hard resetting via RTS pin...

---

OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev

-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

On 1/30/21 11:58 PM, Michael Balzer wrote:

congratulations to a successful heart transplantation :-)

With the right tools it was actually pretty easy. Certainly the hand soldering was easier than the CP2102 I swapped.

Regarding RAM, I think you need to enable bank switching (CONFIG_SPIRAM_BANKSWITCH_ENABLE).

Sounds like it's a little more complicated:

https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/sy...

 In order to use the himem API, you have to enable it in the
 menuconfig using CONFIG_SPIRAM_BANKSWITCH_ENABLE, as well as
 set the amount of banks reserved for this in
 CONFIG_SPIRAM_BANKSWITCH_RESERVE. This decreases the amount of
 external memory allocated by functions like malloc(), but it
 allows you to use the himem api to map any of the remaining
 memory into the reserved banks.

Please also disable the PSRAM bug workaround and maybe do some performance comparison. SPIRAM operations should run much faster without the workaround.

What kind of tests should I run?

I'll might wait to disable the workaround until I upgrade my other production ovms unit.

Forgot to explain: to fully disable the PSRAM workaround, you also need to modify main/component.mk:

COMPONENT_ADD_LDFLAGS = -Wl,--whole-archive -l$(COMPONENT_NAME) -Wl,--no-whole-archive -T main/ovms_boot.ld
-mfix-esp32-psram-cache-issue

Remove the "-mfix-esp32-psram-cache-issue" here.

I did some testing and I think adding -mfix-esp32-psram-cache-issue to COMPONENT_ADD_LDFLAGS can be driven by the CONFIG_SPIRAM_CACHE_WORKAROUND define. I submitted a pull request to do this (but please check my work).

	Craig

On 2/8/21 5:20 AM, Michael Balzer wrote:

Am 31.01.21 um 19:58 schrieb Craig Leres:

...

...

Please also disable the PSRAM bug workaround and maybe do some performance comparison. SPIRAM operations should run much faster without the workaround.

What kind of tests should I run?

I've just added an execution time output to my SPIRAM test command, which was meant to trigger the memory corruption, but can also serve as a memory benchmark.

To get comparable results, run the tests after booting with "config set auto init no" (you'll need a USB connection).

Tests with my results (ESP32/1, SPIRAM fix enabled, debug output removed):

OVMS# test string 1000 2 finished 1000 loops for mode 2 using extram in 33503 ms

OVMS# test string 5000 4 finished 5000 loops for mode 4 using extram in 30268 ms

OVMS# test string 25000 6 finished 25000 loops for mode 6 using extram in 34681 ms

Test mode 2 reads from metrics (involves locks & stream formatting), mode 4 reads a fixed string from the config, mode 6 is mostly pure memory copying.

I ran these with 3.2.016-27-g8564963b-dirty with this sdkconfig:

 ice 1186 % diff sdkconfig support/sdkconfig.default.hw31 | fgrep -v 

VEHICLE | egrep '^[<>]' < CONFIG_SPIRAM_CACHE_WORKAROUND= > CONFIG_SPIRAM_CACHE_WORKAROUND=y

The first time I just pasted the test lines into the serial window and the 2nd test caused a watchdog reset. But I wasn't able to reproduce it.

	Craig

OVMS# test string 1000 2 #1: stdlen = 1034 0,1,2,3,4,5,6,7,8,92,4,5,6,7,8,94202392OVMS WIFI BLE BT cores=2 rev=ESP32/3104-1271416156578083.2.016-27-g8564963b-dirty/ota_1/main (build idf v3.3.4-848-g1ff5e24b1 Mar 13 2021 09:19:45)11.5512.6no5889830,1,2,3,4,5,6,7,8,92,4,5,6,7,8,94202392OVMS WIFI BLE BT cores=2 rev=ESP32/3104-1271416156578083.2.016-27-g8564963b-dirty/ota_1/main (build idf v3.3.4-848-g1ff5e24b1 Mar 13 2021 09:19:45)11.5512.6no5889830,1,2,3,4,5,6,7,8,92,4,5,6,7,8,94202392OVMS WIFI BLE BT cores=2 rev=ESP32/3104-1271416156578083.2.016-27-g8564963b-dirty/ota_1/main (build idf v3.3.4-848-g1ff5e24b1 Mar 13 2021 09:19:45)11.5512.6no5889830,1,2,3,4,5,6,7,8,92,4,5,6,7,8,94202392OVMS WIFI BLE BT cores=2 rev=ESP32/3104-1271416156578083.2.016-27-g8564963b-dirty/ota_1/main (build idf v3.3.4-848-g1ff5e24b1 Mar 13 2021 09:19:45)11.5512.6no5889830,1,2,3,4,5,6,7,8,92,4,5,6,7,8,94202392OVMS WIFI BLE BT cores=2 rev=ESP32/3104-1271416156578083.2.016-27-g8564963b-dirty/ota_1/main (build idf v3.3.4-848-g1ff5e24b1 Mar 13 2021 09:19:45)11.5512.6no5889830,1,2,3,4,5,6,7,8,9

finished 1000 loops for mode 2 using extram in 37348 ms OVMS# test string 5000 4 #1: stdlen = 1030 2020053100202005310020200531002020053100202005310020200531002020053100202005310020200531002020053100202005310020200531002020053100202005310020200531002020053100202005310020200531002020053100202005310020200531002020053100202005310020200531002020053100202005310020200531002020053100202005310020200531002020053100202005310020200531002020053100202005310020200531002020053100202005310020200531002020053100202005310020200531002020053100202005310020200531002020053100202005310020200531002020053100202005310020200531002020053100202005310020200531002020053100202005310020200531002020053100202005310020200531002020053100202005310020200531002020053100202005310020200531002020053100202005310020200531002020053100202005310020200531002020053100202005310020200531002020053100202005310020200531002020053100202005310020200531002020053100202005310020200531002020053100202005310020200531002020053100202005310020200531002020053100202005310020200531002020053100202005310020200531002020053100202005310020200531002020053100202005310020200531002020053100

E (166099) task_wdt: Task watchdog got triggered. The following tasks did not reset the watchdog in time: E (166099) task_wdt: - IDLE1 (CPU 1) E (166099) task_wdt: - OVMS DukTape (CPU 1) E (166099) task_wdt: Tasks currently running: E (166099) task_wdt: CPU 0: IDLE0 E (166099) task_wdt: CPU 1: OVMS Events E (166099) task_wdt: Aborting. abort() was called at PC 0x400e6984 on core 0

ELF file SHA256: 3099b1f81632b65f

Backtrace: 0x40089947:0x3ffb0690 0x40089be1:0x3ffb06b0 0x400e6984:0x3ffb06d0 0x40083cd2:0x3ffb06f0

Rebooting... ets Jul 29 2019 12:21:46

==============================================================

ice 1189 % ./backtrace.sh 0x40089947:0x3ffb0690 0x40089be1:0x3ffb06b0 0x400e6984:0x3ffb06d0 0x40083cd2:0x3ffb06f0

• xtensa-esp32-elf-addr2line -e build/ovms3.elf 0x40089947:0x3ffb0690 0x40089be1:0x3ffb06b0 0x400e6984:0x3ffb06d0 0x40083cd2:0x3ffb06f0 /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/esp32/panic.c:736 /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/esp32/panic.c:736 /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/esp32/task_wdt.c:274 /home/ice/u0/leres/esp/openvehicles-xtensa-esp32-elf/components/freertos/xtensa_vectors.S:1154

==============================================================

OVMS# test string 5000 4 #1: stdlen = 1030 2020053100202005310020200531002020053100202005310020200531002020053100202005310020200531002020053100202005310020200531002020053100202005310020200531002020053100202005310020200531002020053100202005310020200531002020053100202005310020200531002020053100202005310020200531002020053100202005310020200531002020053100202005310020200531002020053100202005310020200531002020053100202005310020200531002020053100202005310020200531002020053100202005310020200531002020053100202005310020200531002020053100202005310020200531002020053100202005310020200531002020053100202005310020200531002020053100202005310020200531002020053100202005310020200531002020053100202005310020200531002020053100202005310020200531002020053100202005310020200531002020053100202005310020200531002020053100202005310020200531002020053100202005310020200531002020053100202005310020200531002020053100202005310020200531002020053100202005310020200531002020053100202005310020200531002020053100202005310020200531002020053100202005310020200531002020053100202005310020200531002020053100

finished 5000 loops for mode 4 using extram in 28945 ms OVMS# test string 25000 6 #1: stdlen = 1035 0123456789-abcdefghijk-0123456789-abcdefghijk-0123456789-abcdefghijk-0123456789-abcdefghijk-0123456789-abcdefghijk-0123456789-abcdefghijk-0123456789-abcdefghijk-0123456789-abcdefghijk-0123456789-abcdefghijk-0123456789-abcdefghijk-0123456789-abcdefghijk-0123456789-abcdefghijk-0123456789-abcdefghijk-0123456789-abcdefghijk-0123456789-abcdefghijk-0123456789-abcdefghijk-0123456789-abcdefghijk-0123456789-abcdefghijk-0123456789-abcdefghijk-0123456789-abcdefghijk-0123456789-abcdefghijk-0123456789-abcdefghijk-0123456789-abcdefghijk-0123456789-abcdefghijk-0123456789-abcdefghijk-0123456789-abcdefghijk-0123456789-abcdefghijk-0123456789-abcdefghijk-0123456789-abcdefghijk-0123456789-abcdefghijk-0123456789-abcdefghijk-0123456789-abcdefghijk-0123456789-abcdefghijk-0123456789-abcdefghijk-0123456789-abcdefghijk-0123456789-abcdefghijk-0123456789-abcdefghijk-0123456789-abcdefghijk-0123456789-abcdefghijk-0123456789-abcdefghijk-0123456789-abcdefghijk-0123456789-abcdefghijk-0123456789-abcdefghijk-0123456789-abcdefghijk-0123456789-abcdefghijk-

finished 25000 loops for mode 6 using extram in 34205 ms OVMS# test string 1000 2 #1: stdlen = 1034 0,1,2,3,4,5,6,7,8,92,4,5,6,7,8,94202384OVMS WIFI BLE BT cores=2 rev=ESP32/3405-1271416156582763.2.016-27-g8564963b-dirty/ota_1/main (build idf v3.3.4-848-g1ff5e24b1 Mar 13 2021 09:19:45)11.5412.6no5889830,1,2,3,4,5,6,7,8,92,4,5,6,7,8,94202384OVMS WIFI BLE BT cores=2 rev=ESP32/3405-1271416156582763.2.016-27-g8564963b-dirty/ota_1/main (build idf v3.3.4-848-g1ff5e24b1 Mar 13 2021 09:19:45)11.5412.6no5889830,1,2,3,4,5,6,7,8,92,4,5,6,7,8,94202384OVMS WIFI BLE BT cores=2 rev=ESP32/3405-1271416156582763.2.016-27-g8564963b-dirty/ota_1/main (build idf v3.3.4-848-g1ff5e24b1 Mar 13 2021 09:19:45)11.5412.6no5889830,1,2,3,4,5,6,7,8,92,4,5,6,7,8,94202384OVMS WIFI BLE BT cores=2 rev=ESP32/3405-1271416156582763.2.016-27-g8564963b-dirty/ota_1/main (build idf v3.3.4-848-g1ff5e24b1 Mar 13 2021 09:19:45)11.5412.6no5889830,1,2,3,4,5,6,7,8,92,4,5,6,7,8,94202384OVMS WIFI BLE BT cores=2 rev=ESP32/3405-1271416156582763.2.016-27-g8564963b-dirty/ota_1/main (build idf v3.3.4-848-g1ff5e24b1 Mar 13 2021 09:19:45)11.5412.6no5889830,1,2,3,4,5,6,7,8,9

finished 1000 loops for mode 2 using extram in 37315 ms W (441099) script: DuktapeDispatch: msg type 3 lost, queue full W (441099) script: DuktapeDispatch: msg type 3 lost, queue full W (442099) script: DuktapeDispatch: msg type 3 lost, queue full W (443099) script: DuktapeDispatch: msg type 3 lost, queue full OVMS#

On 3/14/21 12:15 AM, Michael Balzer wrote:

you triggered the watchdog by pasting all commands into the shell, you need to leave 1-2 seconds between the commands to feed the dog.

I didn't realize that was possible!

Do persistent metrics impact test mode 2? Looking at the ESP32-WROVER dat sheet (version 2.4) I see:

 ESP32-D0WDQ6 contains two low-power Xtensa 32-bit LX6
 microprocessors. The internal memory includes:

  - 448 KB of ROM for booting and core functions.

  - 520 KB of on-chip SRAM for data and instructions.

  - 8 KB of SRAM in RTC, which is called RTC FAST Memory and can
    be used for data storage; it is accessed by the main CPU
    during RTC Boot from the Deep-sleep mode.

  - 8 KB of SRAM in RTC, which is called RTC SLOW Memory and can
    be accessed by the co-processor during the Deep-sleep mode.

  - 1 Kbit of eFuse: 256 bits are used for the system (MAC address
    and chip configuration) and the remaining 768 bits are
    reserved for customer applications, including flash-encryption
    and chip-ID.

And:

 3.2 External Flash and SRAM

 SP32-WROVER integrates a 4 MB of external SPI flash and an 8
 MB PSRAM for more memory space.

It's confusing to me that the external ram is interchangeably called PSRAM (pseudo static RAM), SPI SRAM, and SPIRAM.

Anyway, does test mode 2 only access SPIRAM or does it also pull from RTC slow memory?

Your results could indicate the SPIRAM workaround doesn't really degrade performance for the kind of RAM accesses the test does.

Or it indicates something's wrong in your build / configuration, i.e. the SPIRAM workaround is still in place.

Ideas:

a) Did you do a "make clean" after disabling the SPIRAM workaround?

I've had the workaround disabled ever since I upgraded my modules to V3 and I don't bother with "make clean", I usually use "rm -rf build" (!)

b) Verify your toolkit version (should be crosstool-ng-1.22.0-97-gc752ad5)

ice 1243 % xtensa-esp32-elf-gcc --version xtensa-esp32-elf-gcc (crosstool-NG crosstool-ng-1.22.0-97-gc752ad5) 5.2.0

c) Verify the actual compiler & linker options given by doing "make -n"

I did something like:

 rm -rf build ; gmake -n | fgrep esp32can.o | fmt -1 > file

with CONFIG_SPIRAM_CACHE_WORKAROUND enabled and disabled and it looks like the flag is present/flag:

 ice 1277 % diff /tmp/workaround.txt /tmp/noworkaround.txt
 21d20
 < -mfix-esp32-psram-cache-issue

So my setup looks correct to me.

	Craig

Congratulations! I guess this wouldn't work to rejuventate my v3.0 module, though, because it has an older WROOM with fewer pins.

                                                    -- Steve

On Sat, 30 Jan 2021, Craig Leres wrote:

Success!

After protecting nearby components with kynar tape my hot air rework made "quick" work of removing the V1 module, including the ground pads on the back of the module. Then I hand soldered the new module in. (I wasn't sure if re-soldering the ground pads was important but I put a little solder paste on it and hit the back side of the board with a little hot air afterwards until the TPs flowed so there's some chance it's back to its original state.)

I repurposed an SMA/U.FL cable and wifi antenna from an old foxconn netbox and once I had flashed it and restore the config my wifi signal improved from -80.7 to -53.6 dBm. I'm pretty sure my (brick) chimney is inbetween my ruckus ap and this vehicle and had been thinking about relocating the ap but no need now.

OVMS# module sum
OVMS MODULE SUMMARY

Module
  Version:  3.2.015-550-g49f7b669/factory/main (build idf

v3.3.4-845-gd59ed8bba-dirty Jan 30 2021 18:31:40) Hardware: OVMS WIFI BLE BT cores=2 rev=ESP32/3

It doesn't look like ovms knows there is extra memory?

OVMS# module memory
Free 8-bit 83756/277928, 32-bit 6836/11192, SPIRAM 3826192/4194252

Also when I was bootstrapping the old config a wifi scan listed my WPA3 ssid but the module couldn't associate with it. But I do see an option with newer versions of the idf:

https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/kc... CONFIG_ESP32_WIFI_ENABLE_WPA3_SAE

Select this option to allow the device to establish a WPA3-Personal
connection with eligible AP's. PMF (Protected Management Frames)
is a prerequisite feature for a WPA3 connection, it needs to
be explicitly configured before attempting connection. Please
refer to the Wi-Fi Driver API Guide for details.

I'm not sure if WPA3 requires V3 hardware or if it's purely an idf thing but it's something fun for the future.

  Craig

On Sun, 31 Jan 2021, Craig Leres wrote:

I can't find any pictures of a v3.0 module but the esp32 V3 devkit's I've gotten have a smaller module with some side pins move to the bottom of the module. Does the wroom on your V3.0 board look like the attached?

Yes, attached are photos of the OVMS v3.0 board and the old DEVKIT-C with a topless module that Mark sent me when we were first starting out before the OVMS boards were made.

If so then maybe the ESP32-WROOM-32UE/M113EH2800UH3Q0 would work? Or ESP32-WROOM-32E/M113EH2800PH3Q0 if you don't want to switch to an external wifi antenna?

The ESP32-WROOM-32UE/M113EH2800UH3Q0 would allow me to attach an external antenna and perhaps increase flash size, but the WROOM series does not include PSRAM and that is the problem I want to fix.

                                                    -- Steve

On 1/31/21 3:17 PM, Stephen Casner wrote:

The ESP32-WROOM-32UE/M113EH2800UH3Q0 would allow me to attach an external antenna and perhaps increase flash size, but the WROOM series does not include PSRAM and that is the problem I want to fix.

I see what you mean; the esp32-wroom modules have psram but the esp32-wroom-32 do not:

https://docs.espressif.com/projects/esp-idf/en/latest/esp32/hw-reference/mod...

I decided to upgrade my other car to a V3 module so now both are running with CONFIG_SPIRAM_CACHE_WORKAROUND disabled.

	Craig

Very impressive, well done(!). Thanks for sharing, but I don’t have the soldering skills to pull this one off.

On Jan 31, 2021, at 5:53 PM, Stephen Casner <casner@acm.org> wrote:

It might be possible to make an adapter between the two pinouts using one or two layers of PCB. But the OVMS v3.0 board made connections the the pins on the end that are marked NC on the newer modules but were active on the older ESP32-WROOM-32. The v3.0 board has external flash connected there, which wouldn't be needed, but I seem to recall that the SD0-3 pins may have been used for some other function in addition.

                                                   -- Steve

---

OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev