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