Well, Przemek noted the warnign about the vector. So maybe HIS makefile was for the wrong processor. Note that you need to define the processor type twice: once when including its definies into the code (often for a complete processor group) and once for the compiler and linker in the makefile. Of course 114 is correct for the 5438 where the vector segment starts at 0xff80. But if compiler/linker are given a processor where the vector segmens start at 0xffe0, it gives a warning and won't work.
You shouldn't use classes or library functions inside an ISR. ISRs should be as short and quick as possible and accessing classes is usually not. It's better to set a flag inside the ISR and handle the job outside. If you absolutely must, you should implement a simple task scheduler and trigger a task switch from inside the ISR to handle the subject. A simple task scheduler takes up only a few hundred bytes and the 5438 has plenty of them (compared to the 1232 where we implemented one anyways) That won't solve your actual code problem but maybe when re-considering the program flow it may disappear anyway. JMGross ----- Ursprüngliche Nachricht ----- Von: Piotr Romaniuk An: [email protected] Gesendet am: 28 Sep 2009 23:22:33 Betreff: Re: [Mspgcc-users] cannot compile __bic_SR_register_on_exit( ) from mspgcc v.3.2.3 I compiled the code for msp430f5438, hence the vector equal to 114 (it is located at 0xFFF2). The C program can be compiled when I removed unnecessary "extern C" - thank you Przemek for suggestion. I also experimented with C++ but there is a problem with __FUNCTION__ (or __func__). In C++ they are not a string literals but "const char *", so it cannot be concatenated with other literals. Please try to compile with GCC the .cpp file containing following code: int main( int argc, char *argv[] ) { char *txt = __FUNCTION__ "something"; const char *txt = __FUNCTION__ "something"; } My intention was to use ISR routine in .cpp file, I need there an access to classes and need to use _bic_SR.... I saw that "extern C" simplifies function names in listing, so the names are compatible with __FUNCTION__, but mentioned above problem with concatenation remains. Piotr Romaniuk -----Original Message----- From: JMGross [mailto:[email protected]] Sent: Monday, September 28, 2009 6:13 PM To: MSPGCC mailing list, Subject: Re: [Mspgcc-users] cannot compile __bic_SR_register_on_exit( ) from mspgcc v.3.2.3 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. ---------------------------------------------------------------------------- -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ Mspgcc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mspgcc-users ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ Mspgcc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mspgcc-users
