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