From: JMGross <ms...@gr...> - 2009-09-28 16:12:47
|
The valid vectors are all below 0x10000, so 0x10052 does not point into the vector table. This is most likely caused by a wrong start value for the vectors. Unfortunately, all vectors are defined up from a defined start address instead of down from 0xfffe. So the start address differs with the number of vectors. And I remember a wrong start address being discovered in one of the header files several months ago (together with a patch posted here in the list and merged into CVS). Anyway, a second look into the source file shows USCI_A0_VECTOR being defined in the very same file as 114 (which is 0x72). Give the default start address of 0xffe0 for the vector tables in older devices, this becomes 0x10052 which is outside the vector segment. For the newer devices (with more interrupt siources) the start address for vectors is 0xff80. With this, the given vector offset will result in the proper address of 0xfff2. So most likely the makefile is wrong (stating the wrong target device) or the linker script has a wrong segment definition table. JMGross ----- Ursprüngliche Nachricht ----- Von: Przemek Klosowski An: GCC for MSP430 - http://mspgcc.sf.net Gesendet am: 27 Sep 2009 15:47:13 Betreff: Re: [Mspgcc-users] cannot compile __bic_SR_register_on_exit( ) from mspgcc v.3.2.3 Per Steve Underwood's MSPGCC manual, you have to #include <signal.h> in the interrupt service code modules (1) . Also, extern "C" is not necessary for compiling C, and I believe is not even alowed in C code: it prevents mangling of C++ externals so it's only needed for C++ code (i.e. .cpp/.C/.cxx files). With those two changes, your code compiles. with warnings about __FUNCTION__ being deprecated, and an invalid Interrupt vector being assigned to your ISR. I understand that the current GCC replaces __FUNCTION__ with __func__ so the iomacros.h file should be patched accordingly. I am not sure about the ISR vector number: the warning is about vector 0x10052 which isn't even mentioned in the file. Perhaps someone familiar with writing ISRs for MSPGCC can explain what's going on. |