search

espressif / ESP8266_NONOS_SDK

ESP8266 nonOS SDK
Other
926 stars 536 forks source link

Out of RAM #45

Open scargill opened 7 years ago

scargill commented 7 years ago

Something you've done in the last mod.... once again I find myself out of RAM and despite clawing back quite a bit by checking my code - I STILL get this message beyond SDK 2.0 -

c:/espressif/xtensa-lx106-elf/bin/../lib/gcc/xtensa-lx106-elf/4.8.2/../../../../xtensa-lx106-elf/bin/ld.exe: build/app_0.out section .text' will not fit in regioniram1_0_seg' collect2.exe: error: ld returned 1 exit status mingw32-make.exe: *** [build/app_0.out] Error 1

Previous version I had enough to keep going for a while.. and yes all functions are in Flash.... very disappointing.

davydnorris commented 7 years ago

Pete @scargill have you checked the library functions in any esp_open_sdk built libs? I assume you are using the Open SDK tools - libc and libgcc get built with a whole heap of functions that are actually in ROM. I created a script to strip these and it's now part of the distro here.

I had same problem as you till I stripped out the ROM based functions and I got a fair bit back

scargill commented 7 years ago

Hi @davydnorris - you could be my saviour - but treat me gently - I am using ESP8266_NONOS_SDK just around 2.0 - around 2.1 it all started to run out of RAM. I mean - I'm running on 2.0 but can't move forwards.. Would you like to explain that SLOWLY.... when you say the "distro here" - I'm lost.. here is where I got my normal SDK from... the one I'm having trouble with on 2.1+

If this gets boring for others could you email me pete at scargill dot org? I REALLY would like to get some program RAM back as I've about 200 bytes left. I've never used anything OTHER than the standard Espressif SDK.....

So - can you point me to the distro you're referring to - and would I need to make code changes?? And is it documented what's already in ROM? This is exciting...

davydnorris commented 7 years ago

@scargill - sent you email mate

scargill commented 7 years ago

Thanks Davy - and I have SDK 2.1 and realise that the README file refers to the two library files and gives instructions as to how to modify them.

Sadly - despite being able at times to work miracles in C, my knowledge of MAKEFILES is so poor that I simply cannot figure out where to put the code suggested - https://www.dropbox.com/s/ooaw7i2cyg3fojz/Makefile.txt?dl=0

My makefile is shown above - I can't actually include it in here (and yes, I added the .txt). It has no reference to TOOLCHAIN in it and I don't know whereabouts in the makefile to put those mods. So near, yet so far. If you ARE able to offer advice on that I would really appreciate it - but also appreciate if that is too much hassle - in which case can anyone who is well familiar with Makefiles help? This makefile originated in the unofficial toolkit for Windows and has been modified by Richard Burton and others over time - I've managed only the simplest changes.

kriegste commented 7 years ago

The libs included in this SDK are already stripped. You won't gain more RAM through this step.

There are more things you can do. Did you

define USE_OPTIMIZE_PRINTF

? Do you use more (constant) strings or arrays in your project?

davydnorris commented 7 years ago

I've been in contact with Pete and he's got several copies of the built libs in his toolchain - depending on his path he may be using unstripped libs. I'm going to strip them for him to eliminate that possibility

scargill commented 7 years ago

Hi there

I added that 'define - in a header that pretty much all my pages include... made no difference - or at least, the compilation still failed for the same reason. I tried with 2.0 and having it there or not made no difference (possibly defined elsewhere).

I have this defined

            #ifndef IFA

define IFA ICACHE_FLASH_ATTR attribute((aligned(4)))

endif

ifndef IRA

define IRA ICACHE_RODATA_ATTR attribute((aligned(4)))

endif

and use IFA on all functions - and IRA on all arrays and as many strings as possible.

Re the latter, I thought this was a different area of RAM anyway??? I do have a few regular strings...

------ Original Message ------ From: "kriegste" notifications@github.com To: "espressif/ESP8266_NONOS_SDK" ESP8266_NONOS_SDK@noreply.github.com Cc: "Peter Scargill" pete@scargill.org; "Mention" mention@noreply.github.com Sent: 25/10/2017 10:28:14 Subject: Re: [espressif/ESP8266_NONOS_SDK] Out of RAM (#45)

The libs included in this SDK are already stripped. You won't gain more RAM through this step.

There are more things you can do. Did you

define USE_OPTIMIZE_PRINTF

? Do you use more (constant) strings or arrays in your project?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/espressif/ESP8266_NONOS_SDK/issues/45#issuecomment-339270928, or mute the thread https://github.com/notifications/unsubscribe-auth/ABzUg_T3KpgHv5zgjbHwAawqly4zaZNHks5svv8ugaJpZM4P73NA.

kriegste commented 7 years ago

Test it. If you introduce a new line os_printf("THIS IS A TESTTEXT, ONE TWO THREE, TEST"); you should see your flash decreasing, but not your RAM.

kriegste commented 7 years ago

Oh, to be able to compare, you should display the RAM usage in line 1 (or most early) in user_init(). This way no dynamically allocated RAM is interfering. It should display the same value on every start unless you change your code. But then you can see what happened.

scargill commented 7 years ago

For printing stuff.. I use this

    void IFA iprintf(uint16_t debug_type, char *fmt, ... ){

char buf[128]; // resulting string limited to 127 chars - change it if you like va_list args; va_start (args, fmt); ets_vsnprintf(buf, sizeof(buf), fmt, args); va_end (args); if (debug_type & enable_debug_messages) uart0_tx_buffer(buf,os_strlen(buf));

}

and changing the size of messages makes no difference at all to the remaining _TEXT area... indeed .rodata increases as you suggest.

------ Original Message ------ From: "kriegste" notifications@github.com To: "espressif/ESP8266_NONOS_SDK" ESP8266_NONOS_SDK@noreply.github.com Cc: "Peter Scargill" pete@scargill.org; "Mention" mention@noreply.github.com Sent: 25/10/2017 10:55:54 Subject: Re: [espressif/ESP8266_NONOS_SDK] Out of RAM (#45)

Test it. If you introduce a new line os_printf("THIS IS A TESTTEXT, ONE TWO THREE, TEST"); you should see your flash decreasing, but not your RAM.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/espressif/ESP8266_NONOS_SDK/issues/45#issuecomment-339278234, or mute the thread https://github.com/notifications/unsubscribe-auth/ABzUg-kDjBgE7TKGNt6AkHfbQ_v9pzXzks5svwWpgaJpZM4P73NA.

kriegste commented 7 years ago

Do you have other strings? Strings you don't feed into your iprintf function? Or const arrays?

Edit: Oh, I overlooked this answer of yours. Well, if they are indeed ICACHE_RODATA_ATTR I doubt there can be done much...

Do you use things like char buf[128] often? Maybe allocating dynamically would be an option?

scargill commented 7 years ago

So nearly all strings go into iprintf..... and changing the size of those has no effect...

const arrays - I use this with any but the tiniest.. ICACHE_RODATA_ATTR attribute((aligned(4)))

I tried reducing a couple which go off to MQTT - made no difference to .TEXT size at all.

The BIGGEST difference was trying libcirom.a - and that reduced me from 7cd4 .TEXT to 7668 - in the 2.0 sdk - but even that failed to allow me to compile with the 2.1 SDK - which just simply says it can't fit everything in.

kriegste commented 7 years ago

Did you add -ffunction-sections -fdata-sections to the c flags in your Makefile and also -Wl,-gc-sections to the ld flags? This gives you more flash, but also a tiny amount of RAM.

kriegste commented 7 years ago

What are you doing with all that RAM anyway? Do you record data? Like temperatures? In that case an idea would be to record them directly to flash. Erase a page, then write in 32 bit chunks. Surplus: This way the data will even survive a power cycle.

scargill commented 7 years ago

No - all of that already done :-) my code for the ESP8266 handles MQTT communication and a wide variety of drivers. https://bitbucket.org/scargill/esp-mqtt-dev2

As I understand it, RAM used by text etc has nothing to do with the RAM used by programs. I've tried reducing strings and arrays and it makes absolutely no difference to the amount of RAM available for program code. I've plenty of heap space.... but by using that ROM-only version of the lib discussed higher up - I got a reasonable amount of .text space back - and yet - from version 2.0 to 2.1 - I run out every time. 2.0 is just fine.

davydnorris commented 7 years ago

Hey Pete @scargill - can you compile and drop out a full memory map?

Add -Wl,-print-map to your link options and let's see where everything is going

scargill commented 7 years ago

Working on that, davydnorris.

Here are the current flags - I cannot find any way to add -print-map without the compilation bombing.

LDFLAGS = -nostdlib -Wl, --no-check-sections -u Cache_Read_Enable_New, -u call_user_start -Wl,-static

kriegste commented 7 years ago

Or just add -Wl,-Map,foo.map to that line.

PS: Also try -Wl,-gc-sections like mentioned above.

scargill commented 7 years ago

Well, that worked though it looks weird to me... here it is...

foo.txt

davydnorris commented 7 years ago

Not sure why you couldn't get my option working but good you got the map out either way.

Couple of things this is showing:

Can you go through the process we went through last time and use the irom stripped versions of libc and libgcc, and compile with the dump once again?

scargill commented 7 years ago

Ok, so I'm doing this all on the previous SDK of course - the one that works for me... and the .TEXT info say I'm up to 00007cd4 - which doesn't leave a lot but for that SDK it is fine.

Making the change you suggest... the only one I know how to.. ie LIBS = c gcc hal phy pp net80211 lwip wpa pwm upgrade $(LIBMAIN) ssl crypto

changing c to cirom... changes the .text to... 00007668 and that is a significant improvement but STILL not enough to allow compilation with version 2.1 SDK..

Here's the file... if I've missed anything it is through lack of understanding... foo.txt

davydnorris commented 7 years ago

@scargill - send me via email the following: c:/espressif/xtensa-lx106-elf/lib\libcirom.a c:/Espressif/ESP8266_SDK/lib\libgcc.a

and I'll strip them and send back to you. Then rename the ones in the above locations and replace with the stripped versions, and we'll see if you crib any more.

davydnorris commented 7 years ago

Well this is interesting...

Your 2.0 libgcc has one of the multiplication routines still in it (_mulsf3.o), but the 2.1 version is clean. Won't make much of a difference but I've stripped out that function for you.

And the libcirom has eprintf still in it - I've stripped that too.

All in all I don't think it'll make a huge diff :-(

scargill commented 7 years ago

Got your email - will give it a go... and thank you!!

scargill commented 7 years ago

Hi there

Ok, so libcrom.a - when used in the working 2.0 SDK – instead of the original made ZERO difference to .TEXT size.

Overwriting the LIBGCC.A file reduced the .TEXT size from 7CXX when not using the rom version, through 766C when using the original ROM version – to 7508 using your version… however… if as you say, this is already shrunk in the 2.1 SDK then this change is welcome in 2.0 but not of use in 2.1

So overall for 2.1 there would be no change at all….

Good try though – much appreciated… if anyone has any other ideas I’d love to hear back.

Pete.

From: davydnorris [mailto:notifications@github.com] Sent: 01 November 2017 11:43 To: espressif/ESP8266_NONOS_SDK ESP8266_NONOS_SDK@noreply.github.com Cc: Peter Scargill pete@scargill.org; Mention mention@noreply.github.com Subject: Re: [espressif/ESP8266_NONOS_SDK] Out of RAM (#45)

Well this is interesting...

Your 2.0 libgcc has one of the multiplication routines still in it (_mulsf3.o), but the 2.1 version is clean. Won't make much of a difference but I've stripped out that function for you.

And the libcirom has eprintf still in it - I've stripped that too.

All in all I don't think it'll make a huge diff :-(

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/espressif/ESP8266_NONOS_SDK/issues/45#issuecomment-341084001 , or mute the thread https://github.com/notifications/unsubscribe-auth/ABzUgztqgP8a3cXjPrW6IEUdOd267Ge3ks5syFk-gaJpZM4P73NA . https://github.com/notifications/beacon/ABzUg_3nTQ3j1CU0iB9xppMaIHvpIyCoks5syFk-gaJpZM4P73NA.gif

scargill commented 7 years ago

All of which of course begs the question - what on EARTH were Espressif thinking of - in a processor already tight for program code RAM, bringing out an update that uses that much MORE RAM -and by what I'm seeing here, a LOT more of it - 7508 works on 2.0 - but not on 2.1 so they've used, what - at least 2.5K more ???

davydnorris commented 7 years ago

Can you build with both 2.0 and 2.1 with the memory map option set and save to separate files, then do a diff between the two files? That might give us an idea of where the key changes between SDK releases are affecting you.

scargill commented 7 years ago

foo20.txt foo21.txt

There is SO much more in the new map (renamed to .TEXT here) that I don't even know where to start...

kriegste commented 7 years ago

One big difference is this.

foo20.txt:

 .text          0x401068d0      0x493 c:/Espressif/ESP8266_SDK/lib\liblwip.a(espconn_buf.o)
                                0x50e (size before relaxing)
                0x401068d4                ringbuf_new
                0x40106924                ringbuf_buffer_size
                0x40106928                ringbuf_reset
                0x40106938                ringbuf_free
                0x40106978                ringbuf_capacity
                0x401069a8                ringbuf_bytes_free
                0x401069d8                ringbuf_bytes_used
                0x401069fc                ringbuf_is_full
                0x40106a14                ringbuf_is_empty
                0x40106a3c                ringbuf_tail
                0x40106a40                ringbuf_head
                0x40106aa0                ringbuf_findchr
                0x40106b40                ringbuf_memset
                0x40106c08                ringbuf_memcpy_into
                0x40106cc0                ringbuf_memcpy_from

foo21.txt:

 .irom0.text    0x4022e104      0x403 c:/Espressif/ESP8266_SDK/lib\liblwip.a(espconn_buf.o)
                                0x45b (size before relaxing)
                0x4022e150                ringbuf_new
                0x4022e1a0                ringbuf_buffer_size
                0x4022e1a4                ringbuf_reset
                0x4022e1b0                ringbuf_free
                0x4022e1f0                ringbuf_capacity
                0x4022e1f8                ringbuf_bytes_free
                0x4022e210                ringbuf_bytes_used
                0x4022e22c                ringbuf_is_full
                0x4022e244                ringbuf_is_empty
                0x4022e268                ringbuf_tail
                0x4022e26c                ringbuf_head
                0x4022e274                ringbuf_findchr
                0x4022e30c                ringbuf_memset
                0x4022e3bc                ringbuf_memcpy_into
                0x4022e464                ringbuf_memcpy_from

Edit: But this is actually positive (it is in .irom0.text in 2.1)...

kriegste commented 7 years ago

Is that the actual version 2.1 from May 5th or is this the master branch from here? If it is the current master branch, can you find out when the problem first occurred? There have been quite some commits since the actual version 2.1... https://github.com/espressif/ESP8266_NONOS_SDK/commits/master

scargill commented 7 years ago

The version of 2.1 was the master - at about a week ago. I can't get over how much bigger the map file is on 2.1 over 2.0 - right now this is a major pain for me - I've been developing this software for a long time, benefitting from each new version of the SDK - and now something they've done has made it impossible for me to go past 2.0

kriegste commented 7 years ago

One more idea: Check whether your link process is using the right (current) linker files: https://github.com/espressif/ESP8266_NONOS_SDK/tree/master/ld There have been changes to them, too. If I compile my project using the old ones, I get the same error message.

davydnorris commented 7 years ago

Actually that's a really good call @kriegste ! @scargill - do a search for eagle.app.*.ld files and make sure you're using the ones from the SDK. From memory, the particular toolchain build style you are using makes copies of these files, which may mean you're not using the right ones for the SDK.

scargill commented 7 years ago

One of those has changes.... now I'm getting into uneasy terrritory - the fellow who developed RBOOT had me make changes to those - I'll wait till I have a clear head in the morning - back everything up and have a go - somewhat encouraged to know that Kriegste had a similar issue... thanks for this guys...

kriegste commented 7 years ago

The important (new) lines are these:

[...]
  .irom0.text : ALIGN(4)
  {
    _irom0_text_start = ABSOLUTE(.);

    *libat.a:(.literal.* .text.*)
    *libcrypto.a:(.literal.* .text.*)
    *libespnow.a:(.literal.* .text.*)
    *libjson.a:(.literal.* .text.*)
    *liblwip.a:(.literal.* .text.*)
    *libmesh.a:(.literal.* .text.*)
    *libnet80211.a:(.literal.* .text.*)
    *libsmartconfig.a:(.literal.* .text.*)
    *libssl.a:(.literal.* .text.*)
    *libupgrade.a:(.literal.* .text.*)
    *libwpa.a:(.literal.* .text.*)
    *libwpa2.a:(.literal.* .text.*)
    *libwps.a:(.literal.* .text.*)

    *libmbedtls.a:(.literal.* .text.*)

    *libm.a:(.literal .text .literal.* .text.*)
[...]

Search for " .irom0.text : ALIGN(4)", then add those *lib... lines if they are missing.

scargill commented 7 years ago

I hope those lines mean something to someone...

davydnorris commented 7 years ago

Yeah they do - that is telling the linker to move a whole lot of code out of .text and into .irom0.text, which is EXACTLY what you want mate :-)

scargill commented 7 years ago

But... that's exactly what has not happened... the changes you guys have helped make took my code from 7cxxx which was dangerously close to the edge, to 75xxx which leaves a good margin- yet the code will not finish compiling on 2.1... I'll look at the latest suggestion tomorrow thanks.

davydnorris commented 7 years ago

which is why @kriegste may have hit the nail on the head. If you are still using the older .ld files then you won't have that new stuff in there. And that may well be why you're running out of space!

scargill commented 7 years ago

No, sorry guys, So the two relevant .LD files sit in my RBOOT folder. I replaced them with the new ones - and of course that didnt' work because the link at the bottom of the shorter one was now wrong... fixed the link - recompiled - absolutely the same result... .text will not fit in irom0.text

So with the various changes previously made... on 2.0

Sections: Idx Name Size VMA LMA File off Algn 0 .data 00000d40 3ffe8000 3ffe8000 000000e0 24 CONTENTS, ALLOC, LOAD, DATA 1 .rodata 000028c0 3ffe8d40 3ffe8d40 00000e20 24 CONTENTS, ALLOC, LOAD, READONLY, DATA 2 .bss 0000b218 3ffeb600 3ffeb600 000036e0 24 ALLOC 3 .text 00007508 40100000 40100000 000036e0 22 CONTENTS, ALLOC, LOAD, READONLY, CODE 4 .irom0.text 0009b5d4 40202010 40202010 0000abf0 2**4 CONTENTS, ALLOC, LOAD, READONLY, CODE

As you can see above, .TEXT now has a little more space left...

But on 2.1

c:/espressif/xtensa-lx106-elf/bin/../lib/gcc/xtensa-lx106-elf/4.8.2/../../../../xtensa-lx106-elf/bin/ld.exe: build/app_0.out section .text' will not fit in regioniram1_0_seg' collect2.exe: error: ld returned 1 exit status mingw32-make.exe: *** [build/app_0.out] Error 1

scargill commented 6 years ago

Appreciate any other ideas - I can't believe Espressif deliberately used up this much more memory.

kriegste commented 6 years ago

I saw that the pwm lib is not included in the ld files. You use that lib, too, right? I am not sure if that works at all, but you could also try to add *libpwm.a:(.literal .text .literal.* .text.*) to the ld files.

davydnorris commented 6 years ago

Looking at your two memory map files, most of the changes in memory are from liblwip, and there are a bunch of functions that have been added (or rather, configured).

Given your code worked fine beforehand, I'm thinking you probably didn't use these additions, and that they are therefore not needed.

One of the really cool things that has happened in 2.1.0 is that they have now released the source for a bunch of libraries, and liblwip is one of those. You may be able to compile your own version with the additional capability disabled again.

scargill commented 6 years ago

Very helpful Davy but I would not have the foggiest idea how to compile the libraries like that. Would be ideal if I had full source for the lot in my project - I'm sure there is LOTS I don't use....

scargill commented 6 years ago

Kreigste - bearing in mind I'm not an expert with LD files... not even a beginner, really, the only one of the two where that line seemed to make sense was the first one - eagle.app.v6.ld - I tried it in every section, one at a time, with and without semicolons - no difference to .TEXT size whatsoever.

kriegste commented 6 years ago

Are you sure these are the ld files used for your project? What happens if you delete/move them? You should not be able to make then.

scargill commented 6 years ago

Hi Kriegste - yes, when trying to put in that libpwm.a:(.literal .text .literal. .text.*) - at one point I put it out of any section and the code would not compile... so the eagle.app.v6.ld is definitely in use and in there is a link to the other ld file (eagle.rom.addr.v6.ld) so that's in use too.

davydnorris commented 6 years ago

@scargill - might be worth trying your build with the latest SDK changes. See #55