On 9/26/21 10:28 AM, Michael Balzer wrote:
just to be sure: you refitted both your modules with an ESP32 rev 3, only difference is, the production module is running "master", sim7600 module "for-v3.3"?
That's right: OVMS# mod sum OVMS MODULE SUMMARY Module Version: 3.2.016-292-g61cde63a/ota_1/main (build idf v3.3.4-848-g1ff5e24b1 Sep 17 2021 09:44:13) Hardware: OVMS WIFI BLE BT cores=2 rev=ESP32/3
If so, my conclusions so far would be:
a) we've got a real heap corruption issue that sometimes gets triggered by the test. I've had it twice around the same place, i.e. within the scheduled event processing. I'll check my code.
That's what it looks like to me. I think my sim7600 module hits the bug less often because it's not doing anything (especially when the modem goes offline). The production module is posting v2/v3 data giving it more chances to hit the bug.
b) more important: only ESP32 rev 3 really solves the SPIRAM bug. It's not completely solved by the workaround, the workaround just reduces the frequency.
Is it possible the spiram workarounds are more complete in the newest version of the idf? Does the newer compiler toolchain it uses factor in at all? Craig