Resolved Memory Overlap Issue on ESP32 with Zephyr, Seeking Long-Term Solution

[c3pStefano]

Hello everyone,

I recently encountered a memory overlap problem while working on a Zephyr project with an ESP32 using the https://docs.zephyrproject.org/latest/samples/subsys/display/cfb/README.html . During the binary generation process, a fatal error occurred because two segments were loaded into the same 64KB flash mapping area. This was the specific error message:

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

I managed to bypass this issue by commenting out a line in the linker script that was apparently causing the overlap:

// #zephyr_linker_sources_ifdef(CONFIG_CHARACTER_FRAMEBUFFER DATA_SECTIONS check_cfb_fonts.ld)

While this solution worked for me, I am aware that it might be more of a temporary fix, possibly bypassing important configurations for different project setups. Therefore, I'm reaching out to the community:
How should one properly resolve this issue to ensure a robust and scalable solution?

I would like to mention that I don't have much experience with memory management. Any suggestions or explanations are greatly appreciated and would be very helpful to me.

Best regards,
Stefan

---

Here's a summary of the development environment:

Environment Setup:

• Operating System: The development is performed on a Windows system.
• Zephyr Version: The project uses Zephyr version 3.6.99

Toolchain and Tools:

• CMake Version: 3.29.2
• Python Version: 3.10.11, running within a virtual environment
• West Tool Version: 1.2.0
• Zephyr SDK: Version 0.16.6 installed at C:/Users/name/zephyr-sdk-0.16.6.
• Compiler: GNU Compiler Collection (GCC) version 12.2.0 for C and C++ programming languages.
• Esptool: esptool.py v4.7.0

Device:

• Board Configuration: esp32_devkitc_wroom/esp32/procpu

[sylvioalves]

@c3pStefano, thanks for reporting this. The issue lies somewhere else. We will handle this.