MSP430x14x Flere Interrupts problem med mspgcc

Hej

Vi sidder og arbejder på et projekt hvor vi skal bruge flere interrupts på en MSP430F149 MCU. Projektet bliver kompileret med mspgcc (mspgcc.sf.net) toolchain.

Når vi bruger flere interrupts så får vi en fejl: msp430-ld: section .vectors [0000ffe0 -> 0000ffff] overlaps section .text [0000fc00 -> 000100d7]

Vi skal gerne bruge: UART0TX_VECTOR ADC_VECTOR

Vi har husket og køre:

eint();

og kalder interruptene således:

interrupt(ADC_VECTOR) ADC12ISR(void) { ADC[0] = ADC12MEM0; ADC[1] = ADC12MEM1; // Move results, IFG is cleared ADC[2] = ADC12MEM2; ADC[3] = ADC12MEM3; }

interrupt(UART0TX_VECTOR) send_uart0(void) { ... ... ... }

Makefile:

# Project: MSP430 CPP = msp430-gcc.exe CC = msp430-gcc.exe RES = OBJ = main.o konfiguration/konfiguration.o fejl/fejl.o toolboks/toolboks.o porthandler/porthandler.o porthandler/adc.o terminalkomm/RS232.o $(RES) LINKOBJ = main.o konfiguration/konfiguration.o fejl/fejl.o toolboks/toolboks.o porthandler/porthandler.o porthandler/adc.o terminalkomm/RS232.o $(RES) LIBS = -L"C:/mspgcc/lib" INCS = -I"C:/mspgcc/msp430/include" BIN = main.exe CFLAGS = $(INCS)-g -O2 -Wall -mmcu=msp430x149

.PHONY: all all-before all-after clean clean-custom

all: all-before main.exe all-after

clean: clean-custom rm -f $(OBJ) $(BIN)

$(BIN): $(LINKOBJ) $(CC) $(LINKOBJ) -o "main.exe" $(LIBS)

main.o: main.c $(CC) -c main.c -o main.o $(CFLAGS)

konfiguration/konfiguration.o: konfiguration/konfiguration.c $(CC) -c konfiguration/konfiguration.c -o konfiguration/konfiguration.o $(CFLAGS)

fejl/fejl.o: fejl/fejl.c $(CC) -c fejl/fejl.c -o fejl/fejl.o $(CFLAGS)

toolboks/toolboks.o: toolboks/toolboks.c $(CC) -c toolboks/toolboks.c -o toolboks/toolboks.o $(CFLAGS)

porthandler/porthandler.o: porthandler/porthandler.c $(CC) -c porthandler/porthandler.c -o porthandler/porthandler.o $(CFLAGS)

porthandler/adc.o: porthandler/adc.c $(CC) -c porthandler/adc.c -o porthandler/adc.o $(CFLAGS)

terminalkomm/RS232.o: terminalkomm/RS232.c $(CC) -c terminalkomm/RS232.c -o terminalkomm/RS232.o $(CFLAGS)

Vi vil gerne høre fra folk som har brugt flere interrupts på MSP'en

Reply to
Per Toft
Loading thread data ...

Hvad sker der hvis i tvinger .text til at befinde sig et andet sted? (f.eks med -Wl,-Ttext=2000) - Eller SKAL .text starte på 0xfc00? Det ville da virke ret underligt, da interruptvektorerne altid starter ved 0xffe0, hvilket ville medføre en maksimal programstørrelse på 0xffe0 - 0xfc00 = 992 bytes... Og så hut jeg visker, så kunne koden være hele 60K, ikke sandt?

Men en .text sektion der slutter i 0x100d7? det virker vist ret umuligt på for et 64K-adresseområde :)

Ellers kunne i spørge i comp.arch.embedded, der er rigtigt mange der er kloge inden for det her område.

--
mvh Rasmus Neckelmann
Reply to
Rasmus Neckelmann

*snip*

Det er jeres linker, der får forkerte instruktioner. I skal ændre jeres linker-fil, så de to sektioner ikke overlapper hinanden.

Reply to
Ole Lodahl Mikkelsen

section

hinanden.

Hej Ole

Jo tak, det fandt vi ud af for over ½ år siden. Hvordan kandu komme på at svare så lang tid efter?

Hilsen Mikkel

Reply to
Mikkel Lund

Hej Mikkel,

Ole er sikkert bare ny på usenet :)

--
Venlig hilsen,
Søren
              * If it puzzles you dear... Reverse engineer *
LM317-PSU-Designer v1,0b
Reply to
Søren

Men hvordan finder han så gamle indlæg (udover google)? Svjks. smider min newsserver dem ret hurtigt i havnen (eller hvor de nu ender ;-)...

/A

Reply to
Anders F

Hej Anders,

Også min, men måske Sunsites newsserver gemmer dem længe.

--
Venlig hilsen,
Søren
              * If it puzzles you dear... Reverse engineer *
LM317-PSU-Designer v1,0b
Reply to
Søren

Jeg ved det.

Min newsreader skunkede lidt rundt i det, af en eller anden mærkelig grund, da sunsite flyttede server her 2/5 - bl.a. begyndte den at sortere omvendt efter dato uden at jeg opdagede det :-(

Så jeg så bare et indlæg, der så ret simpelt ud, og tænkte, at det kendte jeg da svaret på ;-)

/Ole

Mikkel Lund wrote:

Reply to
Ole Lodahl Mikkelsen

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.