BenF V3 source code

It is exacly like this in IAR4 - the vector table in LIB is located in segment CODE, which is
of type CODE and aligned on 2-byte boundaries; the table begins with __APP_start, so
other symbols could be located by computing the offset.

Here’s the excerpt from LIB’s ASM_Functions.s:

RSEG CODE:CODE(2)
__APP_Start                ;void __APP_Start(void)
    B       0x0800C121
__USB_Istr                 ;
    B       USB_Istr
__CTR_HP                   ;
    B       CTR_HP
__MSD_WriteBlock           ;
    B       MSD_WriteBlock
__MSD_ReadBlock            ;
    B       MSD_ReadBlock
__Get_Font_8x14            ;
    B       Get_Font_8x14
__Get_Ref_Wave             ;
    B       Get_Ref_Wave
__SD_Set_Changed           ;void SD_Set_Changed(void);
    B       SD_Set_Changed

The only EXPORTED symbol is __APP_Start, which contains the IAR4 entry point for APP.

Now, the parallel definitions in APP’s ASM_Functions.s are these:

__CTR_HP                  ;void __CTR_HP(void)
    B       0x08004159
__USB_Istr                ;void __USB_Istr(void);
    B       0x08004155
;-------------------------------------------------------------------------------
__MSD_WriteBlock          ;u8 __MSD_WriteBlock(u8* pBuffer, u32 WriteAddr, u16 NumByteToWrite)
    B       0x0800415D
__MSD_ReadBlock           ;u8 __MSD_ReadBlock(u8* pBuffer, u32 ReadAddr, u16 NumByteToRead)
    B       0x08004161
__Get_Font_8x14           ;u16 __Get_TAB_8x14(unsigned char Code, unsigned short Row)
    B       0x08004165
__Get_Ref_Wave            ;u8 __Get_Ref_Wave(unsigned short i)
    B       0x08004169
__SD_Set_Changed          ;void __SD_Set_Changed(void)
    B       0x0800416D

from which you can infer that __APP_Start resides in memory at location 0x08004151 when LIB is compiled under IAR4. Of course, it won’t get the same address with IAR5 - there’s a brand new linker, there.

And, for the very same reason (as you already pointed out), __APP_Start should be updated to contain a different address - the APP entry point under both gcc and IAR5 will be different from 0x0800C121.

Well, this needs a solid rework in IAR5 too :wink:

A good starting point for me could be the one you proposed - a separate section whose address is specified via linker config. These notes explain how to do that in IAR5:
http://supp.iar.com/Support/?note=36121
http://supp.iar.com/Support/?note=17934

Don’t know about gcc, but another problem in the migration to IAR5 could be given by different stack alignment: from the migration guide at http://supp.iar.com/FilesPublic/SUPPORT/004242/EWARM_MigrationGuide.ENU.pdf, I read

Antonio