Debug Message
\nNone, comparing output program size for different Core versions\nOther Steps to Reproduce
\nNo, just run the nullprog.ino
\ntest results speak for themselves
I have checked existing issues, online documentation and the Troubleshooting Guide
\n- \n
- I confirm I have checked existing issues, online documentation and Troubleshooting guide. \n
I dug deep into this and here is my conclusion:
\n- \n
- Size increase comes from the WiFi library after the network layer refactoring in v3 \n
- It is present on empty sketch, because we always instantiate the
WiFiobject \n - This was true even before, but now we include proper destructors for the AP and STA interfaces \n
- The destructors call
WiFi.mode()internally, which in turn links to all low level WiFi and Netif init/deinit methods \n - Commenting out the calls to
WiFi.mode()in the destructors, brings back the flash size to 300+KB \n
Now with that said:
\n- \n
- There is no real scenario, where you will include the WiFi library, but never use it. If you will use only ETH/PPP, then include
Network.hinstead. \n - Any use of the WiFi library will inevitably call
WiFi.mode()which will link to all those things anyway and bring the size back to the same amount. \n
With all of the above, I conclude that this is not a real world issue. Yes, the WiFi stack has increased in size in ESP-IDF, but we have no control over that.
","upvoteCount":1,"url":"https://github.com/espressif/arduino-esp32/discussions/11274#discussioncomment-12932553"}}}
-
BoardESP32 Dev Module Device DescriptionNo other board. Just ESP32 Dev Module, Hardware ConfigurationNone Versionlatest stable Release (if not listed below) IDE NameArduino IDE 2.3.5 Operating SystemWindows 11 Flash frequency80 Mhz PSRAM enabledno Upload speed115200 DescriptionI was trying to upgrade an existing ESP32 Program but even with all program options disabled the program size was 90%. I decided to write a minimal program and report the program size for different ESP32 Core, from 2.0.13 to 3.2.0 Arduino IDE 2.3.5 ESP32 Core 2.0.13 ESP32 Core 2.0.17 ESP32 Core 3.0.0 ESP32 Core 3.1.3 ESP32 Core 3.2.0 My Question then is I can no longer program the esp32 boards with the application (Weather station) because the program size is now (using Core 3.2.0) in excess of 100%. Is there something I am missing here or perhaps not understanding the huge jump in program size from 2.x to 3.x of the ESP32 Core versions? Any suggestions most welcome. regards Sketch//nullprog.ino
#include <Arduino.h>
#include <WiFiServer.h>
#include <WiFiClient.h>
#include <ArduinoJson.h>
#include "SPIFFS.h"
#include <WiFi.h>
#include <Math.h>
#include <Wire.h>
void setup() {}
void loop() {}Debug MessageOther Steps to ReproduceNo, just run the nullprog.ino I have checked existing issues, online documentation and the Troubleshooting Guide
|
Beta Was this translation helpful? Give feedback.
Replies: 4 comments 4 replies
-
|
You can resize the partitions by allocating more space for app0 and app1 by reducing SPIFFS. For example app 1408 Spiffs 828: otadata, data, ota, 0xe000, 0x2000, app0, app, ota_0, 0x10000, 0x160000, app1, app, ota_1, 0x170000,0x160000, spiffs, data, spiffs, 0x330000,0xD0000,` I myself do not really understand why the idf kernel has grown so much in size. The second surprise for you will be the use of RAM. Personally, I will have to switch to esp32 with a larger memory size of 8-16 MB. But the fact that there is little RAM left threatens the use of esp32 at all. Something simple is still possible, but multifunctional devices with the current psram policy have already reached 60 KB and less free for me. Which no longer allows using https. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for your comment. I appreciate the response and your thoughts. Yes, I know about partitions and heap size and all about that and SPIFFS etc. I have been using esp32 for a number of years now (as well as esp8266 before that). The partition scheme really does not help here, as the project also uses OTA updates. As the project is now stable and been in place for some time, partioning was explored and changed over time to where it is today. Been there, done that, took home the medal so to speak. RAM is not an issue for me. But code space is. The problem is if all the project options are enabled, the resultant code space significantly exceeds 100%. With just 1 option enabled, a web server, program space is 90%. To be honest, none of it addresses the concern I expressed, let alone explain why the increase. I also feel that moving to a discussion could be interpreted as a "its not a real convern - live it - all your fault - write better code". I come back to the fact the the explosion of program space used by core now renders my solutions totally worthless if moving to the latest core version. The project was often referred to as an esp32 killer app. Now its progably gonna be referred to the app that esp32 core killed. Just my thoughts. Not blaming anyone. Regards |
Beta Was this translation helpful? Give feedback.
-
|
I partly understood that yes, this is our problem and we have to live with it. I moved to version 3.x.x only because of Matter, I still keep my main version on the distant 1.0.2 just because of memory issues. Now I decided to switch to ESP32 with 8-16 MB of PSRAM, because in addition to the web server, web client, websocket server and client, I need to implement Matter support. I also wrote for the 8266, there was still plenty of space there, and strangely enough, RAM was enough. I haven’t written off the 8266 yet. Good luck to you!!! |
Beta Was this translation helpful? Give feedback.
-
|
I dug deep into this and here is my conclusion:
Now with that said:
With all of the above, I conclude that this is not a real world issue. Yes, the WiFi stack has increased in size in ESP-IDF, but we have no control over that. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you so much for your work!!! I suspected that the memory problem is in the IDF itself and does not depend on porting for Arduino. If you have the opportunity, please consider more aggressive use of PSRAM in Arduino’s menuconfig settings. With the current default settings, PSRAM is used by the system in rare cases. |
Beta Was this translation helpful? Give feedback.
-
|
me-no-dev I have observed the same issues with other available partiton schemes. The majority of those suffer from the same spave issues. It is increasingly looking like the only real solution (apart from moving away from ESP32) is to use a custom partition definition. Because this increase affects all the available partition spaces, perhaps it might be prudent to look at existing partition definitions and modify them to hold a larger size of program space, considering the IDF changes increased program space from 19% (old IDF) to 63% (new IDF)? My concern (apart from the projects) is that new users moving to the ESP32 could encounter these same issues and be deterred from using ESP32 in their projects because program space can now be easily become a major issue for them (and apart from the frustration that also brings) Regards |
Beta Was this translation helpful? Give feedback.
-
|
There are plenty of partition options. For example "no-fs" gives you almost 2MB APP partition. If we are to modify current partitions, this will cause other issues, especially with partitions that have file systems. The result will be that FS will no longer mount, it will need to be re-formatted and data will be lost. |
Beta Was this translation helpful? Give feedback.
-
|
ThanksI expected as much. I can only say that prior - I had everything fitting within the space under prior's esp32 arduino core. OTA, SPIFFS, code, everything.
Now I have nothing, as nothing fits anymore. My code is unaltered, The only different is the core code went from 19% to well over 64% an increase of about 300%
I have all ready tried custom partitions. Its the core size space which prevents me from coming up with viable solutions. I tried to find esp32 dev module 8MB flash but could find none searching on various sites (ebay, aliexpress, google search etc). That would have been a viable solution, basically replacing the chip would have been an upgrade path.
Please consider this closed. I appreciate your time and feedback. Yesterday I started to move to a different platform, as that now appears my only path. Current users can either stay with the older core etc, but cannot update.
Once again, I thank you for all your feedback, and fully understand that this is outside the control of the team.
RegardsRobert
On Friday, May 2, 2025 at 11:08:12 PM GMT+12, Me No Dev ***@***.***> wrote:
There are plenty of partition options. For example "no-fs" gives you almost 2MB APP partition. If we are to modify current partitions, this will cause other issues, especially with partitions that have file systems. The result will be that FS will no longer mount, it will need to be re-formatted and data will be lost.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
I dug deep into this and here is my conclusion:
WiFiobjectWiFi.mode()internally, which in turn links to all low level WiFi and Netif init/deinit methodsWiFi.mode()in the destructors, brings back the flash size to 300+KBNow with that said:
Network.hinstead.