Skip to content

Conversation

@MartinEmrich
Copy link

Potentially fixes: #8732 #8729

Effectively reverts 9211b1b
for ESP32 devices without PSRAM, like my Lilygo V2 1.6.1.

All versions later have ~20kB less heap, making them slow and unresponsive when using with Wifi (App cannot connect, using API is very slow, regular network dropouts).

This reverts that change for plain ESP32 devices that have no PSRAM, which I assume would be used if present.

🤝 Attestations

  • I have tested that my proposed changes behave as described.
  • I have tested that my proposed changes do not cause any obvious regressions on the following devices:
    • Heltec (Lora32) V3
    • LilyGo T-Deck
    • LilyGo T-Beam
    • RAK WisBlock 4631
    • Seeed Studio T-1000E tracker card
    • Other (please specify below)
    • Lilygo T3 V2 1.6.1

@CLAassistant
Copy link

CLAassistant commented Dec 6, 2025

CLA assistant check
All committers have signed the CLA.

@CLAassistant
Copy link

CLA assistant check
Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
You have signed the CLA already but the status is still pending? Let us recheck it.

@MartinEmrich
Copy link
Author

After leaving the device running for a while, the heap usage still creeps up, and at the 88-90% mark the device starts to drop IP connectivity (Mesh node activity seems to be less affected).

@jp-bennett
Copy link
Collaborator

It would be nice to identify what is leaking memory.

@MartinEmrich
Copy link
Author

@jp-bennett TBH I don't think it's a memory leak in the classical sense (memory gets malloc()d and forgotten), but the dynamic allocation over time allocates the same amount of memory as was pre-allocated without that patch. It was worth a try, but we (me and some participants in the linked issues) now think it its also caused by some bloat creeping in since 2.6.x, and a feature-reduced build for non-PSRAM devices (or an expert optimizing the code for memory usage) is probably necessary.

If a maintainer clearly agrees, I am happy to close the PR without a merge, clearly even in my less-populared area the memory allocated quickly reaches the same amount as pre-allocated.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Bug]: LiliGo T-Beam consumes 89+% of the heap when wifi is enabled on 2.7.15

3 participants