It seems that the three biggest are SPIRAM, Wifi, Bluetooth. That and the entire freertos api being in iram. Disabling sub-components we don’t use may help.

I think we have some opportunity to tune this. For example, spi_master_nodma is using 6842 bytes of IRAM (and I think the majority of that is not required - or we can try to get rid of that and just switch back to the normal dma based esp32 spi library).

I tried a very rough disabling/tuning some things, and got this:

$ make size-components

Total sizes:

DRAM .data size: 18008 bytes

DRAM .bss size: 42384 bytes

Used static DRAM: 60392 bytes ( 54808 available, 52.4% used)

Used static IRAM: 119508 bytes ( 11564 available, 91.2% used)

Flash code: 1633934 bytes

Flash rodata: 740056 bytes

Total image size:~2511506 bytes (.bin may be padded larger)

Per-archive contributions to ELF file:

Archive File DRAM .data & .bss IRAM Flash code & rodata Total

libbt.a 521 3954 542 307054 141815 453886

libovms_webserver.a 0 185 0 53102 218036 271323

libstdc++.a 149 5640 0 121351 70409 197549

libduktape.a 0 0 0 120301 56061 176362

liblwip.a 19 3992 0 121557 18181 143749

libc-psram-workaround.a 1988 66 18361 111005 9283 140703

libnet80211.a 1977 8892 3322 97053 10358 121602

libvehicle_renaulttwizy. 0 10 0 56564 38599 95173

libmain.a 7 1177 0 69798 22656 93638

libpp.a 855 6339 13019 40848 7311 68372

libwolfssl.a 0 16 0 51488 15797 67301

libbtdm_app.a 347 4629 15135 30200 2848 53159

libesp32.a 1936 485 14396 13092 15591 45500

libdriver.a 111 214 2811 25454 13732 42322

libmongoose.a 16 221 0 33204 8145 41586

libphy.a 1334 868 4568 29048 0 35818

libvehicle_kiasoulev.a 0 1 0 21612 6446 28059

libwpa.a 0 682 0 20266 2320 23268

libfreertos.a 4156 776 15731 0 2031 22694

libovms_server_v2.a 0 14 0 18129 4224 22367

libmdns.a 0 1865 0 19772 337 21974

libfatfs.a 12 47 0 18123 2973 21155

libm-psram-workaround.a 4 0 0 19188 698 19890

libsimcom.a 0 1 0 13380 6443 19824

libwolfssh.a 0 12 0 17089 1929 19030

libcanopen.a 0 24 0 12095 4470 16589

libcan.a 0 36 0 10637 4621 15294

libvehicle.a 0 52 0 9853 5113 15018

libesp32wifi.a 0 1 0 9707 4625 14333

libconsole_ssh.a 2 8 0 9286 3382 12678

libspinodma.a 0 12 5850 4146 2590 12598

libovms_ota.a 0 8 0 6511 5421 11940

libgcc.a 4 20 104 10682 888 11698

libnvs_flash.a 0 32 0 8656 2716 11404

libesp32bluetooth.a 44 274 0 5584 4573 10475

libretools.a 12 6 0 8285 2134 10437

libvfsedit.a 924 0 0 7055 1873 9852

libwpa_supplicant.a 0 0 0 9577 4 9581

libspi_flash.a 36 323 5998 1477 1073 8907

libheap.a 1160 8 4179 2070 940 8357

libsoc.a 774 8 6310 0 1210 8302

libobd2ecu.a 0 1 0 5993 1681 7675

libsdmmc.a 0 0 0 4888 2504 7392

libvehicle_teslaroadster 0 1 0 6069 996 7066

libovms_server_v3.a 0 13 0 5108 1762 6883

libvehicle_nissanleaf.a 8 85 0 4676 1312 6081

libwear_levelling.a 0 68 0 4665 1312 6045

libcoexist.a 1277 94 3332 0 142 4845

libovms_location.a 4 36 0 4049 541 4630

libcrypto.a 0 64 0 4006 167 4237

libsdcard.a 0 9 16 2783 1289 4097

libvehicle_voltampera.a 0 1 0 2592 1140 3733

libmbedtls.a 0 0 0 3326 320 3646

libmicrorl.a 4 0 0 2864 583 3451

libvfs.a 40 63 0 2923 381 3407

libvehicle_demo.a 0 1 0 2708 527 3236

libtcpip_adapter.a 0 124 0 2705 300 3129

libbootloader_support.a 0 4 0 1941 1171 3116

librtc.a 0 4 2777 0 0 2781

libapp_update.a 0 80 0 1860 770 2710

libpcp.a 0 56 0 2313 286 2655

libnewlib.a 152 252 802 616 85 1907

libmcp2515.a 0 0 0 1592 314 1906

libpthread.a 16 12 176 957 637 1798

libvehicle_teslamodels.a 0 1 0 1253 509 1763

libesp32can.a 0 4 0 1659 52 1715

libvehicle_obdii.a 0 1 0 909 639 1549

liblog.a 8 268 442 709 14 1441

libovms_mdns.a 0 8 0 1036 189 1233

libcore.a 0 5 0 753 402 1160

libcxx.a 12 16 0 684 443 1155

libvehicle_track.a 0 1 0 409 476 886

libvehicle_none.a 0 1 0 401 480 882

libmax7317.a 0 1 0 385 459 845

libhal.a 0 0 515 0 32 547

libext12v.a 0 0 0 350 140 490

libovms_server.a 0 1 0 156 124 281

libstrverscmp.a 0 0 0 212 48 260

libesp32adc.a 0 0 0 112 20 132

libesp32system.a 0 0 0 96 20 116

libwpa2.a 0 1 0 0 0 1

libwps.a 0 1 0 0 0 1

libethernet.a 0 0 0 0 0 0

We get a substantial improvement by simply using:

-CONFIG_OPTIMIZATION_LEVEL_DEBUG=y

-CONFIG_OPTIMIZATION_LEVEL_RELEASE=

+CONFIG_OPTIMIZATION_LEVEL_DEBUG=

+CONFIG_OPTIMIZATION_LEVEL_RELEASE=y

(which is the compiler options / optimisation level from debug -> release)

I think at this stage going through and disabling what we don’t need, down to the sub-component level, may free up enough. For release builds, we don’t really need DEBUG code, and can turn on the release optimisations in gcc. That, and other reductions, should give us enough breathing room.

Regards, Mark.

On 28 May 2018, at 2:12 AM, Michael Balzer <dexter@expeedo.de> wrote:

After adding a missing newlib module (just code) I got this:

xtensa-esp32-elf/bin/ld: region `iram0_0_seg' overflowed by 712 bytes

I've now done a little analysis using the idf_size.py tool, results attached.

As you can see, the esp-idf puts lots of components into IRAM, including parts of libc ("libc-psram-workaround").

Without bluetooth and with the old version it's already been using 105636 bytes IRAM, the new version had quite some growth on this (marked in red), and the
bluetooth (blue) components add another 15 KB, total is now 129880 bytes.

Effectively there is now no IRAM space left (of the linker section) after enabling bluetooth.

I guess my newlib module drew in some libc functions, as the libc segment grew beyond acceptable size.

I don't think we will be able to continue providing a single firmware covering all features. Maybe we'll need to split into a wifi and a bluetooth release, I
think those are the only optional components for us.

Regards,
Michael

Am 23.05.2018 um 00:14 schrieb Michael Balzer:
Steve,

yes, at build time, I suppose the static IRAM preallocations from the bluetooth and wifi improvements have grown too much to fit:

/home/balzer/esp/xtensa-esp32-elf/bin/../lib/gcc/xtensa-esp32-elf/5.2.0/../../../../xtensa-esp32-elf/bin/ld:
/home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/ovms3.elf section `.iram0.text' will not fit in region `iram0_0_seg'
/home/balzer/esp/xtensa-esp32-elf/bin/../lib/gcc/xtensa-esp32-elf/5.2.0/../../../../xtensa-esp32-elf/bin/ld: region `iram0_0_seg' overflowed by 940 bytes

This is my currently running build:

balzer@leela:~/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3> ~/esp/esp-idf/tools/idf_size.py build/ovms3.map
Total sizes:
DRAM .data size:   18760 bytes
DRAM .bss size:   42440 bytes
Used static DRAM:   61200 bytes ( 54000 available, 53.1% used)
Used static IRAM: 131000 bytes (     72 available, 99.9% used)
      Flash code: 1908902 bytes
    Flash rodata: 791536 bytes
Total image size:~2850198 bytes (.bin may be padded larger)

So that's also quite close already.

Regards,
Michael

Am 22.05.2018 um 23:50 schrieb Stephen Casner:
Michael,

Can you clarify regarding the IRAM space issues. Was there an error
at build time? If so, that's a surprise because I don't think our
code does anything with preallocation of IRAM so that means everyone
who uses a similar set of system functions would hit this.

My memory diagnostic code allocates from IRAM if available, but only
if the memory commands are issued, so any system allocations in IRAM
should come first.

                                                       -- Steve

On Tue, 22 May 2018, Michael Balzer wrote:

I've pushed the updated esp-idf status to our clone now, so we can start using that for release 007.

I've also checked the upstream master status again, which is already quite some commits ahead, including lots of wifi and bluetooth updates.

Unfortunately I got IRAM space issues and had to disable bluetooth to be able to build at all. The resulting firmware crashed immediately on wifi power up with
error code 0x102 and a message that we should use WIFI_INIT_CONFIG_DEFAULT. Which we do, I don't see anything wrong in our init code. So I switched back to the
working version for now.

To use the new esp-idf version all you need to do is a pull from our repository and a git submodule update. The xtensa tools are still the same.

Regards,
Michael

Am 17.05.2018 um 10:41 schrieb Michael Balzer:
Regarding the esp-idf update: it works without (new) issues and seems to improve stability a bit, but not as much as I was hoping.

So it's an option, but not a priority for 006.

Regards,
Michael

Am 17.05.2018 um 05:06 schrieb Mark Webb-Johnson:
Deadline for the factory firmware is this weekend. The modules have all been built and are waiting sim cards, firmware flash, then final QC.

So, I suggest we freeze things as they are. I will double-check the wifi setup tonight (it seemed ok last time I checked, so hopefully good now). Build will not include the bluetooth code I am working on (that is disabled in our default sdkconfig anyway).

Is there anything else holding this up? Or anything anybody wants to rush in?

Regards, Mark.

_______________________________________________
OvmsDev mailing list
OvmsDev@lists.openvehicles.com
http://lists.openvehicles.com/mailman/listinfo/ovmsdev
--
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

_______________________________________________
OvmsDev mailing list
OvmsDev@lists.openvehicles.com
http://lists.openvehicles.com/mailman/listinfo/ovmsdev

_______________________________________________
OvmsDev mailing list
OvmsDev@lists.openvehicles.com
http://lists.openvehicles.com/mailman/listinfo/ovmsdev

--
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

<iram-usage.ods>_______________________________________________
OvmsDev mailing list
OvmsDev@lists.openvehicles.com
http://lists.openvehicles.com/mailman/listinfo/ovmsdev