[Ovmsdev] IRAM usage (was Re: 3.1.006)
Mark Webb-Johnson
mark at webb-johnson.net
Mon May 28 09:09:02 HKT 2018
I can’t read your .ods attachment, but here is what I get:
$ make size-components
Total sizes:
DRAM .data size: 18748 bytes
DRAM .bss size: 42456 bytes
Used static DRAM: 61204 bytes ( 53996 available, 53.1% used)
Used static IRAM: 131000 bytes ( 72 available, 99.9% used)
Flash code: 1909566 bytes
Flash rodata: 791724 bytes
Total image size:~2851038 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 599 341306 147939 494319
libovms_webserver.a 0 185 0 99722 219428 319335
libstdc++.a 149 5640 0 119785 70474 196048
libduktape.a 0 0 0 120709 55997 176706
liblwip.a 19 3992 0 141697 19853 165561
libc-psram-workaround.a 1988 66 18361 111481 9316 141212
libvehicle_renaulttwizy. 0 10 0 90328 40188 130526
libnet80211.a 1977 8892 3322 97052 10288 121531
libmain.a 7 1177 0 93298 24608 119090
libesp32.a 2725 485 18932 24982 29492 76616
libwolfssl.a 0 16 0 57399 16504 73919
libpp.a 855 6339 13019 40872 7311 68396
libdriver.a 111 214 3253 37267 25758 66603
libbtdm_app.a 347 4629 15135 30068 2872 53051
libmongoose.a 16 221 0 36567 8803 45607
libvehicle_kiasoulev.a 0 1 0 31588 6762 38351
libovms_server_v2.a 0 14 0 31981 4541 36536
libphy.a 1334 868 4572 29060 0 35834
libmdns.a 0 1865 0 26947 370 29182
libsimcom.a 0 1 0 18537 6773 25311
libfreertos.a 4156 776 18116 0 2092 25140
libwpa.a 0 682 0 20266 2304 23252
libfatfs.a 12 47 0 20023 3036 23118
libwolfssh.a 0 12 0 19516 2446 21974
libvehicle.a 0 52 0 16196 5624 21872
libm-psram-workaround.a 4 0 0 19196 697 19897
libesp32wifi.a 0 1 0 13807 4949 18757
libcanopen.a 0 24 0 13437 5260 18721
libspinodma.a 0 12 6842 5593 5072 17519
libcan.a 0 36 0 13175 3482 16693
libconsole_ssh.a 2 8 0 12770 3704 16484
libovms_ota.a 0 8 0 9407 5594 15009
libnvs_flash.a 0 32 0 10763 2625 13420
libretools.a 12 6 0 10184 2291 12493
libgcc.a 4 20 104 10670 888 11686
libspi_flash.a 36 323 7188 1626 1866 11039
libesp32bluetooth.a 44 274 0 5886 4746 10950
libobd2ecu.a 0 1 0 8603 2197 10801
libheap.a 1205 8 5325 2424 976 9938
libovms_server_v3.a 0 13 0 8043 1836 9892
libwpa_supplicant.a 0 0 0 9812 4 9816
libvfsedit.a 924 0 0 6983 1751 9658
libsoc.a 657 8 7010 0 1247 8922
libsdmmc.a 0 0 0 5855 2667 8522
libvehicle_teslaroadster 0 1 0 7010 1486 8497
libwear_levelling.a 0 68 0 5917 1477 7462
libvehicle_nissanleaf.a 8 85 0 5893 1391 7377
libovms_location.a 4 36 0 5838 563 6441
libsdcard.a 0 9 16 3549 1369 4943
libcoexist.a 1277 94 3332 0 137 4840
libcrypto.a 0 64 0 3998 167 4229
libvehicle_voltampera.a 0 1 0 3041 1159 4201
libmbedtls.a 0 0 0 3677 320 3997
libvehicle_demo.a 0 1 0 3352 526 3879
libbootloader_support.a 0 4 0 2308 1424 3736
libtcpip_adapter.a 0 124 0 3220 306 3650
libvfs.a 40 63 0 3060 395 3558
libmicrorl.a 4 0 0 2896 576 3476
libpcp.a 0 56 0 3050 286 3392
libapp_update.a 0 80 0 2184 785 3049
librtc.a 0 4 2777 0 0 2781
libnewlib.a 152 252 806 611 133 1954
libpthread.a 16 12 178 1090 650 1946
libmcp2515.a 0 0 0 1526 317 1843
libvehicle_teslamodels.a 0 1 0 1276 519 1796
libesp32can.a 0 4 0 1725 52 1781
libovms_mdns.a 0 8 0 1495 213 1716
liblog.a 8 268 478 810 16 1580
libvehicle_obdii.a 0 1 0 782 647 1430
libcxx.a 12 16 0 751 453 1232
libcore.a 0 5 0 753 398 1156
libmax7317.a 0 1 0 444 470 915
libvehicle_none.a 0 1 0 261 489 751
libvehicle_track.a 0 1 0 261 482 744
libhal.a 0 0 515 0 32 547
libext12v.a 0 0 0 282 141 423
libovms_server.a 0 1 0 188 125 314
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
OVMS# module memory
Free 8-bit 82928/229892, 32-bit 32/36, SPIRAM 4079896/4194252
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 at 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 at 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 at 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 at lists.openvehicles.com
>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>>>
>>>>
>>> _______________________________________________
>>> OvmsDev mailing list
>>> OvmsDev at 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 at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20180528/f030558f/attachment-0001.html>
More information about the OvmsDev
mailing list