Set standard lib memory address

I have never ever needed to set any standard lib memory address. And I don't think you need either.

When the linker produces a binary, it computes all target addresses that needs to be adjusted based on where the different code blocks are stored.

You do not (!) want to create an application that depends on the library functionality having been compiled months earlier and placed in the flash. Any changes in version between compilers or if you build your application with a newer version of the compiler etc would invalidate any assumption that it's safe to call the individual functions already stored in that other flash block.

Unless you are a very advanced developers with a huge amount of experience, you really should make your application binary 100% self-contained. So the boot loader downloads an opaque binary blob and places at a predefined target address in flash without understanding the actual logic of the application. And the application after being started manages itself all alone without any assumptions on binary functions already behing stored at magic addresses in the device.

Next thing is that it should be ok to have your code in any memory address range that the processor actually supports for code execution. If your program fails when a function is in a specific memory region, then it's time to start debugging to find out what assumptions you have made that aren't correct.

Have you verified your stack sizes? That all RAM gets properly initialized? That all memory controllers for external memory is initialized before the first access to external memory regions?

Obviously, if there is a bug in the program, then moving code or moving variables may change the behaviour of the program. Sometimes, some rearranging may make the bug stop producing any bad effects. But moving code/variables is best done after you have found and fixed the bug - just to make sure that same bug doesn't show up again later but giving some other unexpected result.

I have never ever needed to set any standard lib memory address. And I don't think you need either.

When the linker produces a binary, it computes all target addresses that needs to be adjusted based on where the different code blocks are stored.

You do not (!) want to create an application that depends on the library functionality having been compiled months earlier and placed in the flash. Any changes in version between compilers or if you build your application with a newer version of the compiler etc would invalidate any assumption that it's safe to call the individual functions already stored in that other flash block.

Unless you are a very advanced developers with a huge amount of experience, you really should make your application binary 100% self-contained. So the boot loader downloads an opaque binary blob and places at a predefined target address in flash without understanding the actual logic of the application. And the application after being started manages itself all alone without any assumptions on binary functions already behing stored at magic addresses in the device.

Next thing is that it should be ok to have your code in any memory address range that the processor actually supports for code execution. If your program fails when a function is in a specific memory region, then it's time to start debugging to find out what assumptions you have made that aren't correct.

Have you verified your stack sizes? That all RAM gets properly initialized? That all memory controllers for external memory is initialized before the first access to external memory regions?

Obviously, if there is a bug in the program, then moving code or moving variables may change the behaviour of the program. Sometimes, some rearranging may make the bug stop producing any bad effects. But moving code/variables is best done after you have found and fixed the bug - just to make sure that same bug doesn't show up again later but giving some other unexpected result.