Cortex M3 - Copying code from flash to ram without startup

Hi,

Can you try using "AT>" rather than "AT >" in your linker script?

Best regards,

Hi,

I have changed it, and it looks the same.

I have also tried the other variation :

 _sidata = .;

 .data : AT ( _sidata )
 {
  _sdata = .;
  *(.data*)
  . = ALIGN(4);
  _edata = .;
 } >ram

Which again didn't change the outcome.

size:
   text data bss dec hex filename
    148 320 8 476 1dc array.elf

arm-none-eabi-nm -na array.elf
..
00000000 a array.c
00000008 A __bss_size
00000094 A __text_size
00000140 A __data_size
08000000 t .text
08000000 T vector_table
08000010 T main
08000078 T delay
08000094 T _etext
08000094 T _sidata
20000000 d .data
20000000 D _sdata
20000000 D uint_array_init_glb
20000140 b .bss
20000140 D _edata
20000140 B _sbss
20000140 B alpha
20000148 B _ebss

Thanks,
Furkan

>The problem I see is that although I don't use any startup code and I don't have any function to copy the text section to ram, all the text section gets copied to the ram area.

I'd really like to know how this happens but for now, lets assume some embedded boot sequence is doing this. In this case, the LMA is the flash address map and the VMA becomes the RAM address map. You could place the data section such that the location counter points to the end of text for the data.

The AT (addr) that you have specified above is the VMA (RAM)

_sidata = .;

 .data : AT ( _sidata )

It should be the LMA which the Flash/ROM.

See the following links for more explanation:

https://sourceware.org/binutils/docs/ld/Output-Section-LMA.html#Output-Section-LMA

and

https://sourceware.org/binutils/docs/ld/Basic-Script-Concepts.html#Basic-Script-Concepts

Hi,

Thanks for the explanation. I could fix the problem by adding a function to copy the data section from rom to ram in the beginning of the code, but without that couldn't get it working properly.

> The AT (addr) that you have specified above is the VMA (RAM)
> _sidata = .;
> .data : AT ( _sidata )
> It should be the LMA which the Flash/ROM.

The _sidata symbol is at the Flash/ROM area as can be seen from the nm output above (08000094 T _sidata)

> You could place the data section such that the location counter points to the end of text for the data.

And from the above example this is exactly what I think I am doing with the above linker.

Here is the objdump output. The data LMA is at 08000094 and VMA is at 20000000 which looks correct to me.

 arm-none-eabi-objdump -h array.elf

array.elf: file format elf32-littlearm

Sections:
Idx Name Size VMA LMA File off Algn
  0 .text 00000094 08000000 08000000 00010000 2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .data 00000140 20000000 08000094 00020000 2**2
                  CONTENTS, ALLOC, LOAD, DATA
  2 .bss 00000008 20000140 080001d8 00020140 2**3
                  ALLOC
 ...

arm-none-eabi-objdump -t array.elf

array.elf: file format elf32-littlearm

SYMBOL TABLE:
08000000 l d .text 00000000 .text
20000000 l d .data 00000000 .data
20000140 l d .bss 00000000 .bss
00000000 l d .comment 00000000 .comment
00000000 l d .ARM.attributes 00000000 .ARM.attributes
00000000 l df *ABS* 00000000 array.c
00000140 g *ABS* 00000000 __data_size
08000094 g .text 00000000 _sidata
08000094 g .text 00000000 _etext
20000140 g .bss 00000000 _sbss
20000000 g O .data 00000140 uint_array_init_glb
00000008 g *ABS* 00000000 __bss_size
20000000 g .data 00000000 _sdata
20000148 g .bss 00000000 _ebss
08000000 g O .text 00000010 vector_table
08000010 g F .text 00000068 main
08000078 g F .text 0000001a delay
00000094 g *ABS* 00000000 __text_size
20000140 g .data 00000000 _edata
20000140 g O .bss 00000008 alpha

Thanks,
Furkan

First of all, how do you expect it to work if you *don't* initialize the .data section from flash? If you don't, the section (and thus your uint_array_init_glb[] will have undefined contents.

The fact that the undefined content looks a bit like the .text section shouldn't bother you at all. How do you know that it isn't remains from a previous run? If you load through GDB, it could potentially initialize RAM sections for you (I know it sets the $pc to your entry point). If you use a gdbserver or flashing tool like for example OpenOCD, it will use the RAM as a working buffer for flashing algorithm and data (this looks very much to be the case here).

In short; just ignore the content of your RAM and write a proper copy routine to initialize it from flash and zero .bss, otherwise it will surely not work.

As I mentioned in my earlier comment, adding a proper copy routine works without any problems, and I was trying to figure out why the data gets copied to RAM area without any initialization code. However you have a good point about st-flash tool using RAM area as a temporary buffer. This might very well be the case. (It doesn't depend on GDB as it happens when I run it as well.)

Cheers,
Furkan