ESP32-C3: Significant wireless library size increase between 5.2.1 and 5.2.2 (IDFGH-13157)

[rojer]

Answers checklist.

• [X] I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
• [X] I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
• [X] I have searched the issue tracker for a similar issue and not found a similar issue.

General issue report

Simply recompiling a ESP32-C3 project with IDF 5.2.2 instead of 5.2.1 results in a gain of 14 KB binary size. I am attaching a size diff report here (diff_esp32c3.txt) for the same app compiled for 5.2.2 with reference to 5.2.1 - and it shows flash gains all over the wireless stack, the largest being in something called vshci_task.o.

This is significant, because it pushes us over the flash envelope for some of our targets, effectively precluding us form updating IDF. A supposedly bugfix-only release (according to semantic versioning) results in significant gain in binary size. Is there any recourse for us? Is there something we can do to disable the new functionality (if there was any added)?

[rojer]

I should add that 5.2.2 provided significant and very welcome reduction in resulting binary size for ESP32 (which is why i'm verya eager to adopt it, actually). This makes C3 increase all the more surprising. ESP32 diff: diff_esp32.txt - this is very nice, can we have the same for C3? pretty please? :)

[Weijian-Espressif]

@rojer Thank you for reporting this issue and I will get back to you as soon as possible

[Weijian-Espressif]

@rojer

It is exactly as you described, there are two reasons for this:

1. bug fix consumes part of IRAM
2. Added some features that consume flash size

For problem 2, we will propose MR Repair as soon as possible. Meanwhile, I can provide you with a patch first. Please help provide you with IDF commit, thank you.

[rojer]

@Weijian-Espressif thjanks for the response but i'm not sure what you're asking for?

[rojer]

I am updating from 5.2.2 to 5.4.1 and again BLE library is adding bloat: our app simply recompiled added 40K on C3, 60K on C6, 16K on xtensa. it looks like more functions are implemented in flash now rather than in ROM. I guess some of it is inevitable, but definitely not all.

It's not all bad: I noticed a very interesting change CONFIG_BT_CTRL_RUN_IN_FLASH_ONLY added in https://github.com/espressif/esp-idf/commit/2a05eb8fd3971a8816cce853912b1cf46ca30eef . It goes the opposite direction - uses more flash and frees up RAM (which will be useful on our less space-constrained targets). But one other thing it does is segregate controller functions by features, in particular isolating test and BLE5.0 features (which we don't use).

So, after some experimentation i made a change that stubs out some unused functions even when CONFIG_BT_CTRL_RUN_IN_FLASH_ONLY is disabled, and it seems to work: https://github.com/rojer/esp-idf/pull/1/files

It saves 17K of flash compared from the initial 40K bump which is a significant amount for our space-constrained targets and our app seems to work without crashing with and without CONFIG_BT_CTRL_RUN_IN_FLASH_ONLY. But obviously i don't have insight into the binaries, so I don't know all the implications.

@Weijian-Espressif can you please check if something like this can be done officially? It would be really nice.

@igrr for visibility, as we discussed this problem (blob size creep) at EW.

[Weijian-Espressif]

We are trying to modify the code to reduce bin size and IRAM consumption, which may take a little time, we need to do a lot of testing, compatible with different chip versions. Although your changes can run, but not sure if it will introduce other problems, we recommend that you use our published code

[rojer]

@Weijian-Espressif if open-sourcing BT libs is not an option, then perhaps providing builds with certain features disabled would help space-constrained builds such as ours. important features that can be disabled are BLE 5.0 and Connection support (for devices that only advertise and/or scan). So, a device with conenction and BLE5 support disabled should have significantly smaller RAM and flash footprint. Maybe providing different sets of binary libs is the answer, or making sure that unused functions get pruned. A post-link stub-out tables like you did for CONFIG_BT_CTRL_RUN_IN_FLASH_ONLY is also an interesting idea worth elaborating.

Anyway, your work in this regard is will be very much appreciated - by us and our users :) If you need help testing any changes, please let me know.

[rojer]

and this happened again between 5.4.1 and 5.4.2: 20K of code added, mostly in some wireless parts. why?

[Weijian-Espressif]

Are there any detailed data? Do you mean the addition of the Bluetooth module?

[Weijian-Espressif]

v5.4.1 v5.4.2

Bluetooth only added about 2k of flash

[rojer]

@Weijian-Espressif i built an app with 5.4.1 and 5.4.2, no other changes:

    App size: 2003984 of 2621440 (76%)
    App size: 2018288 of 2621440 (76%)

there are significant size diifference in various wifi/bt related symbols: r_lld_*, r_llc_*, r_rf_*. i have no visibility into the blobs, but lots of churn in wireless-related functions and the result is +15K

i'm attaching output of my tool, it lists symbol additions, removal and size changes.

BluGwG3_5.4.1_5.4.2_diff.txt

[Weijian-Espressif]

Please use idf.py size-components to view the information of the two versions of the Bluetooth module and send me the screenshots. Thank you.

[Weijian-Espressif]

By the way, Bluetooth currently offers a flash version and a ROM version. The flash version moves all Bluetooth code from the ROM to the flash. Its advantage is that the IRAM consumption is significantly reduced, but the bin size increases considerably. If you compare the flash version with the ROM version, there will definitely be a big difference, which is also as expected.