The whole characterization of MCUs as msp1,2,3,4,5,6 or ISA_whatever and the
assumption that the CPU type definitively identifies the vector length is
not reliable, which is why I'm reworking things to eliminate the hard-coded
MCU characteristics. (As an example, the msp430f2410 is an MSP430, but the
msp430f2416 is a MSP430X.)
Though in this case, it's simpler: the ISA_24 chips do not set the correct
base address for the interrupt vector start in msp430.c. They're all at
0xffc0, but the code defaults to 0xffe0.
I'll have to review all the MCUs and ensure that vector start is set
correctly. It takes several hours to bundle and prepare a release, so it'll
be sometime late Sunday before there's a new version out. There won't be
pre-built binaries for it, so it may be worth your time until then making
sure you have the toolchains installed to build mspgcc4 from scratch.
(Unfortunately, due to the way the build scripts work, it's very difficult
to apply a patch to an existing build, though if you're comfortable with
doing builds by hand it can be done.)
Peter
On Sat, Feb 5, 2011 at 7:52 PM, Mike Van Emmerik <[email protected]> wrote:
> 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
>
>
------------------------------------------------------------------------------
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
