Then there must be something else in your IDE's configuration that provided the right paths so it could find the memory.x appropriate for the target. It probably did the -L part of what -mmcu does, but not the crt0ivtbl part. Dunno whether it originally did the -mcpu and -mmpy stuff right either; getting those wrong could result in some very difficult to diagnose problems.
At any rate, that too is an IDE configuration issue, nothing to do with mspgcc. I suggest you file a bug report with whoever supports the IDE. Peter On Tue, Aug 23, 2011 at 9:04 AM, Valentin Sawadski <valen...@energybob.com> wrote: > I checked the readelf for the binary I produced without passing the > "-mmcu=cc430f6137" flag to the linker. It showed the following output > > readelf -e Binary-linked-without-mmcu-set > [Nr] Name Type Addr Off Size ES Flg Lk Inf Al > [ 0] NULL 00000000 000000 000000 00 0 0 0 > [ 1] .text PROGBITS 00008000 000074 0000a2 00 AX 0 0 2 > [ 2] .vectors PROGBITS 0000ff80 000116 000020 00 AX 0 0 1 > > So it seems like the position was correct after all. It's just that the > vector table is longer with -mmcu=cc430f6137, which writes the reset > vector at the right position. > > readelf -e Binary-linked-with-mmcu-set > [Nr] Name Type Addr Off Size ES Flg Lk Inf Al > [ 0] NULL 00000000 000000 000000 00 0 0 0 > [ 1] .text PROGBITS 00008000 000074 0000a2 00 AX 0 0 2 > [ 2] .vectors PROGBITS 0000ff80 000116 000080 00 AX 0 0 1 > > Kind Regards, > Valentin > > On Tue, 2011-08-23 at 07:57 -0500, Peter Bigot wrote: >> At the risk of re-opening what appears to be a solved problem: >> >> In that case, mspgcc should have built a binary for the default >> processor (msp430f110), which would have put the text at 0xfc00 and >> the interrupt vector at 0xffe0. (Confirm that with readelf -e and >> look for the .text and .vectors sections.) >> >> If mspdebug wrote the text section to 0x8000 and the vectors to 0xffc0 >> anyway, it must have selected addresses based on the chip being >> programmed, rather than what was specified in the object file. >> >> Daniel, can you confirm this is how mspdebug works? If it's true, it >> seems to have the potential for biting people who try to do tricky >> things like use non-standard memory layouts. Or maybe not. Good to >> know that it could happen, though. >> >> Peter >> >> On Tue, Aug 23, 2011 at 7:28 AM, Valentin Sawadski >> <valen...@energybob.com> wrote: >> > Hi Peter, hi JMGross, >> > >> > you were right, I did forget to pass -mmcu=cc430f6137 to the linker. I >> > thought my IDE passed this argument to both, the compiler and the >> > linker, but obviously it did not. >> > >> > Anyway now mspgcc produces a full size 128 byte vector table and >> > everything works fine. >> > >> > Thank you both for your quick replies. >> > >> > Best regards, >> > Valentin >> > >> > On Tue, 2011-08-23 at 06:12 -0500, Peter Bigot wrote: >> >> It's possible there's something wrong with the toolchain, but unlikely >> >> as the close-related CC430F5137 is the primary development platform >> >> for mspgcc. Most likely you didn't put -mmcu=cc430f6137 on all phases >> >> of the build process: if it was missing from the command that produced >> >> the final non-relocatable link, the linker wouldn't know the size of >> >> the interrupt vector for that part, and would default to a 16-element >> >> vector. >> >> >> >> Peter >> >> >> >> On Tue, Aug 23, 2011 at 4:56 AM, Valentin Sawadski >> >> <valen...@energybob.com> wrote: >> >> Hello, >> >> >> >> I'm fairly new to the world of MSP430s therefore this might be >> >> a simple >> >> case for more experienced users. However I don't know how to >> >> explain or >> >> fix the following behaviour. >> >> >> >> But first things first. I use a Fedora 15 x86 installation as >> >> a host >> >> system. I installed mspgcc from source using the >> >> mspgcc-20110716.tar.bz2 >> >> tar-ball from SourceForge. As far as I can tell everything >> >> worked out >> >> fine. In addition to the mspgcc-toolchain I installed mspdebug >> >> from >> >> Fedora repositories. >> >> >> >> My goal is to run a simple example on an CC430F6137 MCU. >> >> Compilation and >> >> Linking seems to work fine as I can not find any warnings or >> >> errors in >> >> the output (see attached file). >> >> >> >> However if I try to run my binary on the MCU nothing happens. >> >> mspdebug >> >> displays the following output while flashing: >> >> Erasing... >> >> Programming... >> >> Writing 156 bytes to 8000... >> >> Writing 32 bytes to ff80... >> >> >> >> I then compiled the same code using IAR and found out that >> >> when I flash >> >> the IAR-binary using mspdebug everything works out fine and I >> >> can run >> >> the code. In addition I noticed that mspgdebug does not write >> >> 32 bytes >> >> in the vector table but only 2 bytes to position 0xfffe. >> >> I then read those last two bytes out of the table and saw that >> >> it was >> >> 00 at 0xfffe >> >> 80 at 0xffff >> >> >> >> Now the interesting part: If I flash my mspgcc binary to the >> >> MCU, set >> >> the last two bytes manually and reset the MCU, then I can run >> >> the mspgcc >> >> binary! >> >> >> >> Is this a bug in mspgcc or am I doing something wrong? >> >> >> >> Kind Regards, >> >> Valentin >> >> >> >> >> >> >> >> ------------------------------------------------------------------------------ >> >> Get a FREE DOWNLOAD! and learn more about uberSVN rich system, >> >> user administration capabilities and model configuration. Take >> >> the hassle out of deploying and managing Subversion and the >> >> tools developers use with it. >> >> http://p.sf.net/sfu/wandisco-d2d-2 >> >> >> >> _______________________________________________ >> >> Mspgcc-users mailing list >> >> Mspgcc-users@lists.sourceforge.net >> >> https://lists.sourceforge.net/lists/listinfo/mspgcc-users >> >> >> >> >> > >> > >> > >> > ------------------------------------------------------------------------------ >> > Get a FREE DOWNLOAD! and learn more about uberSVN rich system, >> > user administration capabilities and model configuration. Take >> > the hassle out of deploying and managing Subversion and the >> > tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 >> > _______________________________________________ >> > Mspgcc-users mailing list >> > Mspgcc-users@lists.sourceforge.net >> > https://lists.sourceforge.net/lists/listinfo/mspgcc-users >> > >> > > > ------------------------------------------------------------------------------ Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 _______________________________________________ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
