I've finally found and installed mspgcc4. (Version 4.4.4 for Windows). I
expanded the .bz2 file with tar -j and I can generate object files now.
However, I'm still getting warnings about the interrupt vectors, e.g.
$ make tri86.o
msp430-gcc -mmcu=msp430x247 -Wall -g -O2 -c -o tri86.o tri86.c
tri86.c: In function `main':
tri86.c:375: warning: pointer targets in passing argument 1 of
`bmu_transmit' differ in signedness
usci.h:17: note: expected `const unsigned char *' but argument is of type
`char *'
tri86.c: In function `timer_b0':
tri86.c:772: warning: Interrupt vector 0x1001a assigned to ISR `timer_b0' is
invalid.
tri86.c: In function `timer_a0':
tri86.c:838: warning: Interrupt vector 0x10012 assigned to ISR `timer_a0' is
invalid.
The warning about signedness is just gcc4 being more picky than gcc3.
Expected.
Peter Bigot noted:
> No, if you're getting warnings about interrupt vectors, something's wrong.
Indeed, that seems to be the case. With mspgcc4, the end of my disassembly
is
0000ffe0 <InterruptVectors>:
ffe0: 30 80 30 80 30 80 30 80 30 80 30 80 30 80 30 80
0.0.0.0.0.0.0.0.
fff0: 30 80 30 80 30 80 30 80 30 80 30 80 30 80 00 80
0.0.0.0.0.0.0...
With gcc3, it has six vectors defined (other than reset):
0000ffe0 <InterruptVectors>:
ffe0: *dc 8c* *4c 8d* 30 80 30 80 30 80 30 80 *a4 8c* *12 8d*
..L.0.0.0.0.....
fff0: 30 80 *06 8b* 30 80 30 80 30 80 *46 8a* 30 80 00 80
0...0.0.0.F.0...
I'm using the MSP430F247 chip, with -mmcu=msp430x247 in the makefile.
>From the data sheet for that chip, timer_b0 interrupt is priority 29,
address 0xFFFA. (The priority is also the slot number, starting with 0 for
the first.)
This chip has 32 interrupt slots, with the first 16 unused. So the address
0x1001a is 0x20 too many.
I see from /c/mspgcc4/msp430/include/signal.h (mspgcc4 unpacked into
/c/mspgcc4/):
#if defined(__MSP430X__)
#define INTERRUPT_VECTOR_SLOTS 32
#define RESET_VECTOR 62
#elif defined(__MSP430X2__)
#define INTERRUPT_VECTOR_SLOTS 64
#define RESET_VECTOR 126
#else
#define INTERRUPT_VECTOR_SLOTS 16
#define RESET_VECTOR 30
#endif
So it seems that since the interrupt vector address is off by 32, perhaps
INTERRUPT_VECTOR_SLOTS has the wrong value. Perhaps because __MSP430X__ is
not defined correctly, or at all.
It is also possible that since 16 of the interrupt vectors are unused, maybe
the number of slots should be 16.
When I dump the specs, the part that seems relevant to me is this:
%{mmcu=msp430x247:%(cpp_msp2) -D__MSP430_247__}
This seems to be saying that this chip is of kind cpp_msp2. Later in the
specs:
*cpp_msp2:
-DMSP430_HAS_HW_MUL -DMSP430_HAS_HWMUL
*cpp_msp3:
-DMSP430_HAS_HW_MUL -DMSP430_HAS_HWMUL -D__MSP430X__
It seems to me that since this chip has 32 interrupt vectors, that it should
be declared to be of kind cpp_msp3.
I attempted to change the specifications by dumping the specs into a file
named specs, editing that file to make the obvious change, and using
-specs=specs on the compile line. It seemed to make no difference.
I've also tried putting #define __MSP430X__ into my source file at various
places, and using -D__MSP430X__ on the command line as well. None have any
effect that I can detect.
Is there a simple way I can get the compiler to tell me what the value of
INTERRUPT_VECTOR_SLOTS is? I thought that
#error Number of interrupt slots = INTERRUPT_VECTOR_SLOTS
might have done it, but it doesn't expand the #define. (One of my source
files needs #include <signal.h> for the interrupt() macro, so I put the
#error immediately after that.) I know there is a way, I've used it before,
I just can't remember it.
If the MSP430F247 has the wrong cpp_mspX value, then I suspect that a whole
heap of them also do.
I note that mspgcc3, which works fine for interrupt vectors, also defines
this chip as cpp_msp2. So there is likely something wrong in my logic above.
I se that with mspgcc3, some processors soon after msp430x247 have
-D__MSP430X__, so maybe __MSP430X__ should NOT be defined after all. In
crt430x247.o, there are only 16 interrupt vectors defined (symbols with
names like vector_ffxx and _reset_vector__) so that's another clue that the
number of slots should be 16 after all. But then why the warning, and no
interrupt vectors appearing at the right addresses?
The main difference that I can see with mspgcc3 compared with mspgcc4 in
this area is that mspgcc3 does not have support for chips with 64 interrupt
slots. Oh, also mspgcc3 seems to handle definition of __MSP430X__ earlier in
the specs, not with the cpp_mspX section.
All comments welcome.
- Mike
------------------------------------------------------------------------------
The modern datacenter depends on network connectivity to access resources
and provide services. The best practices for maximizing a physical server's
connectivity to a physical network are well understood - see how these
rules translate into the virtual world?
http://p.sf.net/sfu/oracle-sfdevnlfb
_______________________________________________
Mspgcc-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
