ESP32 Huge jump in Program Size for minimal program

[brownrb]

Board

ESP32 Dev Module

Device Description

No other board. Just ESP32 Dev Module,

Hardware Configuration

None

Version

latest stable Release (if not listed below)

IDE Name

Arduino IDE 2.3.5

Operating System

Windows 11

Flash frequency

80 Mhz

PSRAM enabled

no

Upload speed

115200

Description

I 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
Here are the results

---

Arduino IDE 2.3.5
ESP32 Dev Module
nullprog.ino as shown in next section

ESP32 Core 2.0.13
Sketch uses 257465 bytes (19%) of program storage space.
Global variables use 21432 bytes (6%) of dynamic memory

ESP32 Core 2.0.17
Sketch uses 258113 bytes (19%) of program storage space.
Global variables use 21432 bytes (6%) of dynamic memory

ESP32 Core 3.0.0
Sketch uses 889873 bytes (67%) of program storage space.
Global variables use 40724 bytes (12%) of dynamic memory,

ESP32 Core 3.1.3
Sketch uses 903108 bytes (68%) of program storage space.
Global variables use 44724 bytes (13%) of dynamic memory

ESP32 Core 3.2.0
Sketch uses 905882 bytes (69%) of program storage space.
Global variables use 46304 bytes (14%) of dynamic memory

My Question then is
Why the huge jump in program size from ESP32 Core 2.0.13 to Core 3.2.0
19% Program space to 69% program space,

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
Robert

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 Message

None, comparing output program size for different Core versions

Other Steps to Reproduce

No, just run the nullprog.ino
test results speak for themselves

I have checked existing issues, online documentation and the Troubleshooting Guide

• I confirm I have checked existing issues, online documentation and Troubleshooting guide.

[ValdayMl]

You can resize the partitions by allocating more space for app0 and app1 by reducing SPIFFS. For example app 1408 Spiffs 828:
`# Name, Type, SubType, Offset, Size, Flags
nvs, data, nvs, 0x9000, 0x5000,

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.

[brownrb]

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
Robert

[ValdayMl]

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!!!