End of program...

[M G_2]

Posted on May 12, 2018 at 00:03

Dear Community,

If I compile a project for e.g. STM32F051 which contains following line

int END_ofProg             __attribute__((at(0x08007C00)))    = 1; supposed to show up at the end of program, then I notice that Keils’ compiler adds some additional stuff on top of the hex dump:

:107C00000100000000000000000000000000000073

:107C10000000000000000000000000000000000064

:107C20000000000000000000000000000000000054

:107C30000000000000000000000000000000000044

:107C40000000000000000000000000000000000034

:107C50000000000000000000000000000000000024

:107C60000000000000000000000000000000000014

:107C70000000000000000000000000000000000004

:107C800000000000000000000000000000000000F4

:107C900000000000000000000000000000000000E4

:107CA00000000000A92E0008B92D00081D2E0008B4

:107CB000F12E000800000000011200084D1200081B

:107CC000F91B000800000000010203040102030484

If I remove this additional code later on e.g. by deleting the associated flash page the code stops to work after reset. If I look for the map file the code inside the hex dump should not to be there.

   0x08006868  0x00000008  Data  RW          61   .ARM.__AT_0x08006868 main.o

   0x08006870  0x00001390  PAD

   0x08007c00  0x00000004  Data  RW          62   .ARM.__AT_0x08007C00 main.o **

** this is the last line.

After searching the ST Forum regarding this this issue Ive found this Thread:

<LINK NO LONGER ACTIVE>

However I not really understand what the mentioned change of the scatter file really does and if a changed scatter file will cause that the additional code vanishes. I would be glad if someone would post a more descriptive explanation of what is going on.

[Tesla DeLorean]

Posted on May 12, 2018 at 01:05

The AT directive can cause all kinds of issues, how does it build without doing that?

How large are the statics?

The Linker builds table beyond the end of code that describe the areas of RAM that need initializing, either be zeroing, or by copying a block of data held in FLASH.

  extern uint32_t Load$$LR$$LR_IROM1$$Limit;

  printf('Limit %08X\n', (uint32_t)&Load$$LR$$LR_IROM1$$Limit);

http://www.keil.com/support/man/docs/armlink/armlink_pge1362065953823.htm

 

...

:10348000000000000000000000000000000000003C

:10349000000000000000024040000000100000009A:1034A000200000000800000000180240000C02404C:1034B000000C0240002802400024F400010000003B:0834C0001000000000000000F4:04000005080001B539:00000001FF

Limit 080034C8

[M G_2]

Posted on May 17, 2018 at 20:42

Dear Clive,

thank you very much for responding to my question (and sorry for my late response). The point of what I did by putting in the line “int END_ofProg…� into my code was to make sure that those additional lines where moved beyond this line. Thus I got the possibility to add some lines such as....

double Parameter1  __attribute__ ((at(Adress_before_END_ofProgram                    ))) =  1.0;

....which are already pre initialized with certain values after flashing the firmware but which can also still be changed during runtime. Thus I can delete the associated Flashpage without destroying those strange lines of code at the end of the program. The reason of my question was to find out for what kind of secret operation the µC uses those lines -  which might d some kind of ram initialization as you’ve pointed out in your response. However I want to understand what exactly the µC does using those lines. It would help very much if I could reverse translate this code into assembler. The newest edition of IDA seems to support ARM codes however its full licence is quite expensive. So a pdf containing the mnemonics would help very much.

[Tesla DeLorean]

Posted on May 17, 2018 at 20:53

Keil has an object disassembler, use FromELF with the -c option

FromELF foo.axf  -c  -s  -d  >foo.lst

The .HEX describes the load region in the .AXF, so should be equivalent.