How to execute code from RAM on stm32f4Discovery

Well, you'll need to get the code into RAM before you can execute it!!

Why do you want to do this?

www.catb.org/.../smart-questions.html

Well, you'll need to get the code into RAM before you can execute it!!

No, you don't. Code is normally executed from flash on STM32 family of MCU's.

Why do you want to do this?

There can be valid reasons.
- To compare performance when running from flash and from RAM.
- To save flash endurance and/or speed up code upload when doing frequent debugging sessions.

"Code is normally executed from flash on STM32 family of MCU's"

Yes, but the OP specifically asked how to run from RAM - for that, it is necessary to get the code into RAM!

So it is a step that will be necessary for the OP to do this!

"There can be valid reasons"

Did I say there weren't?

But it helps to know the goal in order to give appropriate advice.

I see what you mean. There has to be a boot process that would place the code in RAM.
I was assuming the OP would have the debugger attached, so uploading code wouldn't be a problem. The assumption is not necessarily correct, so yes, we need more info.

Please forgive my poor English.
I mean how to upload my code into RAM instead of flash
I do this because some of the STM32 disrupt GPS modules.
ST explained by interference from flash memory.
So I wanted to upload and run code from RAM for test.

When testing, you can just change your project and in the flash input boxes specify the start address of RAM and then you adjust the address range you specified in the RAM input boxes and shrink the values there correspondingly.

Note two things.
1) You need to check what requirements that specific processor has for interrupt vector table, so you get the vector table properly mapped into the RAM address range. You might have to adjust the startup file to take care of this.

2) You need to use a debugger script that sets the PC to the start of the address range where the code got loaded, since the physical processor will not know about your code in RAM and will try to do a normal start based on the reset vector.

When you later decide to run code in RAM in production use, you can make use of the configuration file for the linker, to have the linker store the code in flash, but configure it for duplication into RAM before your code starts to run. This is similar to how R/W variables have their initial values stored in flash and the startup file then extracts these values into RAM.

"ST explained by interference from flash memory"

I think they may be "pulling your leg" - That sounds highly unlikely to me!

You use a GPS module with internal antenna, or with connector for external antenna?

With external antenna, there should be almost zero chance for the electronics to interfere with the GPS as long as the PCB is properly designed so you don't radiate noise on the antenna ground shield.

With internal antenna, you could get issues with radiation from your own electronics. But with internal antenna, you can't use a shielded case which means that GPS or not, you still have to design the electronics to fulfill all EMI regulations.

No, I don't think executing from RAM instead of flash matters here. If your electronics interferes, I would instead start by checking power supply lines, ground planes etc and see how much noise the electronics radiates from the spikes in the current consumption.

Is it your own hw design? Are there proper caps as close as possible to the chips for all supply voltages? Are there EMI filters limiting bandwith on your I/O signals? Have the GPS power been filtered separately from the power to the processor?

It's all about unfortunately in Polish. www.elektroda.pl/.../topic1541960.html
Issues bad routing on the PCB. shielding, etc.
Author sent a query to the ST and received a reply that the subject is known to them. FLASH is the culprit.
A simple experiment:
On the table next to stm32f4Discovery is FGPMMOPA6H with integrated GPS antenna. No way connected with the power turned off.
Turn on the GPS. After a while. MiniGPS (GPS program) shows that gets fix. Number of satellites ~ 8
Turn stm32f4Discovery drops to 4 satellites. Traci fix, power strips fall.
If connecting systems together (only RX TX) and Stm32f4 only reads the frame. I have to wait very long to fix and although some satellites. The more am approaching it is worse
The other processors do not have this problem. AVR can be placed on GPS and it does not matter.
I sent a query to the ST and so far I'm waiting for an answer.
For stm32f1 .... have been reported the same cases, even with GSM!

Maybe I misunderstood the OP, but I think he is talking about scatter loading that places code in RAM. That is well documented in the linker documentation.

Sounds like amateur weekend then with that PCB :(

I don't understand this thread actually.
But I found a link which may be helpful to the OP.
The below link mentions some SW methods to reduce the electrical noises of STM32vldiscovery.

www.bigmessowires.com/.../

#include "stm32f10x.h"
#include "STM32vldiscovery.h"

GPIO_InitTypeDef GPIO_InitStructure;

void Delay(__IO uint32_t nCount);

int main(void)
{
    /* Configure all unused GPIO port pins in Analog Input mode (floating input
      trigger OFF), this will reduce the power consumption and increase the device
      immunity against EMI/EMC *************************************************/
    RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOA | RCC_APB2Periph_GPIOB |
    RCC_APB2Periph_GPIOC | RCC_APB2Periph_GPIOD |
    RCC_APB2Periph_GPIOE, ENABLE);

    GPIO_InitStructure.GPIO_Pin = GPIO_Pin_All;
    GPIO_InitStructure.GPIO_Mode = GPIO_Mode_AIN;
    GPIO_Init(GPIOA, &GPIO_InitStructure);
    GPIO_Init(GPIOB, &GPIO_InitStructure);
    GPIO_Init(GPIOC, &GPIO_InitStructure);
    GPIO_Init(GPIOD, &GPIO_InitStructure);
    GPIO_Init(GPIOE, &GPIO_InitStructure);

So STM32vldiscovery_LEDInit() enables the clock for port C, where the LEDs are connected, and then configures the correct pin in port C as an output. GPIO_Mode_Out_PP specifies a push-pull output, in other words a normal output that’s actively driven high and low. GPIO_Speed_50MHz controls the rise and fall times of the output signal. Selecting a faster speed will produce shorter rise and fall times, but will consume more current and generate more supply voltage swings and electrical noise.

I was able to run code from RAM. Everything works fine.
Thank you all.