CORE: STM32F103ZET6
Hi,Pros.
Here Monkey comes agian
I have met a problem with my code,see below:
/* --------- code here --------- */ .section .data _sp_usart: .word _stack_usart _stack_usart: .space 0x100, 0 ... // other code here /* --------- code end here --------- */ and I wrote a ldscript looks like this: /* --------- code here --------- */ SECTIONS { ... // other code here . =0x20000000; .data : {*(.data)} } /* --------- code end here --------- */
But what I read from ADDRESS 0x20000000 is a strange number,something like 0x2Exxxxxx,out of the RAM region.
I have no idea for this,how this happens?Can someone please help me?
Message was edited by: stupidMokey
The problem can be in your assembly file, it can be in your linker script.
To find out whether it's one or the other, try first looking at the disassembly of the file...
$ arm-none-eabi-objdump - Mreg-names-std -D -z yourfile.elf
The linker map (.map file) might also give you a few hints.
The linker map tells you where the linker expects to put things. If it says it will put the data at location 0x2exxxxxx, then the problem is with the linker script.
In your assembly file, I suggest that you start with the following line:
.syntax unified
and then on your command-line, add the following switch:
-mimplicit-it=always
(or -Wa,-mimplicit-it=always if you use the C Pre-processor).
... And just for finding out if your .data section is going where you expect it to go, try adding...
.word 0xdeadbeef
...right after your .word _stack_usart; eg. before your .space 0x100, 0
-Then try reading the contents of address 0x20000004
Actually,I had tried almost every step you pointed out above before I turn to here for help.
The Map output is the same as I expect:
/* ---------- ld Map output ---------- */
Disassembly of section .data:
20000000 <_sp_usart>:
20000000: 20000004 andcs r0, r0, r4
20000004 <_stack_usart>:
...
/* ---------- ld Map output end here ---------- */
still,what I read from ADDRESS 0x20000000 is really the number "2e006816".
So,I guess maybe it would be a special mechanism used in CM3,and,maybe I should mark it and search more details to figure it out.
Very kind of you for help.
Hello,
I am afraid your bootloader would use the address 0x20000000 as a work area.
Are there any reason why you should locate (probably) constant _stack_usart on SRAM area?
Best regards,
Yasuhiko Koumoto.
Do you copy your data section from Flash memory to SRAM during startup ?
WOW,bingo!
Thank you for reminding me,I took a look just now and found this:
// quote from "STM32 microcontroller system memory boot mode(AN2606)". 512 bytes starting from address 0x20000000 are used by the bootloader firmware.
// quote from "STM32 microcontroller system memory boot mode(AN2606)".
512 bytes starting from address 0x20000000 are used by the bootloader firmware.
So,that is how the weird number comes.
------------------------------------------------------------------------------------------------------------------------------------------
--- There was no reason but I just did this stupidity and then,you know,I found that confusing number.
I have the answer,thank you two.jensbaueryasuhikokoumoto