Sysprogs forums › Forums › VisualGDB › ESP8266 iram1_0_seg too Large
- This topic has 16 replies, 3 voices, and was last updated 8 years, 2 months ago by support.
-
AuthorPosts
-
April 25, 2016 at 16:32 #8086jhinkleParticipant
Built the VisualGDB’s example no-OS SDK HTT Server example + GDB stubb and iram1_0_seg is at 31K out of 32K
Not Much RAM code space left!!!
Gutted the HTTP code and placed a small test function (all assigned to flash) + uart.c which only hase the interrupt routines and the char-processing routines in ram — everything else assigned to rom.
Won’t compile!!!!
Can anyone suggest a method of re-gaining some code ram (iram1_0_seg) space back?
I googled the web and searched Espressif’s site — and the only suggestion is to move the SDK literals from ram to rom in the LD file …. but I suspect things will run VERY SLOWLY then so I’m not placing that solution at the top of the list.
Any comments appreciated.
Note … when I test in the RTOS SDK — there is over 5K of ram available.
Most everything I found on the web were from people building on the Ardunio platform and did not properly assigned their function to flash.
Sysprogs — Are the default libs you provide compiled such that 95% of iram1_0_seg is taken?
April 25, 2016 at 17:02 #8092supportKeymasterHi,
Yes, the libraries we provide (that come straight from the Espressif’s SDK) are compiled in a way that occupies most of the RAM. You can try hacking them (with extracting individual objects from .a files to .o files and renaming sections) to move some rarely functions from RAM to the IROM section.
We have also heard people disabling the instruction cache and successfully using another 32K block of RAM after the first 32K, but we have not tried it ourselves and are not aware of the potential performance or stability impact.
April 25, 2016 at 19:26 #8096jhinkleParticipantI’m not the best at modifying the LD files.
Can you provide me an example of how to move the json.a out of ram and into rom?
Thanks.
April 26, 2016 at 03:47 #8097supportKeymasterSure, but please note that you do it at your own risk. Doing this may result in random crashes, bugs and strange behavior in production code.
- Enable the generation of a .map file in VisualGDB Project Properties
- Identify a particular symbol that you want to move to FLASH (json.a does not get included anywhere, so we’ll move ets_timer_arm_new that does). You can find the biggest symbols via Embedded Memory Explorer.
- Build the project and locate the symbol in the linker script:
.text 0x4010016c 0x3d8 f:\SysGCC\esp8266\esp8266-bsp/IoT-SDK/lib\libmain.a(ets_timer.o) 0x450 (size before relaxing) 0x40100244 ets_timer_setfn 0x40100328 ets_timer_disarm 0x401003d8 ets_timer_arm_new
- Copy libmain.a to libmain_fixed.a
- Run the following commands to extract ets_timer.o from libmain_copy.a, rename .text to .irom0.text and put it back:
xtensa-lx106-elf-ar x libmain_fixed.a ets_timer.o xtensa-lx106-elf-objcopy --rename-section .text=.irom0.text ets_timer.o xtensa-lx106-elf-ar r libmain_fixed.a ets_timer.o
- Replace “main” with “main_fixed” in esp8266.mak (it will get reverted back once you edit anything in VisualGDB Project Properties, so you can instead rename libmain.a to libmain_orig.a and edit libmain.a).
- Check the map file to see how it got moved to ROM:
.irom0.text 0x40240000 0x3e4 f:\SysGCC\esp8266\esp8266-bsp/IoT-SDK/lib\libmain_fixed.a(ets_timer.o) 0x450 (size before relaxing) 0x402400dc ets_timer_setfn 0x402401c4 ets_timer_disarm 0x40240278 ets_timer_arm_new
April 26, 2016 at 14:51 #8104jhinkleParticipantThank you … now I understand the process.
I got to recreating a new lib (liblwip.a) – I changed tcp.o and tcp_out.o.
As a double check .. I extracted those to “.o” file and did an objdump and confirmed that text was converted to irom.
I saved the original liblwip.a and placed my version of it in C:\SysGCC\esp8266\esp8266-bsp\IoT-SDK\lib
THAT should address my iram space — SHOULD!!!
I recompiled my application and the size of iram did not change. When I viewed the map file .. tcp.o still had the original .text size.
So I’m puzzled — the liblwip.a in your lib folder holds my changed version of it yet when my app is linked — it does not appear that the section changes occurred and the original is somehow being used.
Any ideas where I’m going wrong in this process?
Thanks
April 26, 2016 at 15:28 #8105jhinkleParticipantNever mind — found the issue.
Early on when I loaded your software … I originally loaded it into C:
Then I removed the software and loaded it into D:
I compiling from D — not C
Is there a way to get back to C without reloading everything again … I speaking by referencing folder SysGCC
Thanks for all your help.
My trial expires in a couple of days and I will be purchasing it.
April 26, 2016 at 18:02 #8107supportKeymasterNo problem. If you run into any any further problems, feel free to open another topic.
April 26, 2016 at 19:33 #8111jhinkleParticipantHow and I tell VisualGDB to use the SysGCC on C: instead of D;
Thanks
April 27, 2016 at 00:58 #8113supportKeymasterHi,
The easiest way to do that would be to just reinstall the toolchain to c:\ again. The installer will update the registry automatically.
September 30, 2016 at 12:57 #9168freeckParticipantHi there,
It worked perfectly well with the ets_timer function. Unfortunately I ran into trouble trying function _divdi3.o, part of libgcc.a. A “dangerous relocation” error occured. It was suggested to add -mlongcalls to the compiler options, but no succes. Perhaps someone can give me a hint.
But perhaps better questions would be:
1: which know IRAM-functions can be relocated to flash? Perhaps there a list available?
2: Why did you select ets_timer as an example?October 1, 2016 at 19:30 #9176supportKeymasterHi,
The error you are encountering most likely means that some other library function is compiled expecting that the functions from _divdi3.o will be placed nearby. Adding -mlongcalls to your compilation won’t help as it will not affect the pre-compiled library code. Basically, you have something like this:
If you want to relocate divdi3(), you also need to relocate func1() and any other functions that call divdi3() or are “connected” by shortcalls in the call graph. We don’t know enough about the structure of the internal ESP8266 libraries to give any definitive answer here, but you can try the following process iteratively:
- Relocate one function
- Build, find out the function causing the problem from the error log
- Relocate the offending function as well
Sorry for the inconvenience, but this is the common case with ESP8266.
Regarding ets_timer() we picked it because it was directly called from the user code and would hence illustrate the process well.
October 4, 2016 at 09:42 #9198freeckParticipantThanks for the advise.
Following your procedure I got the message from the linker that the calling function “__udivmoddi4” could not “reach” the relocated functions. So then I tried to relocate function “__udivmoddi4”, but there was no reference to “__udivmoddi4” in the map-file to be found…October 5, 2016 at 03:44 #9204supportKeymasterHi,
Perhaps this is something auto-generated by the compiler? Please try reverting the settings to a point when the code builds successfully, enable the generation of Map files and check the .map file for any references to ‘_udivmoddi4’. It should mention the .o or .a file that contains the function.
October 5, 2016 at 20:54 #9215freeckParticipantThat was exactly what I did, but could not find any reference to udivmoddi4.
I repeated this procedure using the BlinkLed example, same result. perhaps you are able to find the reference?October 6, 2016 at 01:50 #9220supportKeymasterHi,
Strange. Could you post the entire error message and a few lines above/below?
-
AuthorPosts
- You must be logged in to reply to this topic.