EmbDev.net

Forum: ARM programming with GCC/GNU tools GNU Toolchain: Program working in simulation, but not on target


von Marco (Guest)


Rate this post
useful
not useful
Hi all,

I am using uVision 4 with the Sourcery GNU toolchain. Compiling and 
linking works, even debugging in simulation mode works. But if I 
download to the target, the entry address (PC after reset) and the 
stackpointer are completely wrong. I am using a STM32F107VC (Cortex-M3).

Here is the output of readelf:
1
$ arm-none-eabi-readelf.exe -S project.elf
2
There are 18 section headers, starting at offset 0x3884c:
3
4
Section Headers:
5
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
6
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
7
  [ 1] .isr_vector       PROGBITS        08000000 008000 000108 00   A  0   0  4
8
  [ 2] .text             PROGBITS        08000108 008108 00fe2c 00  AX  0   0  4
9
  [ 3] .bss              NOBITS          20000000 018000 000094 00  WA  0   0  4
10
  [ 4] ._usrstack        NOBITS          20000094 018000 000100 00  WA  0   0  1
11
  [ 5] .ARM.attributes   ARM_ATTRIBUTES  00000000 017f34 00002f 00      0   0  1
12
  [ 6] .comment          PROGBITS        00000000 017f63 0003b2 00      0   0  1
13
  [ 7] .debug_aranges    PROGBITS        00000000 018318 0002e0 00      0   0  8
14
  [ 8] .debug_pubnames   PROGBITS        00000000 0185f8 002d10 00      0   0  1
15
  [ 9] .debug_info       PROGBITS        00000000 01b308 00b459 00      0   0  1
16
  [10] .debug_abbrev     PROGBITS        00000000 026761 001d16 00      0   0  1
17
  [11] .debug_line       PROGBITS        00000000 028477 002162 00      0   0  1
18
  [12] .debug_frame      PROGBITS        00000000 02a5dc 003af8 00      0   0  4
19
  [13] .debug_str        PROGBITS        00000000 02e0d4 00419c 01  MS  0   0  1
20
  [14] .debug_loc        PROGBITS        00000000 032270 00651e 00      0   0  1
21
  [15] .shstrtab         STRTAB          00000000 03878e 0000be 00      0   0  1
22
  [16] .symtab           SYMTAB          00000000 038b1c 002d30 10     17 121  4
23
  [17] .strtab           STRTAB          00000000 03b84c 002b40 00      0   0  1
24
Key to Flags:
25
  W (write), A (alloc), X (execute), M (merge), S (strings)
26
  I (info), L (link order), G (group), x (unknown)
27
  O (extra OS processing required) o (OS specific), p (processor specific)
28
29
$ arm-none-eabi-readelf.exe -x .isr_vector project.elf
30
31
Hex dump of section '.isr_vector':
32
  0x08000000 00000120 c5fc0008 00000000 00000000 ... ............
33
  0x08000010 00000000 00000000 00000000 00000000 ................
34
  0x08000020 00000000 00000000 00000000 00000000 ................
35
  0x08000030 00000000 00000000 00000000 00000000 ................
36
  0x08000040 00000000 00000000 00000000 00000000 ................
37
  0x08000050 00000000 00000000 00000000 00000000 ................
38
  0x08000060 00000000 00000000 00000000 00000000 ................
39
  0x08000070 00000000 00000000 00000000 00000000 ................
40
  0x08000080 00000000 00000000 00000000 00000000 ................
41
  0x08000090 00000000 00000000 00000000 00000000 ................
42
  0x080000a0 00000000 00000000 00000000 00000000 ................
43
  0x080000b0 00000000 00000000 00000000 00000000 ................
44
  0x080000c0 00000000 00000000 00000000 00000000 ................
45
  0x080000d0 00000000 00000000 00000000 00000000 ................
46
  0x080000e0 00000000 00000000 00000000 00000000 ................
47
  0x080000f0 00000000 00000000 00000000 00000000 ................
48
  0x08000100 00000000 00000000                   ........

At address 0x08000000 there is the address of top of stack which is 
configured to 0x20010000 in my linkner script. So this seems to bee 
correct in the elf-file (little endian). When I download the image to 
the target, R13 (SP) is initialized with 0x2000a450, which is not what 
is in the elf!

At address 0x08000004 there should be the address of the reset handler. 
According to the map-file, this is linked to address 0x0800fcc4. In the 
elf-file, we read 0xc5fc0008 (little endian). Since Cortex-M3 only 
supports thumb, the LSB is set to 1 to indicate thumb-mode. When 
downloading the image to the target, R15 (PC) contains 0x0800046c which 
is wrong again!

Any ideas, hints and tips on what could go wrong with downloading highly 
appreciated!

Many thanks in advance!

--
Regards,
 Marco

von Martin T. (mthomas) (Moderator)


Rate this post
useful
not useful
Try do transfer the code with the STM32 bootloader, for example with the 
flash loader demonstrator available from st.com. If it works there is a 
problem with the programming-settings in the IDE (model, 
flash-programming-algorithm, memory-regions, erase...). If it does not 
work too you know that there is something wrong with the code, compiler- 
or linker-settings.

Please log in before posting. Registration is free and takes only a minute.
Existing account
Do you have a Google/GoogleMail account? No registration required!
Log in with Google account
No account? Register here.