elf has a LOAD segment with RWX permissions when using .RamFunc functions

[RobDeatherage]

I've seen other posts to resolve the compiler warning of "elf has a LOAD segment with RWX permissions", but I'm receiving this warning only when calling functions in RAM using the .RamFunc segment attribute.

From the map file I've verified the function is being loaded into RAM.  I could disable the warning, but would like to understand the underlying issue.

I'm working with the latest STMCubeIDE version 1.16.0, but also saw this in 1.15.0.  I'm building code for the STM3H735 and STM32H745 families.

[Iampritesh]

Hi,

try creating another project with the default setting, don't add any drivers and copy yourController_FLASH.Id (e.g., yourController = STM32F401 ) content to your project's file & rebuild project. That should be fine afterwards.

[nicolas]

I had the same problem and I generated new .ld files and saw there was some "(READONLY)" missing in my files.
There is also another thread about this problem: https://community.st.com/t5/stm32cubeide-mcus/stm32cubeide-1-15-0-elf-has-a-load-segment-with-rwx-permissions/td-p/652335

[Carl_G]

I'd like a bit more clarity on this one. Typically I have seen flash writing routines loaded into RAM in order to supporting writing to FLASH. Often FLASH does not allow itself to be written to by a routine that is also executing from that same flash. Thus, you put the flash writing routine in RAM and execute from there.

I can see that 

*(.RamFunc)
.RamFunc 0x200003ac 0x88 ./Drivers/STM32G0xx_HAL_Driver/Src/stm32g0xx_hal_flash.o

Is going into RAM and causing RAM to be executable. However, I can't see where this code is put into the RamFunc section. So I can't tell what its doing and if it needs to be in RAM. Can someone confirm that it is OK to put this code into FLASH and that it will still work fine from there.

[TDK]

> Can someone confirm that it is OK to put this code into FLASH and that it will still work fine from there.

You can erase and write to flash from code running in flash. The MCU will stall until the erase operation is over, then continue on. Obviously, if you erase the code that is currently executing the chip will hard fault shortly thereafter.

[Carl_G]

Good to know there are no RWW restrictions on this MCU. That being the case I wonder why this code was put into RAM!? I use this for eeprom emulation on a flash area that is not executable.

[Pavel A.]

There are reasons to run code from internal RAM. This is perfectly legal. The si*l*l*y linker warning was added in some recent toolchain version. It can be ignored. ST hasn't bothered to silence it in their default GNU tools settings (the specs file) so we have to do this on ours own. Linking images for STM32 worked just fine long before this new linker version with the annoying warning.

[Carl_G]

I get the warning. My application isn't networked so I don't have any exploit risk. So I'll just stick this code in ROM and move along...

[Uwe Bonnes]

It is a pity that no more specific warning is given! The error message should stat _what_ section!