IAR Embedded Workbench for ARM: Porting code from V4 to V5 ( for stm32)

从v4到v5主要修改2个地方：

(1) "__program_start", this start label has changed its name to "__iar_program_start" in the file stm32f10x_vector.c.

(2)change the name in #pragma location from INTVEC to .intvec in the file stm32f10x_vector.c.

详见转载

by Mats Pettersson, IAR Systems

http://qizhying533.blog.163.com/blog/static/193627032010998261667/

Are you porting your project from version 4 to version 5 of the IAR Embedded Workbench for ARM? Maybe this article will help you get an overview of what you are up against.
I received a request from STMicroelectronics for help in porting some of their example applications for their STM32 device—based on the Cortex?-M3 core—to version 5 of IAR Embedded Workbench. I promised I would look into it. We sometimes get requests for help from customers who get stuck when trying to upgrade to version 5, since these two versions differ in many areas:
Project files
C/C++ source format
Assembler source syntax and directives
Linker configuration file
You should also be aware of changes to the:
Debugger
Run-time environment and object files/libraries
So why did we do all these changes in version 5, compared to earlier versions of IAR Embedded Workbench for ARM? The main conceptual difference between version 4 and version 5 is that the internal object format used by IAR Systems build tools has changed. Version 4 uses the UBROF format, whereas version 5 uses EABI (Embedded Application Binary Interface). ARM EABI is based on IA-64 C/C++ ABI. It specifies the runtime model, C standard and C++ runtime libraries and also specifies ELF/DWARF as the object format. Now the good thing about these EABI object files is that modules from different vendors will link together, as long as the modules follow the EABI specifications. ELF/DWARF stands for Executable and Linking Format including DWARF for debug information.
Even though we have all these changes in version 5 of IAR Embedded Workbench for ARM, most of the files can be left unchanged. The project files (EWP and EWD) are converted by the IDE and can almost be ignored. You must, however, remember to check the options after the conversion has been made. The linker options, for example, are reset to the default values.
The parts that require more work are the assembler files and the linker configuration file. C/C++ files can often be used without any modifications at all. I will point to some areas later that will require action from you in regard to the C/C++ source. But let’s start at the beginning.
I will start by converting an STM32F10x example project. In this case, it would be easiest to just start using the new project already in IAR Embedded Workbench for ARM version 5, but we’ll pretend we don’t have that. One point here is that most of the example projects that were in version 4 have been ported to version 5. It is best to use one of these as a starting point if your current application is based on one of these example projects. Then you “only” have to add your changes to this project and you should be all set.

Converting from version 4 to version 5 for STM32

For this first (easy) project conversion, I’ll use the example application IAR-STM32-SK. This example is available in both version 4 and version 5 of IAR Embedded Workbench for ARM, but I will only use the example in version 4.
To start with, I’ll make a copy of the project folder where I keep all project and source files. After that I’ll open the version 4 workspace, IAR-STM32-SK.eww, in version 5 of IAR Embedded Workbench for ARM. Now I’ll get a message for each project in the workspace, telling me this is an old project file and that a conversion can be done. It also informs me that a copy of the original project will be saved. I’ll approve this for all three projects in this workspace.Now we’re halfway to our new project. We can now try to build any of the projects and see what errors and warnings we may get. We know we’ll get errors in this project, but just for fun we’ll do a “Rebuild all” to see what happens.The compiler and assembler do not generate any warnings or errors, but the linker has one error:

We don’t have a definition for __program_start. This is because this start label has changed its name to __iar_program_start.
In the error message, we can see which module or modules are referring to __program_start. In this case it is stm32f10x_vector.c. So we will open the file, stm32f10x_vector.c, in the editor by double-clicking it in the workspace window.
We can see that __program_start is used twice in this file. To make sure we don’t have this label anywhere else, we can search with Find in files (CTRL+SHIFT+F) to look for this symbol in the entire project space. This will confirm that the label only occurs twice in the project.

What to do? The label __program_start is the starting point of the application and should be defined in the startup portion of the standard library that is linked into the application. By default, this label is called __iar_program_start in version 5. So the easiest way to correct this is to rename the two occurrences of __program_start to __iar_program_start in the file stm32f10x_vector.c. Rebuilding the project after this has been done, should result in no further errors or warnings.
Just one thing left to do before we try our project on hardware: As I mentioned before, the linker settings are reset to their default values. This is probably not what you want when building an application that is to be downloaded into hardware. As you know, the linker is responsible (to a large degree) for locating an application in memory.
We have two choices here. First, we could see whether version 5 contains an example for our target hardware and, in that case, use the linker command file from that example. The other way is to review the old linker command file and to ensure that the new command file has the same setup. I’ll show you how it’s done (the hard way) and review my old linker command file, which is included in the project group Other. Just double-click this file and it will open in the editor. After reviewing the command file, I see three parts that I want in my new linker command file:

1. The start of the interrupt vector table (the INTVEC segment)

-Z(CODE)INTVEC=ROMSTART-ROMEND

2. The start and end addresses of ROM and RAM memory

// Code memory in FLASH
-DROMSTART=0x8000000
-DROMEND=0x801FFFF
// Data in RAM
-DRAMSTART=0x20000000
-DRAMEND=0x20004FFF

3. The stack and heap sizes

-D_CSTACK_SIZE=800
-D_HEAP_SIZE=400

We will copy the addresses for the different memory areas and the sizes of the stacks, from the existing xcl file, into the icf file. Other directives for control of the linker no longer reside in the new icf file.
This can easily be set up from within the new IDE. I open the Options dialog from the Project menu in IAR Embedded Workbench and select the Linker Category. In the first tab (Config) my linker command file is set by default to generic.icf. I will check the option Override default and click the Edit button.

The first tab in this dialog box specifies where I want my .intvect region to start. In our case this is address 0x8000000, from reading the old linker command file. I make the necessary change, as shown above.
Also notice that the name of the INTVEC segment has changed to .intvec. We have to remember to edit the interrupt vector start location to .intvec. The interrupt vector is set up in the file stm32f10x_vector.c.)
The next tab is for the memory regions. Here I will use the definitions of ROM/RAM START/END from the old linker command file.

The last step for the linker setup is found on the tab for Stack/Heap Sizes. Again I will use the information from my old project and set the sizes as they used to be.

After this, I click Save and I will get the opportunity to save this linker command file with a name other than generic.icf. The dialog also suggests my project folder as the location. I use the suggested file name GettingStarted.icf and click Save.
Now, let''s see if we can correct the INTVEC/.intvec mismatch. The vector table setup is in the file stm32f10x_vector.c. The location of this table is specified using #pragma location.

We will change the name in #pragma location from INTVEC to .intvec.
We are finally ready to rebuild our application to see if it will run just as well with version 5 as it did with version 4. This test can be made just by clicking the Debug icon, since a build will be made automatically, if needed. And sure enough, after downloading and starting the application, the LEDs go on and off just like they’re supposed to.
Now we’re done with the first project.

Converting from version 4 to version 5 for STR912

For our next and last project conversion, I’ll use a device based on the ARM966E-S? core. I decided to port the STMicroelectronics STR912 example Joystick Mouse. This example can be downloaded from the STMicroelectronics web site. This time we’ll move a bit quicker that we did in our first example.
To start with, this example was not created for the STR912 board included in IAR KickStart Kit for STR912. To get it to work on this board we need to start by modifying the function JoyState() in the file hw_config.c.

u8 JoyState(void)
 {
   u8 port;
   port =GPIO_Read(GPIO7);
   if ((port&0xE0)==0x80) return(UP);
   if ((port&0xE0)==0x20) return(DOWN);
   if ((port&0xE0)==0x60) return(RIGHT);
   if ((port&0xE0)==0x40) return(LEFT);
   else return(0);
 }

The STR912 board has only two buttons and we need to make sure that we read these two buttons if we use this board. The new function looks like this:

u8 JoyState(void)
 {
   u8 port;
   port =GPIO_Read(GPIO7);
   if ((port&0x60)==0x20) return(RIGHT);
   if ((port&0x60)==0x40) return(LEFT);
   else return(0);
 }

We can only move the mouse left/right with these changes, but that’s good enough for this example.
I’ll start by making a copy of my original Joystick Mouse project files.
Then I’ll open up the workspace Joystick Mouse.eww in IAR Embedded Workbench V5.11 for ARM.
Again, I’ll get a message saying that this is an older project file and that a conversion can be made. I’ll click OK.
Let’s perform a build to see what messages we get:
In 91x_init.s we get a couple of Error[109]: Expression is too complex
In 91x_vect.s we get one Error[40]: Bad instruction
Let’s see what this is all about.

Error[109]: Expression is too complex

From the Migration Guide we have the following:
In version 5.x, it is not possible to have two symbols in one expression, or any other complex expressions, unless the expression can be resolved at assembly time. Any such expressions must be rewritten, otherwise the assembler will generate an error.
Back in the assembler source file 91x_init.s we see that all the errors (6 of them) are found at the LTORG directive. If the value of an expression is not within the range of an LDR instruction, or if the expression is unresolved, the assembler places the constant in a literal pool. The LTORG directive directs the current literal pool to be assembled immediately after the LTORG directive.
The problem we have in this assembler module is that the instruction:
LDR     SP, =SFE(xxx_STACK) & 0xFFFFFFF8
… is too complex. We are making a bit-wise AND on an unknown value. If we lose the & 0xFFFFFFF8 we have solved the problem. After removing all six occurrences of & 0xFFFFFFF8, we can rebuild this assembler file without errors or warnings.
LDR     SP, =SFE(xxx_STACK)
Note: The assembler error message number 109 occurs because we use ELF/AEABI. In version 4, the assembler could handle these expressions when using UBROF.

Error[40]: Bad instruction

Here the problem concerns the directive COMMON. This is no longer a valid directive and can be replaced with SECTION.
We replace the line
COMMON   INTVEC:CODE(2)
with the line:
SECTION .intvec:CODE:ROOT(2)
After this we can build our application without errors or warnings.
This doesn’t necessarily mean that it will work. We know from our previous example, that the new start label is __iar_program_start and not __program_start, as it is here. The application will link without producing an error for this, but the debugger will still look for __iar_program_start when the debug session starts. (The reason why it links without error is that the definition of __program_start is in the 91x_init.s source file.)
I’ll change all occurrences of __program_start to __iar_program_start (using Find in files, CTRL+SHIFT+F as before).
Before we move on from the assembler source files, we need to check them for directives that have been removed or changed. A list of all these directives can be found in the Migration Guide.
Beginning with 91x_vect.s we see that this file looks fine. It doesn’t contain many directives and the only one that had to be changed was the COMMON to SECTION directive, and that has already been done.
In the file 91x_init.s we see more directives. To start with there are some RSEG directives. We change these to SECTION as suggested by the Migration Guide. We also know the default stack alignment is 8 in version 5. In version 4 the default alignment was 4 but 8 could be used as well. (The default alignment of 8 comes from AEABI requirements.)
RSEG xxx_STACK:DATA(2)
is changed to:
SECTION xxx_STACK:DATA:NOROOT(3)
So we have:

MODULE       ?program_start
SECTION       IRQ_STACK:DATA:NOROOT(3)
SECTION       FIQ_STACK:DATA:NOROOT(3)
SECTION       UND_STACK:DATA:NOROOT(3)
SECTION       ABT_STACK:DATA:NOROOT(3)              
SECTION       SVC_STACK:DATA:NOROOT(3)
SECTION       CSTACK:DATA:NOROOT(3)
SECTION       ICODE:CODE:NOROOT(2)
PUBLIC       __iar_program_start
EXTERN       ?main
CODE32

The final thing we need to do is to create a new linker command file. We’ll get the old location values from the previous linker command file (lnkarm_flash.xcl).

-DROMSTART=0x00000000
-DROMEND=0x0007FFFF
-DVECSTART=ROMSTART
-DRAMSTART=0x4000000
-DRAMEND=0x4017FFF
-D_CSTACK_SIZE=0x1000
-D_SVC_STACK_SIZE=0x100
-D_IRQ_STACK_SIZE=0x400
-D_FIQ_STACK_SIZE=0x40
-D_ABT_STACK_SIZE=0x40
-D_UND_STACK_SIZE=0x40
-D_HEAP_SIZE=0x400

With this information we can open the linker command file Edit dialog and modify the values. We then save the linker command file and do a rebuild. Downloading the application will verify that it works the same way as it worked with version 4.42A.

A final word

The examples above are for STMicroelectronics but the porting instructions can easily be applied to any other ARM project.
For more information about porting from version 4 to version 5 of IAR Embedded Workbench for ARM see:
Technical Note 40394: Should I upgrade to version 5 of IAR Embedded Workbench for ARM?

ARM? IAR Embedded Workbench Migration Guide. This guide is also available from the Help menu in the IDE and in the arm/doc folder of the IAR Embedded Workbench installation.