Forums

linker overlapping segments

Started by ethernet777 January 24, 2013
I am seeing the linker place code for one module in a location that another module has reserved with the DS directive.

Details:
- IAR KickStart for MSP430 5.51.3
- project is assembler-only
- target is MSP430G2412

Example code:

Module A:
aseg 0xE1E6
a1: dc16 0x1234
a2: ds16 16
a3: dc16 0x5678
end

Module B:
rseg CDATA :CODE(1)
b1: dc16 0x7654
end

The linker places variable b1 at 0xE1E8 which should be reserved for variable a2. There is no warning of overlapping segments, even tho' this message is enabled.

Is this behavior to be expected? It is not desirable for my project.

Beginning Microcontrollers with the MSP430

I don't know which assembler you're using, but this is really obfuse
coding style. I prefer a simpler, much cleaner style. I notice that the
location of rseg is not mentioned anywhere, hence the linker may be free
to place it whereever it likes, without knowing the specific linker
details I don't know.

The use of the seg directives is fine for relocatable code, but that is
more the domain of microprocessors than small memory model microcontrollers.

I prefer a far simpler, method that I believe is clean, easily
understood, and far more informative.

I name all the relevant memory addresses for a given micro in the *.h
file as per the following example from my 2254 *.h file:-

/************************************************************
* End of Modules
************************************************************/

RAMSTART EQU 0x0200
RAMEND EQU 0x03FF
BOOTSTART EQU 0x0C00
BOOTEND EQU 0x0FFF
FLASHSTART EQU 0xC000
INFOD EQU 0x1000
INFOC EQU 0x1040
INFOB EQU 0x1080
INFOA EQU 0x10C0
INT_TABLE EQU 0xFFE0
TOS EQU RAMEND+1

I can then easily separate everything, and at the same time create a
simple version control structure using a SHELL file as follows:-

this simple structure just gets cut and pasted for new projects. There
is no ambiguity about where anything will reside in memory, and if code
does grow into another segment you get plenty of warnings or errors.

Al

#include "MSP430F2254.H" ;Hardware Register definitions
#include "xx_IO.s43" ;System I/O structure
#include "xx_HDR.S43" ;Constants, variables and flags

/*CONSTANTS*/

MEMSTART EQU FLASHSTART
PROGSTART EQU 0xE200
TYPE EQU 2254

/***************************************************************************************
INFORMATION MEMORY SEGMENT D HOLDS SERIAL NUMBER DATA
***************************************************************************************/

ORG INFOD
/***************************************************************************************
INFORMATION MEMORY SEGMENT C HOLDS CONFIG TABLE
***************************************************************************************/
ORG INFOC
/***************************************************************************************
INFORMATION MEMORY SEGMENT B IS CUSTOM FOR DISTRIBUTOR DATA
***************************************************************************************/

ORG INFOB

ORG INFOA

ORG MEMSTART

LOG_BASE: ;LOG MEMORY STARTS AT BEGINNING OF CODE SPACE

ORG PROGSTART

MAINCODE:

#include "xx_ISR.s43" ;ISR module is dedciated memory segment
;with fixed ISR addresses
#include "xx_MAIN.S43" ;Constants, variables and flags
#include "xx_INIT.S43"
#include "xx_EVENTS.S43"

;****************************************************************************
;*
;* Interrupt Vector Assignments
;*
;* (Interrupt Vectors are at end of program memory)
;*
;****************************************************************************

ORG INT_TABLE ;Start of Int Table

DW DUMMY_ISR
DW DUMMY_ISR
DW PORT1_ISR ;I/O PORT1 P1.x
DW PORT2_ISR ;I/O Port2 P2.x
DW DUMMY_ISR
DW ADC10_ISR ;ADC
multi-sauce interrupt
DW USCABTX_ISR ;UART1 TX
VECTOR, TRAP IF UNUSED.
DW USCABRX_ISR ;UART1 Rx & SPI
DW TA12_ISR ;Timer A3 CC Block 1&2
DW TA0_ISR ;Timer A3 CC Block 0
DW WDT_ISR ;Watchdog timer
DW DUMMY_ISR
DW TB12_ISR ;Timer B7 CC Block 1-6
DW TB0_ISR ;Timer B7 CC Block 0
DW NMI_ISR ;NMI, Osc fault, Flash
violation
DW CODESTART ;POR, Ext
reset, Watchdog

;****************************************************************************
END
;****************************************************************************

On 24/01/2013 5:22 PM, ethernet777 wrote:
> I am seeing the linker place code for one module in a location that another module has reserved with the DS directive.
>
> Details:
> - IAR KickStart for MSP430 5.51.3
> - project is assembler-only
> - target is MSP430G2412
>
> Example code:
>
> Module A:
> aseg 0xE1E6
> a1: dc16 0x1234
> a2: ds16 16
> a3: dc16 0x5678
> end
>
> Module B:
> rseg CDATA :CODE(1)
> b1: dc16 0x7654
> end
>
> The linker places variable b1 at 0xE1E8 which should be reserved for variable a2. There is no warning of overlapping segments, even tho' this message is enabled.
>
> Is this behavior to be expected? It is not desirable for my project.

On 2013-01-24 07:52, ethernet777 wrote:
> I am seeing the linker place code for one module in a location that
> another module has reserved with the DS directive.
>
> Details:
> - IAR KickStart for MSP430 5.51.3
> - project is assembler-only
> - target is MSP430G2412
>
> Example code:
>
> Module A:
> aseg 0xE1E6
> a1: dc16 0x1234
> a2: ds16 16
> a3: dc16 0x5678
> end
>
> Module B:
> rseg CDATA :CODE(1)
> b1: dc16 0x7654
> end
>
> The linker places variable b1 at 0xE1E8 which should be reserved for
> variable a2. There is no warning of overlapping segments, even tho' this
> message is enabled.
>
> Is this behavior to be expected? It is not desirable for my project.
Hi!

If you replace the line "aseg 0xE1E6" with the directive "asegn
A_SEGMENT_NAME,0xE1E6", it will work as you want it to.

"asegn" is a more modern alternative to creating absolute segments, the
old "aseg" simply emits the DC bytes but does not inform the linker that
something occupy the space between them.

You should specify a segment name, however, you don't have to add it to
the linker configuration file, as the address is specified in the directive.

-- Anders Lindgren, IAR Systems
--
Disclaimer: Opinions expressed in this posting are strictly my own and
not necessarily those of my employer.