The "unknown opcode `vector_(0x0012):'" assembler error cannot be fixed by
a linker script. It's due to the interrupt() macro not doing what needs to
be done with the current version of the code.
The first solution is indeed to rewrite the interrupt as a pure C
function. How much more inefficient it is would depend on what the
function does. The second solution of a C function with asm statements in
it is really not appropriate except in very special cases, and I probably
shouldn't have mentioned it.
The path I recommend is to hard code __isr_XXX where XXX is determined
based on the actual value of the vector define corresponding to the
interrupt you want to replace. In hopes of saving myself time I merely
pasted the output from the compiler, so when you reproduced those steps in
your environment and experimented to see how the C language material
related to the assembler source generated from it you'd have a clue as to
what pieces were important.
In short, all you should need to do is replace:
interrupt(TIMERA0_VECTOR) ;Receive interrupt processing
with:
.global __isr_54
__isr_54:
after correcting the number if necessary. You might check that by running
the original source through the preprocessor to see what that macro did to
it.
Offhand I can't think of any changes required for interrupts written in C,
but the change underlying this was done about two years ago so I may have
simply forgotten.
The mailing list discussion I couldn't find turns out to be a forum
discussion at
https://sourceforge.net/p/mspgcc/discussion/138167/thread/29b15798
Peter
On Sun, Mar 17, 2013 at 10:11 AM, garyr <ga...@fidalgo.net> wrote:
> I don't quite understand the two solutions you describe. I've read through
> some
> of the posts concerning interrupts in mspgcc mail lists archives and now
> understand a bit more than I did. One post appeared to describe a solution
> to
> this problem with a custom linker script. Is that feasible?
>
> For the first solution you describe, are you saying that the existing
> assembly
> language interrupt handler should be changed to a function that is invoked
> from
> the C interrupt handler? That would probably be straightforward if slightly
> inefficient.
>
> In your second solution I understand that I will have to determine the
> correct
> value of N in __isr_N, and I think I can do that. But what is .LFB37?
> Does the
> "main.c" in the .file statement represent the file that the preceding
> compiled/assembled code will be placed in (i.e., in main.o, in this case)?
>
> Do interrupt functions written entirely in C require any changes?
>
>
> ----- Original Message ----- From: "Peter Bigot" <big...@acm.org>
> To: "garyr" <ga...@fidalgo.net>
> Cc: "Matthias Hartmann" <matthias.w.hartm...@gmail.com**>;
> <mspgcc-users@lists.**sourceforge.net <mspgcc-users@lists.sourceforge.net>
> >
> Sent: Saturday, March 16, 2013 1:36 PM
>
> Subject: Re: [Mspgcc-users] Linker error
>
>
> To make things consistent across the whole MSP430 product line the symbols
>> used to define the interrupt entrypoints no longer encode the address of
>> the pointer within the vector table, but rather its offset in words from
>> the start of the vector table. Unfortunately the preprocessor
>> capabilities
>> of the assembler don't allow that to be automatically generated from the
>> macro definition anymore. Somewhere in the mail archive there's some
>> history explaining why this was done, but I can't find it immediately.
>>
>> Recommended solutions are recode the interrupt handler entirely in C,
>> translate the asm interrupt body into asm statements that are placed
>> within
>> a C interrupt handler, or just separately generate the asm source for a
>> dummy interrupt handler in C for the desired vector and replace the asm
>> entry point with the new syntax. E.g., for a C declaration that looks
>> like:
>>
>> #pragma vector=TIMER0_A0_VECTOR
>> __interrupt void
>> ta0cc0_isr (void)
>> {
>>
>> the corresponding assembly source would look something like this (ignoring
>> line numbers)
>> 7 .text
>> 8 .Ltext0:
>> 9 .section
>> .near.text.ta0cc0_isr,"ax",@**progbits
>> 10 .p2align 1,0
>> 11 .global ta0cc0_isr
>> 13 /***********************
>> 14 * Interrupt Vector 54 Service Routine `ta0cc0_isr'
>> 15 ***********************/
>> 16 ta0cc0_isr:
>> 17 .global __isr_54
>> 18 __isr_54:
>> 19 .LFB37:
>> 20 .file 1 "main.c"
>>
>> It is the __isr_54 symbol that will be placed into the interrupt table by
>> the linker.
>>
>> On this MCU the headers have:
>>
>> #define TIMER0_A0_VECTOR (0x006C) /* 0xFFEC Timer0_A5 CC0 */
>>
>> Offset 0x6C in bytes is 54 words into the table that begins at 0xFF80,
>> thus
>> generating the symbol __isr_54.
>>
>> You should be able to determine the appropriate name for the interrupt
>> entrypoint for your MCU based on the value of the interrupt identifier.
>>
>> Peter
>>
>> On Sat, Mar 16, 2013 at 2:55 PM, garyr <ga...@fidalgo.net> wrote:
>>
>> Wayne, Matthias:
>>>
>>> I don't think the problem was due to the pathname containing a space but
>>> it
>>> would have become a problem, no doubt.
>>> The problem was due to a rookie error on my part: I neglected to
>>> recompile
>>> everything before trying to link. In doing that I've found and corrected
>>> problems in a few files but here is one I don't know how to fix:
>>>
>>> make
>>> msp430-gcc -mmcu=msp430F1132 -x assembler-with-cpp -D_GNU_ASSEMBLER_ -c
>>> -o
>>> ../auart/auart.o ../auart/auart.s
>>> ../auart/auart.s: Assembler messages:
>>> ../auart/auart.s:35: Error: unknown opcode `vector_(0x0012):'
>>> make: *** [../auart/auart.o] Error 1
>>>
>>> The code in question is:
>>>
>>> #include <legacymsp430.h>
>>> #include <msp430.h>
>>> [snip]
>>> .text
>>> rxDataSize: .word rxDataEnd-rxDataStart
>>> ;-----------------------------**---------------------
>>> .global rxInterrupt
>>> rxInterrupt:
>>> interrupt(TIMERA0_VECTOR) ;Receive interrupt processing
>>> push r15
>>> [snip]
>>>
>>> >From msp430F1132.h:
>>> #define TIMERA0_VECTOR (0x0012) /* 0xFFF2 Timer A CC0 */
>>>
>>> Any suggestions?
>>> Gary
>>>
>>> ----- Original Message -----
>>> From: "Matthias Hartmann" <matthias.w.hartm...@gmail.com**>
>>> To:
>>> <mspgcc-users@lists.**sourceforge.net<mspgcc-users@lists.sourceforge.net>
>>> >
>>> Sent: Saturday, March 16, 2013 8:33 AM
>>> Subject: Re: [Mspgcc-users] Linker error
>>>
>>>
>>> >I can confirm what Wayne stated.
>>> >
>>> > If I add a blank at the middle of the name of my mspgcc directory and
>>> > update the path accordingly, the linker yields the error that memory.x
>>> > could not be found.
>>> >
>>> > So please recheck your test. Maybe the path contained the mspgcc
>>> > directory twice and you changed only one instance.
>>> >
>>> > Matthias
>>> > Am 16.03.2013 15:46, schrieb garyr:
>>> >> Wayne,
>>> >> Thanks for your reply.
>>> >>
>>> >> My path is C:\Program Files\mspgcc_4.6\bin;
>>> >>
>>> >> The path to my old version of mspgcc was C:\mspgcc\bin so I created a
>>> folder
>>> >> C:\mspgcc_4.6 and copied everything there and changed my path to
>>> >> C:\mspgcc_4.6\bin. Compile is OK but Make still returns the same error
>>> so
>>> >> that
>>> >> must not be the problem.
>>> >>
>>> >> Gary
>>> >>
>>> >> ----- Original Message -----
>>> >> From: "Wayne Uroda" <w.ur...@gmail.com>
>>> >> To: "garyr" <ga...@fidalgo.net>
>>> >> Cc:
>>> >> <mspgcc-users@lists.**sourceforge.net<mspgcc-users@lists.sourceforge.net>
>>> >
>>> >> Sent: Friday, March 15, 2013 11:12 PM
>>> >> Subject: Re: [Mspgcc-users] Linker error
>>> >>
>>> >>
>>> >> This might be off base, but I've had similar issues when there was a
>>> space in
>>> >> my
>>> >> path to mspgcc in the newer versions.
>>> >>
>>> >> - Wayne
>>> >>
>>> >> On 16/03/2013, at 5:53, "garyr" <ga...@fidalgo.net> wrote:
>>> >>
>>> >>> I've been using the mspgcc toolchain I downloaded in 2006. I'm now
>>> trying to
>>> >>> switch to the latest version, 4.6.3. I can compile but make returns
>>> an
>>> >>> error:
>>> >>>
>>> >>> msp430-gcc -mmcu=msp430f1132 -o usb.elf main.o ../auart/auartc.o
>>> >>> ../auart/auart.o ../uart/delay.o ../uart/dco.o ../utils/b2d.o
>>> >>> ../utils/bin2hexS.o
>>> >>> c:/program
>>> >>>
>>> files/mspgcc_4.6/bin/../lib/**gcc/msp430/4.6.3/../../../../**
>>> msp430/bin/ld.exe:
>>> >>> cannot open linker script file memory.x: No such file or directory
>>> >>> collect2: ld returned 1 exit status
>>> >>> mingw32-make: *** [usb.elf] Error 1
>>> >>>
>>> >>> It appears that I'm missing a file for the linker but I don't know
>>> what that
>>> >>> might be. The relevant (I think) portion of my makefile is:
>>> >>>
>>> >>> CPU = msp430f1132
>>> >>> CFLAGS = -mmcu=${CPU} -Wall -O2 -g
>>> >>> ASFLAGS = -mmcu=${CPU} -x assembler-with-cpp -D_GNU_ASSEMBLER_
>>> -c
>>> >>> CC = msp430-gcc
>>> >>> AS = msp430-gcc
>>> >>>
>>> >>> ${NAME}.elf: ${OBJECTS}
>>> >>> ${CC} -mmcu=${CPU} -o $@ ${OBJECTS}
>>> >>>
>>> >>> Any suggestions?
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> ------------------------------**------------------------------**
>>> ------------------
>>> >>> Everyone hates slow websites. So do we.
>>> >>> Make your web apps faster with AppDynamics
>>> >>> Download AppDynamics Lite for free today:
>>> >>> http://p.sf.net/sfu/appdyn_**d2d_mar<http://p.sf.net/sfu/appdyn_d2d_mar>
>>> >>> ______________________________**_________________
>>> >>> Mspgcc-users mailing list
>>> >>> Mspgcc-users@lists.**sourceforge.net<Mspgcc-users@lists.sourceforge.net>
>>> >>> https://lists.sourceforge.net/**lists/listinfo/mspgcc-users<https://lists.sourceforge.net/lists/listinfo/mspgcc-users>
>>> >>
>>> >>
>>> >>
>>> >>
>>> ------------------------------**------------------------------**
>>> ------------------
>>> >> Everyone hates slow websites. So do we.
>>> >> Make your web apps faster with AppDynamics
>>> >> Download AppDynamics Lite for free today:
>>> >> http://p.sf.net/sfu/appdyn_**d2d_mar<http://p.sf.net/sfu/appdyn_d2d_mar>
>>> >> ______________________________**_________________
>>> >> Mspgcc-users mailing list
>>> >> Mspgcc-users@lists.**sourceforge.net<Mspgcc-users@lists.sourceforge.net>
>>> >> https://lists.sourceforge.net/**lists/listinfo/mspgcc-users<https://lists.sourceforge.net/lists/listinfo/mspgcc-users>
>>> >
>>> >
>>> >
>>> ------------------------------**------------------------------**
>>> ------------------
>>> > Everyone hates slow websites. So do we.
>>> > Make your web apps faster with AppDynamics
>>> > Download AppDynamics Lite for free today:
>>> > http://p.sf.net/sfu/appdyn_**d2d_mar<http://p.sf.net/sfu/appdyn_d2d_mar>
>>> > ______________________________**_________________
>>> > Mspgcc-users mailing list
>>> > Mspgcc-users@lists.**sourceforge.net<Mspgcc-users@lists.sourceforge.net>
>>> > https://lists.sourceforge.net/**lists/listinfo/mspgcc-users<https://lists.sourceforge.net/lists/listinfo/mspgcc-users>
>>> >
>>> >
>>>
>>>
>>>
>>>
>>> ------------------------------**------------------------------**
>>> ------------------
>>> Everyone hates slow websites. So do we.
>>> Make your web apps faster with AppDynamics
>>> Download AppDynamics Lite for free today:
>>> http://p.sf.net/sfu/appdyn_**d2d_mar<http://p.sf.net/sfu/appdyn_d2d_mar>
>>> ______________________________**_________________
>>> Mspgcc-users mailing list
>>> Mspgcc-users@lists.**sourceforge.net<Mspgcc-users@lists.sourceforge.net>
>>> https://lists.sourceforge.net/**lists/listinfo/mspgcc-users<https://lists.sourceforge.net/lists/listinfo/mspgcc-users>
>>>
>>>
>>
>
>
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
