|
April 12, 2011 - 8:03am
Guest |
Hi to All!
I need to load my application starting adress from 0x0807F800 so dont know how will i configure it in ride7.
i change this in main program
NVIC_SetVectorTable( NVIC_VectTab_FLASH, 0x7F800 );
i try change this file but ride7 create this file again
STM32F103_1024K_96K_DEF.ld
MEMORY
{
RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 0x18000
FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 0x100000
STARTFLASH (rx) : ORIGIN = 0x0, LENGTH = 0x0
CRPPATCH (r) : ORIGIN = 0x0, LENGTH = 0
FLASHPATCH (r) : ORIGIN = 0x00000000, LENGTH = 0
ENDFLASH (rx) : ORIGIN = 0x00000000, LENGTH = 0
FLASHB1 (rx) : ORIGIN = 0x00000000, LENGTH = 0x0
EXTMEMB0 (rx) : ORIGIN = 0x00000000, LENGTH = 0
EXTMEMB1 (rx) : ORIGIN = 0x00000000, LENGTH = 0
EXTMEMB2 (rx) : ORIGIN = 0x00000000, LENGTH = 0
EXTMEMB3 (rx) : ORIGIN = 0x00000000, LENGTH = 0
}
/* higher address of the user mode stack */
_estack = 0x20018000;
Which files i must change in ride7 can you help me?
|
Hi,
If you need to place your boot code at the absolute address 0x0807F800, you need to make several things:
1. Place your application starting address into a new named section, using the gcc qualifier __attribute__.
For example, in your main.c file:
int main(void) __attribute__ ((section(".bootfct")));Note that your "main" function will be located at the required address, but you may have to locate your *reset* address instead (depends on what you want to do). If this is the case, you need a specific satrtup file, and you need to locate its reset vector in the created section.
2. Place your specified section at the required address. This can be done by editing your linker script, but this can be a real pain.
The easiest is to add the specific section through the linker's command line. In Ride, go to your application options and in "LD options | More | More options" add this:
--section-start=.bootfct=0x0807F800Rebuild and check that it properly worked in your map file.
Note that there is a limitation concerning the GCC linker: It is NOT able to locate variable with specific first-order constraints: If you need a specific object located at a given memory address, then this object CANNOT be placed in the middle of a section, it must be between 2 other sections. Which means that you have to locate your application starting address at the beginning of a section.
Best Regards,
I change my project
main.c
int main(void) __attribute__ ((section(".bootfct")));
int main(void)
{
.........................
.....................
}
and
in ride7 i change
LD options | More | More options =>--section-start=.bootfct=0x0807F800
but it fail:
Building C:\Users\xxx\Desktop\stm32testapp_boottest_2\Obd_Proje.rapp
Running: LD Linker
"C:\Program Files\Raisonance\Ride\arm-gcc\bin\arm-none-eabi-gcc.exe" -mcpu=cortex-m3 -mthumb -Wl,-T -Xlinker "C:\Users\xxx\Desktop\stm32testapp_boottest_2\Output\Obd_Proje.elf.ld" -u _start -Wl,-static -Wl,--gc-sections -nostartfiles -Wl,-Map -Xlinker "C:\Users\xxx\Desktop\stm32testapp_boottest_2\Output\Obd_Proje.map" --section-start=.bootfct=0x0807F800
c:/program files/raisonance/ride/arm-gcc/bin/../lib/gcc/arm-none-eabi/4.5.1/../../../../arm-none-eabi/bin/ld.exe: section .bootfct loaded at [08000f0c,08000f53] overlaps section .data loaded at [08000f0c,08000f1f]
collect2: ld returned 1 exit status
Build failed
where is my wrong?
Hi,
The problem in what you want to do is that with gcc you cannot just select an address such as 0x0807F800, you have to take care that your whole application can fit before this address.
Your question is a classic problem, I suggest that you use the CircleOS code http://www.stm32circle.com/ as a starting point. The OS itself uses a specific memory area, and the application uses another one. You will have full detail about the necessary GCC configuration through Ride7.
Best Regards
Hi,
I dont want to use CircleOS.
I just need to learn how to configure my project to start from another address.
My bootloader program is in orjin (0x0) in flash so I must compile my program starting from another adress
Best Regards.
Hi i change C:\Program Files\Raisonance\Ride\lib\ARM\sections_FLASH.ld file
i add
/*****************************************/
MEMORY
{
RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 0x18000
//FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 0x100000
FLASH (rx) : ORIGIN = 0x800F000, LENGTH = 1M-0xF000
STARTFLASH (rx) : ORIGIN = 0x, LENGTH = 0x0
CRPPATCH (r) : ORIGIN = 0x0, LENGTH = 0
FLASHPATCH (r) : ORIGIN = 0x00000000, LENGTH = 0
ENDFLASH (rx) : ORIGIN = 0x00000000, LENGTH = 0
FLASHB1 (rx) : ORIGIN = 0x00000000, LENGTH = 0x0
EXTMEMB0 (rx) : ORIGIN = 0x00000000, LENGTH = 0
EXTMEMB1 (rx) : ORIGIN = 0x00000000, LENGTH = 0
EXTMEMB2 (rx) : ORIGIN = 0x00000000, LENGTH = 0
EXTMEMB3 (rx) : ORIGIN = 0x00000000, LENGTH = 0
}
/***********************************************/
now it looks okey but I am not sure. There are some warnings. It says redeclaration warnings you can see below
I couldnt find where "memory region `FLASH'" is declerated before
Building C:\Users\xxx\Desktop\stm32testapp_boottest_2\Obd_Proje.rapp
Running: LD Linker
"C:\Program Files\Raisonance\Ride\arm-gcc\bin\arm-none-eabi-gcc.exe" -mcpu=cortex-m3 -mthumb -Wl,-T -Xlinker "C:\Users\xxx\Desktop\stm32testapp_boottest_2\Output\Obd_Proje.elf.ld" -u _start -Wl,-static -Wl,--gc-sections -nostartfiles -Wl,-Map -Xlinker "C:\Users\xxx\Desktop\stm32testapp_boottest_2\Output\Obd_Proje.map"
c:/program files/raisonance/ride/arm-gcc/bin/../lib/gcc/arm-none-eabi/4.5.1/../../../../arm-none-eabi/bin/ld.exe:sections_FLASH.ld:22: warning: redeclaration of memory region `RAM'
c:/program files/raisonance/ride/arm-gcc/bin/../lib/gcc/arm-none-eabi/4.5.1/../../../../arm-none-eabi/bin/ld.exe:sections_FLASH.ld:24: warning: redeclaration of memory region `FLASH'
c:/program files/raisonance/ride/arm-gcc/bin/../lib/gcc/arm-none-eabi/4.5.1/../../../../arm-none-eabi/bin/ld.exe:sections_FLASH.ld:25: warning: redeclaration of memory region `STARTFLASH'
c:/program files/raisonance/ride/arm-gcc/bin/../lib/gcc/arm-none-eabi/4.5.1/../../../../arm-none-eabi/bin/ld.exe:sections_FLASH.ld:26: warning: redeclaration of memory region `CRPPATCH'
c:/program files/raisonance/ride/arm-gcc/bin/../lib/gcc/arm-none-eabi/4.5.1/../../../../arm-none-eabi/bin/ld.exe:sections_FLASH.ld:27: warning: redeclaration of memory region `FLASHPATCH'
c:/program files/raisonance/ride/arm-gcc/bin/../lib/gcc/arm-none-eabi/4.5.1/../../../../arm-none-eabi/bin/ld.exe:sections_FLASH.ld:28: warning: redeclaration of memory region `ENDFLASH'
c:/program files/raisonance/ride/arm-gcc/bin/../lib/gcc/arm-none-eabi/4.5.1/../../../../arm-none-eabi/bin/ld.exe:sections_FLASH.ld:29: warning: redeclaration of memory region `FLASHB1'
c:/program files/raisonance/ride/arm-gcc/bin/../lib/gcc/arm-none-eabi/4.5.1/../../../../arm-none-eabi/bin/ld.exe:sections_FLASH.ld:30: warning: redeclaration of memory region `EXTMEMB0'
c:/program files/raisonance/ride/arm-gcc/bin/../lib/gcc/arm-none-eabi/4.5.1/../../../../arm-none-eabi/bin/ld.exe:sections_FLASH.ld:31: warning: redeclaration of memory region `EXTMEMB1'
c:/program files/raisonance/ride/arm-gcc/bin/../lib/gcc/arm-none-eabi/4.5.1/../../../../arm-none-eabi/bin/ld.exe:sections_FLASH.ld:32: warning: redeclaration of memory region `EXTMEMB2'
c:/program files/raisonance/ride/arm-gcc/bin/../lib/gcc/arm-none-eabi/4.5.1/../../../../arm-none-eabi/bin/ld.exe:sections_FLASH.ld:33: warning: redeclaration of memory region `EXTMEMB3'
"C:\Program Files\Raisonance\Ride\arm-gcc\bin\arm-none-eabi-objcopy.exe" "C:\Users\xxx\Desktop\stm32testapp_boottest_2\Output\Obd_Proje.elf" --target=ihex "C:\Users\xxx\Desktop\stm32testapp_boottest_2\Output\Obd_Proje.hex"
"C:\Program Files\Raisonance\Ride\Bin\rexrdr.exe" "C:\Users\xxx\Desktop\stm32testapp_boottest_2\Output\Obd_Proje.elf.sizetmp" 0 "C:\Program Files\Raisonance\Ride\arm-gcc\bin\arm-none-eabi-size.exe" "C:\Users\xxx\Desktop\stm32testapp_boottest_2\Output\Obd_Proje.elf"
"C:\Program Files\Raisonance\Ride\Bin\dwf2xml.exe" "C:\Users\xxx\Desktop\stm32testapp_boottest_2\Obd_Proje.dbi" "C:\Users\xxx\Desktop\stm32testapp_boottest_2\Obd_Proje-globals.Standard.xml" "C:\Users\xxx\Desktop\stm32testapp_boottest_2\Obd_Proje.Standard.xml" ARM
DWF2XML 2.00.01 - Raisonance Dwarf information extractor
Copyright (c) Raisonance S.A.S. 2007-2009. All rights reserved.
Build successful
Hi,
Do not change this file, as it is used for all applications using the default linker script on the PC, and also this is not the file that is supposed to hold this information.
Use a _custom_linker_script_ (not the default) as explained in the GettingStartedARM document, then modify only your application's script, and not the sections_FLASH.ld file but rather the STM32F103_1024K_96K_DEF.ld file. (they are both part of 'the script', with at least two others.)
Best Regards,
Vincent
Hi,
Here is a clearer explanation:
http://forum.raisonance.com/viewtopic.php?pid=12314#p12314
Best Regards,
Vincent
Thank you for your explanation now it works
I copy GNUtools.js and modify
Best Regards,
Hi!
At first I do;
1. "LD Linker" / "Scripts" / "Use Default Script File" from "Yes" to "No"
2. Change the "LD Linker" / "Scripts" / "Script File" and select my .ld file(I modify it FLASH (rx) : ORIGIN = 0x08000000+0x2000, LENGTH = 0x10000-0x2000) and built it
it is give me this hex file
:040000030000008079
:00000001FF
but if i select and modify gnutoolstmp.js and scripts - load (alt+f8)
file2.Write (" RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 0x" + HexString(STM3_RAMSize) + "\n");
file2.Write (" FLASH (rx) : ORIGIN = 0x08002000, LENGTH = 1M-0x2000"+"\n");
file2.Write (" STARTFLASH (rx) : ORIGIN = 0x0, LENGTH = 0x0\n");
it is okey but when i close my project and open, I must load script every time. I save project but it is same...
DO NOT modify GNUtools.js.
Just follow the procedure explained in the FAQ.
Vincent
when i follow the procedure
first I change "LD Linker" / "Scripts" / "Use Default Script File" from "Yes" to "No"
and then
change the "LD Linker" / "Scripts" / "Script File" -> when i want to open a file ride7 wants *.ld file and I selected "STM32F103_64K_20K_FLASH.ld" and built it
this hex file created
:040000030000008079
:00000001FF
!!!!
so whats the wrong !!!
Hi,
This might very possibly be a consequence of the modifications you made in the Ride config files. ("\lib\ARM\sections_FLASH.ld", "\scripts\*.js", etc.) Note that even just adding files in Ride\scripts can have consequences. Just leave this folder as Ride installed it.
Now I suggest you follow this procedure:
1. uninstall RKit_ARM and Ride (and the other RKits that you might have)
2. remove the Raisonance folder (during step 1 the uninstaller will not remove the files that you added or modified)
3. reinstall Ride7 and RKit_ARM
4. apply the procedure in the FAQ to one of the examples on which I tried it: \Examples\ARM\REva\STM32F103_Toggle\...
If it fails, send us (support@raisonance) the project.
If it succeeds, apply the procedure in the FAQ to your project. Don't skip step 1 of the FAQ, (normal link) it is critical. (for re-creating the default script files in your application's folder) Don't assume that it has been done before. (it has, but with wrong files because of your modifications)
Best Regards,
Vincent
thank you now it works fine
Best Regards
Great :cool:
Hi everyone. Sorry to resurrect this old thread, but it is relevant to the issue I am currently experiencing.
I am attempting to modify the starting address of a test application (blinking LEDs program) so that it can be used with ST Microelectronic's DFU Sample, acting as a boot loader.
I followed the procedure which was linked to (by Vincent) in Post #8 in this thread.
http://forum.raisonance.com/viewtopic.php?pid=12314#p12314
The target device for this application is the STR750FV2 (Reva v2.10 daughtercard). In order to be used with the DFU program, which begins at address 0x20000000, the application must begin at address 0x20006000.
So as I went through the procedure, I edited a linker file (STR75xFx2_DEF.ld) to create the address shift.
Before editing, STR75xFx2_DEF.ld looked like this:
/* Linker subscript for STR75xFx2 definitions Copyright RAISONANCE 2006 You can use, modify and distribute this file freely, but without any warranty. */ /* Memory Spaces Definitions */ MEMORY { FLASH (rx) : ORIGIN = 0x20000000, LENGTH = 256K STARTFLASH (rx) : ORIGIN = 0x0, LENGTH = 0x0 CRPPATCH (r) : ORIGIN = 0x0, LENGTH = 0 FLASHPATCH (r) : ORIGIN = 0x00000000, LENGTH = 0 ENDFLASH (rx) : ORIGIN = 0x00000000, LENGTH = 0 FLASHB1 (rx) : ORIGIN = 0x200C0000, LENGTH = 16K RAM (rwx) : ORIGIN = 0x40000000, LENGTH = 16K EXTMEMB0 (rx) : ORIGIN = 0x80000000, LENGTH = 16M EXTMEMB1 (rx) : ORIGIN = 0x82000000, LENGTH = 16M EXTMEMB2 (rx) : ORIGIN = 0x84000000, LENGTH = 16M EXTMEMB3 (rx) : ORIGIN = 0x86000000, LENGTH = 16M } /* higher address of the user mode stack */ _estack = 0x40004000;After editing, STR75xFx2_DEF.ld looked like this:
/* Linker subscript for STR75xFx2 definitions Copyright RAISONANCE 2006 You can use, modify and distribute this file freely, but without any warranty. */ /* Memory Spaces Definitions */ MEMORY { FLASH (rx) : ORIGIN = 0x20006000, LENGTH = 256K STARTFLASH (rx) : ORIGIN = 0x0, LENGTH = 0x0 CRPPATCH (r) : ORIGIN = 0x0, LENGTH = 0 FLASHPATCH (r) : ORIGIN = 0x00000000, LENGTH = 0 ENDFLASH (rx) : ORIGIN = 0x00000000, LENGTH = 0 FLASHB1 (rx) : ORIGIN = 0x200C0000, LENGTH = 16K RAM (rwx) : ORIGIN = 0x40000000, LENGTH = 16K EXTMEMB0 (rx) : ORIGIN = 0x80000000, LENGTH = 16M EXTMEMB1 (rx) : ORIGIN = 0x82000000, LENGTH = 16M EXTMEMB2 (rx) : ORIGIN = 0x84000000, LENGTH = 16M EXTMEMB3 (rx) : ORIGIN = 0x86000000, LENGTH = 16M } /* higher address of the user mode stack */ _estack = 0x40004000;(Note that only line 13 has been been changed.)
Afterwards, I succeeded in compiling .hex data for the blinking LED application. The hex file begins with the following 2 lines:
which indicates that the address change for the application was successful.
What is puzzling, however, is that when I erase the entire flash of the STR750FV2, and then load the blinking LED app's hex file into flash (using the JTAG interface), and then reset the power, the LED blinking application runs. I thought that the application would fail to run in the absence of the bootloader (DFU), since there's no instruction at 0x20000000. But, instead it seems like on power up, the ARM7 automatically jumps to 0x20006000 to get its first instruction. I am not sure why this is happening.
Can anyone shed some light for me about this? Thanks in advance.
Hi,
This is a very interesting remark.
I have made the test on a STR712 device and I confirm what you describe.
In debug I could see that when executing the empty zone at the start of the memory, which is full of 0xFFFFFFFF, it just goes on without trigerring an exception. So after some time it reaches the reset vector , then jumps to the startup and then the main function.
So I think it's all right. Thanks for sharing the information. ;)
Note that this wouldn't work with Cortex devices, as executing undefined instructions would trigger a hardfault exception on and on...
Best Regards,
Vincent
Vincent, thank you for replying, and for your confirmation of the ARM behavior I described.
The fact that an
**10-25-12**
Resubmitted this post due to previous submission being truncated.
**********************
Vincent, thank you for replying, and for your confirmation of the ARM behavior I described.
The fact that an "address-shifted" application (like the blinking LED program) will run normally on ARM startup seems to be causing a problem with my DFU bootloader. Here's what I am seeing.
1. I can erase the entire ARM flash, then load (via JTAG) the DFU bootloader program hex data (starting address=0x20000000), and the DFU bootloader will run properly on ARM startup. (USB cable is needed to connect the ARM on the Reva board to a PC host running STMicro's "DfuSe" Demo GUI for Windows, which I have.)
2. I can then use DFU to download the blinking LED program (starting address=0x20006000) into the ARM flash. The download completes without error.
3. When the RESET button on the Reva board is pressed, the ARM chip always starts the blinking LED application. It never enters DFU mode.
4. Alternately, when the ARM power is cycled (turned off, then turned back on), the ARM chip always starts the blinking LED application. It never enters DFU mode.
Instead of this, however, I am hoping to achieve the following:
1. On power up (or RESET button press) the ARM chip starts in DFU mode (bootloader) if the USB connection to PC host (running DfuSe program) is present on initialization.
2. If the USB connection is not present (or "DfuSe" on the PC host isn't ready), then the DFU mode does not run, and the bootloader passes control to the application by jumping to the application start address, 0x20006000.
Can this goal be reached? Many thanks to the Raisonance Forum group for the great support :)
Hi,
Of course what you want to do is possible. But I don't think there is a relation with the fact that the application runs without the bootloader: When there is an application but no bootloader, the empty code where the bootloader should be IS executed. Only, it does nothing because it is empty.
So if there is a bootloader, it will be executed. Then it has to decide if it launches the application or enters prog mode. But there are several ways to do this, and I think your problem is that your bootloader does not do this as you think it does.
You have to check the doc or source of your bootloader in order to know how it determines, when there is already an application, whether it launches it or enters prog mode. You say that this is done depending on the presence of the USB connection... Are you sure that it is really the case? Most bootloaders work differently, (using a dedicated signal or something else) in order to allow the application to use the USB too.
In fact, ST support team should be able to answer much better than us to these questions, which are not related to the tools, but to the STR7 device and bootloader code...
Best Regards,
Vincent