EmbDev.net

Forum: µC & Digital Electronics STM32F4xx: running code from ram


Author: Lauren (Guest)
Posted on:

Rate this post
0 useful
not useful
Greetings to all readers,

shortly ago I read, that the execution of binary code stored in the 
first section of the ram of an STM32F407xx is possible although the 
Cortex-M4F has an harvard architecture
(http://www.arm.com/files/downloads/Developing_Adva...) 
.

Well, so far I began to introduce myself in the settings of the linker 
of the launchpad-gcc-toolchain until a single question start to circle 
around in my head: Does it really make sense to execute code from ram, 
if I just want to increase the speed of execution, for example for 
calculating an FFT?

If you want to program a bootloader I would agree, that it might be 
advantageous, but thats not the application I'm focusing.

Thanks, Lauren

Author: Thomas Winkler (Company: privat) (diddl)
Posted on:

Rate this post
0 useful
not useful
executing in RAM is maybe a good idea for two reasons:

+ some JTAG (like JLINK) has small licences with no debug support in 
flash

+ flash can be written only 100.000 times. While developing it is 
nessecary to flash very often. So execution in RAM would be good for 
flash

Author: Martin Thomas (Guest)
Posted on:

Rate this post
0 useful
not useful
ST Microelectronics promotes the STM32F4 series with: "Based on CoreMark 
benchmark, the performance achieved thanks to the ART accelerator is 
equivalent to 0 wait state program execution from Flash memory at a CPU 
frequency up to 168 MHz." (Source: DM00037051.pdf/Datasheet, ART 
section). A "branche cache" is mentioned so zero wait-states (from the 
cache) should be possible for non-linear code execution to a certain 
level. It might be a good idea to ask in the forum at st.com but since 
only very small modifications are needed to place selected functions in 
Flash or in RAM, profiling both options should not be that difficult. 
Please post your results.

Author: Sam P. (Guest)
Posted on:

Rate this post
0 useful
not useful
> although the Cortex-M4F has an harvard architecture

If you look at the block diagram of the Cortex-M family, you will see 
that this is not a classic Harvard architecture. It is about as much 
Harvard as pretty much every Intel CPU since the Pentium is, which means 
that data and code have different buses for performance reasons only 
(think separate D-Cache/I-Cache in almost every desktop CPU today).

Really, people should stop calling it Harvard architecture, because 
while technically correct, for all practical purposes it isn't. Also, it 
only applies to the Cortex-M core itself, not to the MCU as a whole 
(most of which usually have a hierarchical von-Neumann architecture).

As for the original questions, I agree with what Martin Thomas wrote. 
Note also that external RAM tends to be much slower than Flash on these 
MCUs.


On a side note:
> flash can be written only 100.000 times.

Shouldn't that be "10.000"? Some flash MCUs even guarantee just 1.000 
write cycles. 100.000 is more typical for EEPROMs.

Author: Lauren (Guest)
Posted on:
Attached files:

Rate this post
0 useful
not useful
Thank you for answering!

Currently I try to set up an example to get a running linker-script:
In main.c intiates a gpio-port and catches the MC a loop:
while(1)
{
delay();
toggle_io();
}

The function "toggle_io" is in an different file for the code which 
should be executed from a ram-location. In my example the function just 
toggles the gpio-port.

My problem is the linker-script.

Normaly the script looks like this (in CooCox):
OUTPUT_FORMAT ("elf32-littlearm", "elf32-bigarm", "elf32-littlearm")
SEARCH_DIR(.)
INCLUDE "memory.ld"

/* Section Definitions */ 
SECTIONS 
{ 
       
    .text : 
    { 
        KEEP(*(.isr_vector .isr_vector.*)) 
        *(.text .text.* .gnu.linkonce.t.*)         
        *(.glue_7t) *(.glue_7)                    
        *(.rodata .rodata* .gnu.linkonce.r.*)                            
    } > rom */
    
  
    
    .ARM.extab : 
    { ...

...
...
} 


In my first attemp I divided the .text section in two part (without any 
further changes) and inserted my .boot-section between the isr-vectors 
and the user-code-section .
Currently I havn't implemented a loader-function, I only wanted to see, 
if the MC jumps to a ram-location.
It didn't! The toggle-fuction was executed from a flash-location, so
the programm was able to run.

I assume, that the toggle-function is linked a second time in the second 
part of the .text-section, so I tried to link the other .o-files 
manually.
After that I got an elf-file with 32KB large .text-section, that is even 
not able to init the gpio-port.
Now I'm confused...
Whats wrong with this code?
SECTIONS 
{ 
.text : 
    { 
        KEEP(*(.isr_vector .isr_vector.*))  /* keep interrupt vector at default position */
    } >rom
         
     .boot : /* create boot-section between isr-vectors and user code*/
     AT (0x20000000)  /*  relocate to ram begin */
     {
      _sram_code = .  ;    /* save start adress of code */
        ..\obj\boot.o *(.text);  /* link code to ram-position*/
       _eram_code = . ;     /* save end adress of code*/
     }  > rom 
   
 /* first try */
 /*   .text : 
    {   
        *(.text .text.* .gnu.linkonce.t.*)         
        *(.glue_7t) *(.glue_7)                    
        *(.rodata .rodata* .gnu.linkonce.r.*)                          
    } > rom */
 /* end first try*/

/* second try: */  
    .text : 
   {   
        ..\obj\main.o *(.text);
        ..\obj\stm32f4xx_gpio.o *(.text);
        ..\obj\startup_stm32f4xx.o *(.text);  
        ..\obj\stm32f4xx_rcc.o *(.text); 
    ..\obj\system_stm32f4xx.o *(.text); 
            
        *(.glue_7t) *(.glue_7)                    
        *(.rodata .rodata* .gnu.linkonce.r.*)                          
    } > rom 
/* end second try*/    
    
    .ARM.extab : 
    {...
...

Author: Uwe Bonnes (Guest)
Posted on:

Rate this post
0 useful
not useful
Be sure to handle initialized Variable in a sensible way!

Author: Lauren (Guest)
Posted on:

Rate this post
0 useful
not useful
Sorry, I don't understand, what you mean...

Author: Lauren (Guest)
Posted on:

Rate this post
0 useful
not useful
The deeper I go, the less I understand...
I tried to read out a simple unsigned long int variable:
...
.text : 
    {    
        KEEP(*(.isr_vector .isr_vector.*)) 
      *(.text .text.* .gnu.linkonce.t.*)    
        *(.glue_7t) *(.glue_7)                    
        *(.rodata .rodata* .gnu.linkonce.r.*)
    } > rom       
              
    _stfunc = 0x00000100; /* just for reading out */
...

In my main.c I declared "extern unsigned long _stfunc" an read it out.
The result is not what I assigned to it in the linker-script.
If I rename it in the script, I got (the expected) error-message.
Are these linker-settings some kind of vodoo ???

Reply

Entering an e-mail address is optional. If you want to receive reply notifications by e-mail, please log in.

Rules — please read before posting

  • Post long source code as attachment, not in the text
  • Posting advertisements is forbidden.

Formatting options

  • [c]C code[/c]
  • [avrasm]AVR assembler code[/avrasm]
  • [code]code in other languages, ASCII drawings[/code]
  • [math]formula (LaTeX syntax)[/math]




Bild automatisch verkleinern, falls nötig
Note: the original post is older than 6 months. Please don't ask any new questions in this thread, but start a new one.