[Solved] Overflow region dram0_0_seg for big project ...

[kolban]

I am trying to compile a lot of C source files and then link them together for a large application. My goal was to create a large library as an ESP-IDF component. So far, all the compiles are progressing cleanly but at the linkage step, it is failing with the following error:

Code: Select all

LD app-template.elf
/opt/xtensa-esp32-elf/bin/../lib/gcc/xtensa-esp32-elf/4.8.5/../../../../xtensa-esp32-elf/bin/ld: /home/kolban/esp32/esptest/apps/workspace/jerryscript/build/app-template.elf section `.dram0.bss' will not fit in region `dram0_0_seg'
/opt/xtensa-esp32-elf/bin/../lib/gcc/xtensa-esp32-elf/4.8.5/../../../../xtensa-esp32-elf/bin/ld: region `dram0_0_seg' overflowed by 267900 bytes
/home/kolban/esp32/esptest/esp-idf/make/project.mk:255: recipe for target '/home/kolban/esp32/esptest/apps/workspace/jerryscript/build/app-template.elf' failed

Somewhere in the depths of my memory I seem to remember something about the current state of our ESP-IDF environment as building code that is loaded into RAM as opposed to being kept in flash... but other than that little snippet, that's all I have.

Does anyone have experience in debugging or tweaking error areas such as this? I am using the out of the box ESP-IDF and latest app template.

[WiFive]

I am trying to compile a lot of C source files and then link them together for a large application. My goal was to create a large library as an ESP-IDF component. So far, all the compiles are progressing cleanly but at the linkage step, it is failing with the following error:

Code: Select all

LD app-template.elf
/opt/xtensa-esp32-elf/bin/../lib/gcc/xtensa-esp32-elf/4.8.5/../../../../xtensa-esp32-elf/bin/ld: /home/kolban/esp32/esptest/apps/workspace/jerryscript/build/app-template.elf section `.dram0.bss' will not fit in region `dram0_0_seg'
/opt/xtensa-esp32-elf/bin/../lib/gcc/xtensa-esp32-elf/4.8.5/../../../../xtensa-esp32-elf/bin/ld: region `dram0_0_seg' overflowed by 267900 bytes
/home/kolban/esp32/esptest/esp-idf/make/project.mk:255: recipe for target '/home/kolban/esp32/esptest/apps/workspace/jerryscript/build/app-template.elf' failed

Somewhere in the depths of my memory I seem to remember something about the current state of our ESP-IDF environment as building code that is loaded into RAM as opposed to being kept in flash... but other than that little snippet, that's all I have.

Does anyone have experience in debugging or tweaking error areas such as this? I am using the out of the box ESP-IDF and latest app template.

Dram is data not code. Are you compiling with the jerryscript esp8266 options for low ram usage? See I told you you would run out of memory.

[kolban]

When I look at the front page here:

http://jerryscript.net/

The project claims that it needs <64K of RAM and <200K of flash.

Given that (I think) my ESP32 has ~512K RAM and ~4MB of flash ... I'm missing something (I think).

What I believe I need to understand is how the ESP-IDF is generating "sections" and where it wants to put them.

[ESP_igrr]

The way to debug such issues is as follows:
1. Increase the size of the offending memory region in the linker script
2. Link the application and examine the elf file: xtensa-esp32-elf-objdump -t -j .dram0.bss

[kolban]

Thank you guys ...

Again it was another false alarm on my part ... it seems that program I am compiling (jerryscript) wants to create a RAM heap to manage its own storage (JavaScript variables). The default heap size it wanted to allocate ... 512K. Ouch ... too much. Turning it down to a more managable size and all is now good. Here is the link to the definition in the jerryscript project:

https://github.com/Samsung/jerryscript/ ... nfig.h#L41

[Ritesh]

The way to debug such issues is as follows:
1. Increase the size of the offending memory region in the linker script
2. Link the application and examine the elf file: xtensa-esp32-elf-objdump -t -j .dram0.bss

Hi,

We have also faced this type of issue while adding some external source to compile into application. I have also checked ESP32 LD script and found that length of dram0_0_seg is 0x50000 which is 320 KBytes of RAM.

So, I have following questions regarding that.

1) How-much we can extend that segment? upto 512 KBytes? But with that we can use any extra memory after that and it might be system not started if we allocate that much amount of memory. Basically system needs some RAM to up and running initially. let me correct if i am wrong.

2) " Link the application and examine the elf file: xtensa-esp32-elf-objdump -t -j .dram0.bss". This is just for debugging purpose. correct?

How to prevent above error? It seems most preferable solution is to store all functions into Flash memory instead of RAM. correct?

Also, On which location of flash memory the function will be defined as we are also planning to create some custom partitions into flash memory according to flash memory which we are planning to use.

[Ritesh]

Thank you guys ...

Again it was another false alarm on my part ... it seems that program I am compiling (jerryscript) wants to create a RAM heap to manage its own storage (JavaScript variables). The default heap size it wanted to allocate ... 512K. Ouch ... too much. Turning it down to a more managable size and all is now good. Here is the link to the definition in the jerryscript project:

https://github.com/Samsung/jerryscript/ ... nfig.h#L41

Please suggest me the solution to solve this issue and its procedure as well

[Ritesh]

Also, some more update that there are some large arrays defined into application code which are compulsory required for my application code.

[Ritesh]

I have tried with solution like increasing DRAM0 Segment but not able to generate binary after generating elf file.

Please find following error output

dram0_0_seg len = 0x5B000

A fatal error occurred: Segment loaded at 0x40115710 lands in same 64KB flash mapping as segment loaded at 0x40115598. Can't generate binary. Suggest changing linker script or ELF to merge sections.

[WiFive]

There is only 2 solution: use less ram or add more external ram (wrover). Maybe can move some things to iram if you are close to the limit.