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

Reply via email to