<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://blog.gmane.org/gmane.comp.hardware.texas-instruments.msp430.gcc.user">
    <title>gmane.comp.hardware.texas-instruments.msp430.gcc.user</title>
    <link>http://blog.gmane.org/gmane.comp.hardware.texas-instruments.msp430.gcc.user</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.hardware.texas-instruments.msp430.gcc.user/10564"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.hardware.texas-instruments.msp430.gcc.user/10559"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.hardware.texas-instruments.msp430.gcc.user/10545"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.hardware.texas-instruments.msp430.gcc.user/10544"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.hardware.texas-instruments.msp430.gcc.user/10540"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.hardware.texas-instruments.msp430.gcc.user/10537"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.hardware.texas-instruments.msp430.gcc.user/10535"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.hardware.texas-instruments.msp430.gcc.user/10532"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.hardware.texas-instruments.msp430.gcc.user/10531"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.hardware.texas-instruments.msp430.gcc.user/10529"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.hardware.texas-instruments.msp430.gcc.user/10517"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.hardware.texas-instruments.msp430.gcc.user/10516"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.hardware.texas-instruments.msp430.gcc.user/10514"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.hardware.texas-instruments.msp430.gcc.user/10507"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.hardware.texas-instruments.msp430.gcc.user/10500"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.hardware.texas-instruments.msp430.gcc.user/10491"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.hardware.texas-instruments.msp430.gcc.user/10490"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.hardware.texas-instruments.msp430.gcc.user/10476"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.hardware.texas-instruments.msp430.gcc.user/10462"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.hardware.texas-instruments.msp430.gcc.user/10457"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://comments.gmane.org/gmane.comp.hardware.texas-instruments.msp430.gcc.user/10564">
    <title>missing GET_FRAME_ADDR_F</title>
    <link>http://comments.gmane.org/gmane.comp.hardware.texas-instruments.msp430.gcc.user/10564</link>
    <description>&lt;pre&gt;Dear All,
I am porting some old code from mspgcc v3.x  to v4.x and came across
missing macro GET_FRAME_ADDR_F(). I was using that to determine
from ISR if CPU was sleeping:
   psr = (int *) GET_FRAME_ADDR_F(__FUNCTION__);
   if((*psr &amp;amp; (LPM3_bits)) == LPM3_bits) { /* in LPM3 mode */
         ....

What is the preferred method of doing that with a new toolchain?
Thanks,
Sergei

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
&lt;/pre&gt;</description>
    <dc:creator>Sergei Sharonov</dc:creator>
    <dc:date>2012-05-18T21:19:52</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.hardware.texas-instruments.msp430.gcc.user/10559">
    <title>Fedora Packages</title>
    <link>http://comments.gmane.org/gmane.comp.hardware.texas-instruments.msp430.gcc.user/10559</link>
    <description>&lt;pre&gt;Hi Everyone,

I finally got around to doing some work towards packaging the uniarch
version of mspgcc and friends for Fedora.  I'm working on getting them
into the Fedora repos, but in the meantime you can grab the RPMs from
here: http://users.ecs.soton.ac.uk/rds/rpm/mspgcc-uniarch/

Cheers,

Rob


------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
&lt;/pre&gt;</description>
    <dc:creator>Rob Spanton</dc:creator>
    <dc:date>2012-05-17T21:15:22</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.hardware.texas-instruments.msp430.gcc.user/10545">
    <title>MSPGCC Code Size vs IAR</title>
    <link>http://comments.gmane.org/gmane.comp.hardware.texas-instruments.msp430.gcc.user/10545</link>
    <description>&lt;pre&gt;I'm sorry for bugging people, and I have Googled this question, but the
answers I'm finding are really old and I know there are updates to
mspgcc since most of the answers were posted....

I am trying to port 3 different programs from IAR to MSPGCC for work.
I'm using the latest released version, but 2 of the 3 won't fit even
when compiling using optimizations: -mmcu=$(MCU) -g -Os -Wall
-fdata-sections -ffunction-sections  and linked with --no-keep-memory
-Wl,-gc-sections

Does anyone have any ideas how I can further optimize the compiler
(other than rewriting - which I've been trying to do)?

With an MSP430F149 processor, under IAR, the code compiles and links
(Code = 45858, data = 3000, CONST=4935)

Under GCC, it won't link because '.rodata won't fit into region rom' and
rom overflows by 796 bytes.

Examining the Map file shows .rodata is 0x1a66 in size, .text is 0xc240
in size, .bss is 0x712

Any ideas how to make the libraries or optimizer make smaller code?

adam

This email, including any attachments and files transmitted with it, are for the sole use of the intended recipient(s) to whom this email is addressed, and may contain confidential and/or privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please be advised that you have received this email in error, and please contact the sender by reply email and destroy all copies (including all electronic and hard copies) of the original message. Thank you.

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
&lt;/pre&gt;</description>
    <dc:creator>Adam Ford</dc:creator>
    <dc:date>2012-05-16T15:14:52</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.hardware.texas-instruments.msp430.gcc.user/10544">
    <title>Help to MSPDebug running in eclipse</title>
    <link>http://comments.gmane.org/gmane.comp.hardware.texas-instruments.msp430.gcc.user/10544</link>
    <description>&lt;pre&gt;Good Morning.

I'm a eletronic technologist, and I have recently stated working with MSP
programming. I'm trying to make an Ide for program MSP430 in C language
using Eclipse, MSPGCC an MSPDebug. Through reseach I realised that you all
works using some of these tools, so I was wondering if you could help me to
continue my work.
I have already installed the MSPdebug and MSPGCC is already working with
Eclipse, but now i don't know which is the best way to proceed to make
eclipse program and debug my chip when I click in the debug butom.

Could you help me, please?

Thanks for the attention.
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________
Mspgcc-users mailing list
Mspgcc-users&amp;lt; at &amp;gt;lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
&lt;/pre&gt;</description>
    <dc:creator>William Antunes da Maia</dc:creator>
    <dc:date>2012-05-16T13:46:58</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.hardware.texas-instruments.msp430.gcc.user/10540">
    <title>Updated Debian/Ubuntu Packages ?</title>
    <link>http://comments.gmane.org/gmane.comp.hardware.texas-instruments.msp430.gcc.user/10540</link>
    <description>&lt;pre&gt;Is there any timeline for updated debian or Ubuntu packages based on
the current LTS Relaease?

The packages available out there are still based on the old 20110612 release.

&lt;/pre&gt;</description>
    <dc:creator>Hans Henry von Tresckow</dc:creator>
    <dc:date>2012-05-16T07:56:17</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.hardware.texas-instruments.msp430.gcc.user/10537">
    <title>mspgcc development release 20120514 now available</title>
    <link>http://comments.gmane.org/gmane.comp.hardware.texas-instruments.msp430.gcc.user/10537</link>
    <description>&lt;pre&gt;Development release 20120514 of mspgcc is now available.

This is a development release.  It's being made to clear up a few reported
issues in 20120425 without announcing any new capabilities.  It also
incorporates a major rework of the gcc infrastructure that is required
because gcc never intended sizeof(void*) to differ from sizeof(void(*)()),
and generally isn't prepared to deal with pointers of different sizes.

The patch bundle for 20120514 is available at:

 https://sourceforge.net/projects/mspgcc/files/mspgcc/DEVEL-4.7.x

The tag workspace/release/20120514 in
git://mspgcc.git.sourceforge.net/gitroot/mspgcc/mspgcc checks out a
workspace configured for this release.  The tag workspace/master checks out
a workspace configured for the development series.

Downstream packagers: please don't bundle this.  It's so experimental, only
people who are build from source should be playing with it.  The stable series
remains LTS-20120406.

As usual, please submit problems as tracker tickets at:
https://sourceforge.net/tracker/?group_id=42303&amp;amp;atid=432701

Summary of changes in mspgcc release 20120514 since release 20120425

binutils: changes from binutils-2.22-20120407 to binutils-2.22-20120514:
 - afddce7 [2012-05-14 20:04:59 -0500] Update DEV-PHASE for release
 - 17d6d5d [2012-04-27 11:08:16 -0500] Complete set of far sections
 - de75aa8 [2012-04-27 11:03:19 -0500] Eliminate PROVIDE from symbols
user should not be overriding

gcc: changes from gcc-4.7.0-20120425 to gcc-4.7.0-20120514:
 - 93f6ce9 [2012-05-14 20:04:18 -0500] Update DEV-PHASE for release
 - 822bc1e [2012-04-30 12:59:17 -0500] Add pointer_mode and
address_mode to mem_attrs
 - ac85f5a [2012-04-30 10:57:02 -0500] Add hooks to override pointer
and address modes based on type trees.
 - 5f4ab69 [2012-04-30 18:44:31 -0500] Remove gratuitous passing of
function through memory_address
 - 94215a2 [2012-04-26 14:20:39 +0000] Back-port upstream fix for PR
middle-end/52940
 - 9bc61d1 [2012-04-26 11:52:28 -0500] Revert "Anticipatory patch for
PR middle-end/52940"
 - e83c38a [2012-04-27 07:25:30 -0500] Back-port upstream fix for PR
c/51527 and PR middle-end/53103
 - e127602 [2012-04-24 14:48:07 -0500] Anticipatory patch for PR
middle-end/53104
 - 57f54ee [2012-05-14 20:03:46 -0500] Revert "Anticipatory patch for
PR middle-end/53103"
 - a94ef9d [2012-05-14 20:03:41 -0500] Revert "Anticipatory patch for
PR middle-end/53104"
 - 3172e71 [2012-05-14 19:48:59 -0500] Update for release
 - bd70d32 [2012-05-14 18:11:18 -0500] Run everything through indent
 - cd3c885 [2012-05-14 11:26:38 -0500] fix -Wformat-security issue
 - dcb0ec7 [2012-05-14 11:23:59 -0500] SF 3514303 fix popmhi2 cc attr
 - eecc868 [2012-05-13 20:18:36 -0500] Prevent bogus truncation from SI to PSI
 - a19b694 [2012-05-12 14:52:41 -0500] Accept post-increment source for movpsi
 - d2f5b16 [2012-05-05 15:01:30 -0500] Use type-specific attributes to
determine SR20 and C20 symbol flags and modes
 - 5578c1c [2012-05-05 13:23:49 -0500] Convert c20 and c16 to type attributes
 - de6e54d [2012-05-04 04:56:30 -0500] Refactor attributes
 - d8e54aa [2012-05-04 04:49:17 -0500] Cleanup build warnings
 - 393ff98 [2012-05-03 08:46:02 -0500] Implement core of -md20 and -ma20
 - 144b514 [2012-05-03 08:42:36 -0500] Avoid errors extending 20-bit
symbolic address
 - 8f405f2 [2012-05-01 03:53:27 -0500] Use target hooks for
type-specific pointer modes
 - 65cc562 [2012-05-01 04:35:13 -0500] Add target switch -misr20
 - 1802b2a [2012-05-01 04:11:42 -0500] Stop filtering warnings on
mis-use of a20 attribute
 - d02eb40 [2012-04-30 08:32:10 -0500] Refactor to share attribute
name match between modules
 - 63dd0b2 [2012-04-29 11:36:55 -0500] Treat PSImode as fully
supported for scalar operations
 - d7a2602 [2012-04-29 11:09:05 -0500] First pass at c20 support
 - 1b404d1 [2012-04-27 03:40:38 -0500] Define remaining
(unimplemented) CPUX target options
 - d000415 [2012-04-28 11:01:46 -0500] Avoid adding inconsistent
attributes to function declarations
 - 4fb46b9 [2012-04-28 10:12:09 -0500] Prepare to move fndecl
attribute validation to handler
 - 4a21ef9 [2012-04-27 03:27:54 -0500] Rename preprocessor flags
identifying CPUX target options

gdb: no changes

msp430-libc: changes from msp430libc-20120425 to msp430libc-20120514:
 - 71fabf2 [2012-05-14 20:05:31 -0500] Regenerate
 - a68a1e2 [2012-05-14 20:05:31 -0500] Update version number and release notes
 - e148cd1 [2012-05-14 09:29:37 -0500] SF 3526556 int20_t through
varargs not sign extended
 - 20281a1 [2012-05-03 12:41:36 -0500] Update setjmp/longjmp for 430X
enhancements
 - fc1bcb4 [2012-05-02 02:44:40 -0500] isr_compat.h: inhibit effect of
-mc20 on interrupt declarations
 - fdf85cf [2012-05-01 12:10:25 -0500] Add -ma20 overrides
 - c83d6e3 [2012-05-01 11:43:19 -0500] SF 3522752 malloc return null problem
 - 8c8393e [2012-04-28 12:23:30 -0500] Support -mc20
 - f0cf2e9 [2012-04-27 14:38:08 -0500] Add -fdata-sections and
-ffunction-sections
 - 15134f2 [2012-04-27 03:26:28 -0500] Rename preprocessor flags
identifying compiler options

msp430mcu: changes from msp430mcu-20120425 to msp430mcu-20120514:
 - f3fbec9 [2012-05-14 20:06:02 -0500] Regenerate
 - 343605f [2012-05-14 20:05:55 -0500] Update version number and release notes
 - 6aa7fcd [2012-04-27 14:38:31 -0500] SF 3522088 msp430mcu install.sh
misses a mkdir
 - 24f7728 [2012-04-27 10:40:26 -0500] Regenerate
 - b36473a [2012-04-27 10:40:15 -0500] genmem.py: update region aliases
 - ca78c1d [2012-04-27 02:53:08 -0500] Regenerate
 - cff0e23 [2012-04-27 02:52:06 -0500] Generate constants for CPUX
target flags in msp430.h

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
&lt;/pre&gt;</description>
    <dc:creator>Peter Bigot</dc:creator>
    <dc:date>2012-05-15T02:12:24</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.hardware.texas-instruments.msp430.gcc.user/10535">
    <title>ptrdiff_t is 32bit, intended?</title>
    <link>http://comments.gmane.org/gmane.comp.hardware.texas-instruments.msp430.gcc.user/10535</link>
    <description>&lt;pre&gt;Dear all,

Is it really intended that ptrdiff_t is 32bit?
I guess not, because the "gcc47: 20-Bit Design" states:
"Memory model target options are accepted only when building for
CPUX-capable MCUs. Compilation for non-CPUX MCUs effectively uses the
small memory model."
And before that about the small memory model was stated:
"size_t and ptrdiff_t are 16 bits, and no data object may exceed 32767 bytes."

I am referring to mspgcc-20120406-p20120502 (non-CPUX)

For a quick check how msp430-gcc is configured:
$ msp430-gcc -dM -E - &amp;lt; /dev/null | grep PTRDIFF
#define __PTRDIFF_MAX__ 2147483647L
#define __SIZEOF_PTRDIFF_T__ 4
#define __PTRDIFF_TYPE__ long int

In contrast to the AVR gcc:
$ avr-gcc -dM -E - &amp;lt; /dev/null | grep PTRDIFF
#define __PTRDIFF_MAX__ 32767
#define __SIZEOF_PTRDIFF_T__ 2
#define __PTRDIFF_TYPE__ int

I came across this issue when looking at the generated code for int
pointer subtraction. Surprisingly huge code, because a sign extension
and a 32bit subtraction was performed.
However when dealing with a char pointers subtraction (being casted
into an int result) the 32bit operations are optimized away. That
might explain why this has not been noticed yet.

Regards,
Guido

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
&lt;/pre&gt;</description>
    <dc:creator>Guido Muesch</dc:creator>
    <dc:date>2012-05-14T21:19:00</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.hardware.texas-instruments.msp430.gcc.user/10532">
    <title>__udivmodsi4 missing at link</title>
    <link>http://comments.gmane.org/gmane.comp.hardware.texas-instruments.msp430.gcc.user/10532</link>
    <description>&lt;pre&gt;  hello everyone,

  i've been trying to move from the old mspgcc4 version to the current LTS one for an on-going project, but there is a problem at the final link stage : __udivmodsi4 is missing for vuprintf

/opt/mspgcc/lib/gcc/msp430/4.6.3/../../../../msp430/lib/libc.a(vuprintf.o): In function `vuprintf':
/mspgcc/msp430-libc-20120224/src/./stdlib/vuprintf.c:549: undefined reference to `__udivmodsi4'
/mspgcc/msp430-libc-20120224/src/./stdlib/vuprintf.c:549: undefined reference to `__udivmodsi4'
/mspgcc/msp430-libc-20120224/src/./stdlib/vuprintf.c:552: undefined reference to `__udivmodhi4'
/mspgcc/msp430-libc-20120224/src/./stdlib/vuprintf.c:552: undefined reference to `__udivmodhi4'

  this symbol can be found in gcc-4.4.5/gcc/config/msp430/libgcc.S in the old mspgcc4 source that i built some time ago, but not any more in the new version based on 4.6.3, although the symbol appears in many object files of the msp430-libc

  btw, i followed these directions to build the tool chain
http://sourceforge.net/apps/mediawiki/mspgcc/index.php?title=Install:fromsource

  the same problem was reported in this mail on the list
From: Aljaž Srebrnič &amp;lt;a2piratesoft&amp;lt; at &amp;gt;gmail.com&amp;gt;
Subject: [Mspgcc-users] Portfiles completed
Date: 6 jan 2012 11:12:54 HNEC

  is this a mistake on my side ? a problem somewhere in the build process ? in mspgcc ?

  cheers,

&lt;/pre&gt;</description>
    <dc:creator>Franck Rousseau</dc:creator>
    <dc:date>2012-05-11T13:46:27</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.hardware.texas-instruments.msp430.gcc.user/10531">
    <title>msp430-objcopy for arm</title>
    <link>http://comments.gmane.org/gmane.comp.hardware.texas-instruments.msp430.gcc.user/10531</link>
    <description>&lt;pre&gt;Hi,
Did anyone tried to install and use the binutils, especially the
msp430-objcoy on a sheevaPlug (Plug computer - ARM based)? The armel
distribution binaries fail with seg fault....

- Tal



------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
&lt;/pre&gt;</description>
    <dc:creator>Tal Anker</dc:creator>
    <dc:date>2012-05-10T12:14:30</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.hardware.texas-instruments.msp430.gcc.user/10529">
    <title>error when installing msp430-gcc</title>
    <link>http://comments.gmane.org/gmane.comp.hardware.texas-instruments.msp430.gcc.user/10529</link>
    <description>&lt;pre&gt;Hello,
Using tutorials on net, i tried to install msp430-gcc.
these are the steps i did:

1)sudo apt-get install subversion gcc-4.4 texinfo patch
libncurses5-dev zlibc zlib1g-dev libx11-dev libusb-dev
libreadline6-dev
2)svn checkout https://mspgcc4.svn.sourceforge.net/svnroot/mspgcc4
3)cd mspgcc4
4)sudo ./buildgcc.sh
5)I accepted all the the default (no selection) until i'm asked to
start the build [default NO], i did yes:
then i get this error:

config.status: executing default commands
make[2]: entrant dans le répertoire « /mspgcc4/build/binutils-2.20.1-build/bfd »
Making info in doc
make[3]: entrant dans le répertoire «
/mspgcc4/build/binutils-2.20.1-build/bfd/doc »
make chew
make chew
make[4]: entrant dans le répertoire «
/mspgcc4/build/binutils-2.20.1-build/bfd/doc »
make[4]: entrant dans le répertoire «
/mspgcc4/build/binutils-2.20.1-build/bfd/doc »
make[4]: « chew » est à jour.
make[4]: « chew » est à jour.
make[4]: quittant le répertoire « /mspgcc4/build/binutils-2.20.1-build/bfd/doc »
make[4]: quittant le répertoire « /mspgcc4/build/binutils-2.20.1-build/bfd/doc »
./chew -f /mspgcc4/build/binutils-2.20.1-build/../binutils-2.20.1/bfd/doc/doc.str
 &amp;lt;/mspgcc4/build/binutils-2.20.1-build/../binutils-2.20.1/bfd/doc/../opncls.c
./chew -f /mspgcc4/build/binutils-2.20.1-build/../binutils-2.20.1/bfd/doc/doc.str
&amp;lt;/mspgcc4/build/binutils-2.20.1-build/../binutils-2.20.1/bfd/doc/../reloc.c
/bin/bash : ligne 1 : 26675 Erreur de segmentation  ./chew -f
/mspgcc4/build/binutils-2.20.1-build/../binutils-2.20.1/bfd/doc/doc.str
&amp;lt; /mspgcc4/build/binutils-2.20.1-build/../binutils-2.20.1/bfd/doc/../opncls.c
/bin/bash : ligne 1 : 26676 Erreur de segmentation  ./chew -f
/mspgcc4/build/binutils-2.20.1-build/../binutils-2.20.1/bfd/doc/doc.str
&amp;lt; /mspgcc4/build/binutils-2.20.1-build/../binutils-2.20.1/bfd/doc/../reloc.c
make[3]: *** [opncls.texi] Erreur 139
make[3]: *** Attente des tâches non terminées....
make[3]: *** [reloc.texi] Erreur 139
make[3]: quittant le répertoire « /mspgcc4/build/binutils-2.20.1-build/bfd/doc »
Making info in po
make[3]: entrant dans le répertoire «
/mspgcc4/build/binutils-2.20.1-build/bfd/po »
make[3]: Rien à faire pour « info ».
make[3]: quittant le répertoire « /mspgcc4/build/binutils-2.20.1-build/bfd/po »
make[3]: entrant dans le répertoire « /mspgcc4/build/binutils-2.20.1-build/bfd »
make[3]: Rien à faire pour « info-am ».
make[3]: quittant le répertoire « /mspgcc4/build/binutils-2.20.1-build/bfd »
make[2]: *** [info-recursive] Erreur 1
make[2]: quittant le répertoire « /mspgcc4/build/binutils-2.20.1-build/bfd »
make[1]: *** [all-bfd] Erreur 2
make[1]: quittant le répertoire « /mspgcc4/build/binutils-2.20.1-build »
make: *** [all] Erreur 2
sh do-binutils.sh "/opt/msp430-gcc-4.4.3" "2.20.1"
"http://ftp.uni-kl.de" "build" exited with status code 2.
Failed to execute sh do-binutils.sh "/opt/msp430-gcc-4.4.3" "2.20.1"
"http://ftp.uni-kl.de" "build" at ./buildgcc.pl line 262, &amp;lt;STDIN&amp;gt; line
9.


Can any one help me to fix it Please, i'm stuck there since a while ..
Regards,
Asma
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________
Mspgcc-users mailing list
Mspgcc-users&amp;lt; at &amp;gt;lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
&lt;/pre&gt;</description>
    <dc:creator>asma bel hadj med</dc:creator>
    <dc:date>2012-05-08T21:47:34</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.hardware.texas-instruments.msp430.gcc.user/10517">
    <title>Linker script questions</title>
    <link>http://comments.gmane.org/gmane.comp.hardware.texas-instruments.msp430.gcc.user/10517</link>
    <description>&lt;pre&gt;We have an older project at my work where we use the TI BSL loaded to
load code over RS-232.  Our code is broken up into two categories a
configuration file and a firmware file and they are both loaded together.

The configuration file is a list of constants stored in flash and
specific addresses and they are unique for each of our customers, but
the firmware file is the same.

The code we have now was written with IAR, and I'm trying to port it
over to mspgcc.

What I'd like to be able to do is compile the firmware with the linker
script specifying certain addresses of data, but I don't want the
compiler to actually put any data at those locations.

For the configuration, I'd like to just compile the constant variables
without firmware.

The problem I see is that GCC initializes the constant variables in the
FW which I have to go and manually delete because those constants are
loaded from a separate txt file.  I'd like to have that more streamlined
technique to build both.  Any ideas on the best way to do that?

thanks

adam

This email, including any attachments and files transmitted with it, are for the sole use of the intended recipient(s) to whom this email is addressed, and may contain confidential and/or privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please be advised that you have received this email in error, and please contact the sender by reply email and destroy all copies (including all electronic and hard copies) of the original message. Thank you.

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
&lt;/pre&gt;</description>
    <dc:creator>Adam Ford</dc:creator>
    <dc:date>2012-05-04T19:38:04</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.hardware.texas-instruments.msp430.gcc.user/10516">
    <title>MSPDebug Segmentation Fault</title>
    <link>http://comments.gmane.org/gmane.comp.hardware.texas-instruments.msp430.gcc.user/10516</link>
    <description>&lt;pre&gt;Hello, 

Is there any known issues where MSPDebug in Windows (compiled in cygwin with mingw and ran with cygwin) would throw a segmentation fault when issuing "mspdebug.exe rf2500 erase 'prog bin.elf' "? If not, what could be the problem? I have tried looking for this in Google, but couldn't find anything related.

I don't have the actual output here, it happened to someone during a workshop I was doing to get some guys started with the Launchpad, but I can ask him to run some commands.

Best regards,
---------------------------------------
Sergio Campamá
sergiocampama&amp;lt; at &amp;gt;gmail.com





------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
&lt;/pre&gt;</description>
    <dc:creator>Sergio Campamá</dc:creator>
    <dc:date>2012-05-04T13:07:11</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.hardware.texas-instruments.msp430.gcc.user/10514">
    <title>LTS/20120406 patch updates</title>
    <link>http://comments.gmane.org/gmane.comp.hardware.texas-instruments.msp430.gcc.user/10514</link>
    <description>&lt;pre&gt;The first set of patches for LTS release 20120406 is now available on
SourceForge at
http://sourceforge.net/projects/mspgcc/files/Patches/LTS/20120406/

Neither of these are particularly critical, unless you run into them.

Downstream packagers: Please note the text in the README at
http://sourceforge.net/projects/mspgcc/files/Patches/LTS/ regarding how to
mark patched releases of mspgcc.  This is the first release to which this
practice applies; if you have problems with it, let me know.

msp430-libc-20120224-sf3522752 "malloc return null problem"
(https://sourceforge.net/tracker/?func=detail&amp;amp;aid=3522752&amp;amp;group_id=42303&amp;amp;atid=432701)

malloc() may fail to detect when it has run out of memory, and may end up
overwriting the call stack.  It would also use memory that was reserved for
no-init sections.  This bug is likely to have been present for as long as
msp430-libc has existed.

msp430mcu-20120406-sf3522088 "msp430mcu install.sh misses a mkdir"
(https://sourceforge.net/tracker/?func=detail&amp;amp;aid=3522088&amp;amp;group_id=42303&amp;amp;atid=432701)

msp430mcu's install script didn't create the bin directory before installing
files into it.

As usual, please submit problems as tracker tickets at:
https://sourceforge.net/tracker/?group_id=42303&amp;amp;atid=432701

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
&lt;/pre&gt;</description>
    <dc:creator>Peter Bigot</dc:creator>
    <dc:date>2012-05-02T18:42:06</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.hardware.texas-instruments.msp430.gcc.user/10507">
    <title>Slow execution with MSPDebug,using tilib driver (msp430.dll v3)</title>
    <link>http://comments.gmane.org/gmane.comp.hardware.texas-instruments.msp430.gcc.user/10507</link>
    <description>&lt;pre&gt;Hi,

I have been doing a bit of work on MSPDebug over the weekend trying to 
figure out a few issues I've been having. The one problem I can't solve 
is when using msp430-gdb and mspdebug, the code executes about ten times 
slower than it should (when using the new tilib driver which makes use 
of TI's new MSP430.dll v3).

During my testing I have determined that following a call to 
MSP430_Memory(....., READ); the execution speed will be slow. The first 
thing GDB does when connecting to the target is read the memory at the 
PC, which means it will always run slow after that. MSPDebug will run 
slow after the first run, ctrl+c combination, as it will read and 
disassemble the current function when you press ctrl+c.

I am on windows 7 32bit using version 3.2.3.15 of msp430.dll (from 
msp430.dll_developer_package_rev_3.02.003.015.zip).

I was wondering if anybody had run into similar issues? I will try 
duplicating the issue on my work PC tomorrow before I start making noise 
in the E2E forums.

Thanks,

- Wayne

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
&lt;/pre&gt;</description>
    <dc:creator>Wayne Uroda</dc:creator>
    <dc:date>2012-04-29T13:52:37</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.hardware.texas-instruments.msp430.gcc.user/10500">
    <title>Problem/Regression? placing 10k array into .fartextsection</title>
    <link>http://comments.gmane.org/gmane.comp.hardware.texas-instruments.msp430.gcc.user/10500</link>
    <description>&lt;pre&gt;Hi

After updating from the 2011 LTS to the new LTS version, my code to place a 10k array into . fartext section fails.

The source file looks like this:

__attribute__((section (".fartext")))
const uint8_t cc256x_init_script[] = { 0x00, ... roughly 10k of data ... };
const uint32_t cc256x_init_script_size = sizeof(cc256x_init_script);

I get this error:

msp430-gcc -mmcu=msp430f5438a -g -Os -Wall -I. -I../src -I../firmware -I../.. -I../../chipset-cc256x -I../../src -I../../include   -c -o ../../chipset-cc256x/bluetooth_init_cc2560A_1.7.o ../../chipset-cc256x/bluetooth_init_cc2560A_1.7.c

msp430-gcc ../../chipset-cc256x/bluetooth_init_cc2560A_1.7.o main.o -mmcu=msp430f5438a -o led_counter.out
../../chipset-cc256x/bluetooth_init_cc2560A_1.7.o:(.debug_info+0x8e): relocation truncated to fit: R_MSP430_16_BYTE against symbol `cc256x_init_script' defined in .fartext section in ../../chipset-cc256x/bluetooth_init_cc2560A_1.7.o
collect2: ld returned 1 exit status

Is there something I'm doing wrong, or, is this a regression and I should file an item in the bug tracker?

(complete project is here: btstack.org in /btstack/MSP-EXP430F5438-CC256x/example)

Best
 Matthias 
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
&lt;/pre&gt;</description>
    <dc:creator>Matthias Ringwald</dc:creator>
    <dc:date>2012-04-27T19:19:54</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.hardware.texas-instruments.msp430.gcc.user/10491">
    <title>Draft 20-Bit Design/Interface Specificationavailable for review</title>
    <link>http://comments.gmane.org/gmane.comp.hardware.texas-instruments.msp430.gcc.user/10491</link>
    <description>&lt;pre&gt;The first draft of the design specification for 20-bit support in
mspgcc has been added to the wiki at:

https://sourceforge.net/apps/mediawiki/mspgcc/index.php?title=Gcc47:20-Bit_Design

Interested parties are invited to read the document on the wiki, and
comment on this mailing list.

The specification focuses on the atomic capabilities which combine to
form what's normally called a "memory model".  They are highly
orthogonal, although some combinations are likely to result in
unexpected (i.e., buggy) behavior.

I specifically invite comment on exactly what memory models should be
supported by roll-up options that enable/disable the individual
features described on that page, and what compiler option will
identify them.  (It'd be something like "-mmodel=large", but what
exactly should "large" mean?)  Preferably the naming and semantics of
these models should tie back to existing practice in other MSP430
toolchains or other GCC back-ends.

At this time, I believe what's described is technically possible, but
the management of the namespaces, correct specification of pointer
types based on code and options, and exactly how to get the linker to
assign data and function objects into the split address space are yet
to be implemented, and some showstopper issue might arise.  (As far as
I can tell nobody's ever made binutils support a split address space
before.  Getting 20-bit integers to work produced five bug reports
against upstream gcc so far, all of which have been fixed in mspgcc
with at least one already fixed upstream as well.)

Peter

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
&lt;/pre&gt;</description>
    <dc:creator>Peter Bigot</dc:creator>
    <dc:date>2012-04-26T21:31:19</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.hardware.texas-instruments.msp430.gcc.user/10490">
    <title>mspgcc development release 20120425 now available</title>
    <link>http://comments.gmane.org/gmane.comp.hardware.texas-instruments.msp430.gcc.user/10490</link>
    <description>&lt;pre&gt;Development release 20120425 of mspgcc is now available.

This is a development release.  It begins the path to 20-bit support by
adding int20_t and uint20_t: these are implemented under the covers by a new
type attribute __a20__ which indicates that the 32-bit type it attaches to
maintains only 20 bits of precision, uses a single 20-bit register, but two
words when placed in memory.  It is available via &amp;lt;stdint.h&amp;gt; when compiling
with -mcpu=430x (which is implied by any -mmcu option that identifies a 430X
CPU).

The purpose of this type is primarily to simplify validation of the sorts of
operations that will be needed for 20-bit pointers, but it may also come in
handy when a little extra precision is required.  An example of use:

 #include &amp;lt;inttypes.h&amp;gt;
 #include &amp;lt;stdio.h&amp;gt;

 uint16_t vals[] = { 1, 2, 3, 4, 5, 6, 7, 8, 9,
    0x8001, 0x8002, 0x8002, 0x8004, 0x8005,
    0xf000 };
 void main (void)
 {
   int i;
   uint20_t sv;

   sv = 0;
   for (i = 0; i &amp;lt; sizeof(vals)/sizeof(*vals); ++i) {
     sv += vals[i];
     printf("Add %04" PRIx16 " produces %05" PRIx20 "\n", vals[i], sv);
   }
 }

 Add 0001 produces 00001
 Add 0002 produces 00003
 Add 0003 produces 00006
 Add 0004 produces 0000a
 Add 0005 produces 0000f
 Add 0006 produces 00015
 Add 0007 produces 0001c
 Add 0008 produces 00024
 Add 0009 produces 0002d
 Add 8001 produces 0802e
 Add 8002 produces 10030
 Add 8002 produces 18032
 Add 8004 produces 20036
 Add 8005 produces 2803b
 Add f000 produces 3703b

(Careful experimenters will notice that the generated code in this case
includes unnecessary register moves.  Should somebody care to document this
in a ticket, I'll try to take a look; at the moment, correctness is what I'm
after, and speed can follow at a later time.)

More examples are in the mspgcc repository in the tests/master branch.

Companion to attribute __a20__ is a pair of function attributes __sr16__ and
__sr20__, which cause any callee-saved registers within the function to
be preserved to 16 (default, historical) or 20 (new) bits.  As a general
rule (but not enforced), if you are using __a20__ values you'll want to add
-msr20 to your compiler flags so that the values aren't clobbered in
function calls (including interrupts).

Finally, this release introduces the mechanism by which compilation features
can be identified within the source at compile-time.  The __MSP430X__
preprocessor symbol, historically defined only for CPUX-compatible MCUs, now
contains the same value as __MSP430_CPU__ but also encodes bits indicating
CPUX-related compilation features.  For example:

#if __MSP430X__ &amp;amp; __MSP430_CPUX_FEATURE_SR20__
       pushm.a #2, r11
#elif __MSP430X__
       pushm   #2, r11
#else /* CPUX */
       push    r11
       push    r10
#endif /* CPUX */

A persistent version of the above documentation, as well as an outline of
the similar attributes and compiler options that will enable use of 20-bit
values as pointers, will be appearing on the mspgcc wiki over the next week
or so.

The patch bundle for 20120425 is available at:

 https://sourceforge.net/projects/mspgcc/files/mspgcc/DEVEL-4.7.x

The tag workspace/release/20120425 in
git://mspgcc.git.sourceforge.net/gitroot/mspgcc/mspgcc checks out a
workspace configured for this release.  The tag workspace/master checks out
a workspace configured for the development series.

Downstream packagers: please don't bundle this.  It's so experimental, only
people who are build from source should be playing with it.  The stable series
remains LTS-20120406.

As usual, please submit problems as tracker tickets at:
https://sourceforge.net/tracker/?group_id=42303&amp;amp;atid=432701

Summary of changes in mspgcc release 20120425 since release 20120407

binutils: no changes

gcc: changes from gcc-4.7.0-20120407 to gcc-4.7.0-20120425:
 - 5ff0c47 [2012-04-25 03:36:18 -0500] Update DEV-PHASE for release
 - 150e88f [2012-04-24 14:48:07 -0500] Anticipatory patch for PR
middle-end/53104
 - 086a2c8 [2012-04-24 13:54:22 -0500] Anticipatory patch for PR
middle-end/53103
 - 519cc89 [2012-04-11 18:10:41 -0500] Anticipatory patch for PR
middle-end/52940
 - 770d836 [2012-04-09 17:29:18 -0500] Anticipatory patch for PR
middle-end/52919
 - cdf7d6e [2012-04-03 16:44:16 -0500] Anticipatory patch for PR
middle-end/52856
 - cffacc3 [2012-04-25 02:31:46 -0500] Update for release
 - fcf6556 [2012-04-23 17:40:08 -0500] Support extend from psi, and
truncate to/from psi
 - c9c18ad [2012-04-24 13:56:32 -0500] Support zero-extend load byte
into PSI as well as HI reg
 - a0a3396 [2012-04-10 17:29:34 -0500] SF 3512818 rework rotate to use
430x repeat feature
 - fccc558 [2012-04-09 20:12:20 -0500] Support shift to PREC-1 for PSImode
 - 1e49a19 [2012-04-11 11:14:37 -0500] Add CPUX repeated instruction support
 - 13e444c [2012-04-08 11:42:29 -0500] Support saving 20-bit registers
within functions
 - fad4a26 [2012-04-03 12:35:29 -0500] Partially working support for
a20 comparisons
 - 2e42b9f [2012-04-03 09:36:53 -0500] Correct instruction lengths for
extended instructions
 - f67b68c [2012-04-03 08:11:05 -0500] Incomplete support for passing
a20 args around in functions
 - 64b825f [2012-04-02 17:59:55 -0500] Add PSImode as 20-bit integer
via __a20__ attribute on long int
 - 926fe46 [2012-04-02 14:55:47 -0500] Uniformly use TARGET_CPUX when
mcu has CPUX support

gdb: no changes

msp430-libc: changes from msp430libc-20120224 to msp430libc-20120425:
 - f7aa387 [2012-04-25 02:41:38 -0500] Regenerate
 - 5503065 [2012-04-25 02:41:38 -0500] Update version number and release notes
 - 3904c1d [2012-04-08 15:13:10 -0500] Add -msr20 recognition to
assembly sources
 - 5851e48 [2012-03-06 08:54:22 -0600] Add int20_t support

msp430mcu: changes from msp430mcu-20120407 to msp430mcu-20120425:
 - efd322e [2012-04-25 02:42:37 -0500] Regenerate
 - 56f216c [2012-04-25 02:42:30 -0500] Update version number and release notes
 - c4cde23 [2012-04-03 09:53:36 -0500] Add __a20__ to 20-bit
peripheral register declarations

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
&lt;/pre&gt;</description>
    <dc:creator>Peter Bigot</dc:creator>
    <dc:date>2012-04-25T14:56:44</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.hardware.texas-instruments.msp430.gcc.user/10476">
    <title>Reserving stack space at compile time?</title>
    <link>http://comments.gmane.org/gmane.comp.hardware.texas-instruments.msp430.gcc.user/10476</link>
    <description>&lt;pre&gt;Howdy.
I recently ran into an issue with my program stack growing into the
statically-allocated variables in the .bss section due to some
overenthusiastic use of printf's. Looking through the archives, I found this
discussion&amp;lt;http://www.mail-archive.com/mspgcc-users&amp;lt; at &amp;gt;lists.sourceforge.net/msg10178.html&amp;gt;
regarding
general stack protection techniques.

Two questions, which may be more general gcc/ld-related than msp-specific

1. While it's impossible in the general case to determine the maximum stack
size that a program will use, is there any mspgcc setting (or standalone
tool) that can handle the simple cases that dominate in MCUs (no recursion,
no function pointers, no nested ISRs) and spit out a maximum stack depth?


2. Failing that, what is the preferred method for indicating that X bytes
should be reserved at the top of RAM, and violations of this should result
in a linker error? It looks like the .noinit section gets placed where I
want it, so I see a couple of options:

a. Use the RESERVE_RAM
annotation&amp;lt;http://mspgcc.sourceforge.net/manual/x1023.html&amp;gt; on
the main method. This is somewhat undesirable to me because I'm working in
TinyOS and this would introduce what seems to be an msp-gcc specific change
to an otherwise platform-independent core file. It's not a deal-breaker,
but I'd like to avoid it if possible. Unless avr-gcc supports this and I'm
just not finding it in the documentation.

b. Use the section attribute, something like this:
char __attribute__ ((section(".noinit"))) stack_space[RESERVED_STACK_SIZE];

where RESERVED_STACK_SIZE is based on either observation or the type of
analysis described above. This appears to be somewhat supported by
avr-gcc&amp;lt;http://nongnu.org/avr-libc/user-manual/mem_sections.html#sec_dot_noinit&amp;gt;
.

c. Some unknown-to-me command in the linker script that forces a particular
section to be of a given size, regardless of what symbols are actually
supposed to be placed there.


Any suggestions would be most appreciated.

Thanks!
Doug Carlson
------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2_______________________________________________
Mspgcc-users mailing list
Mspgcc-users&amp;lt; at &amp;gt;lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
&lt;/pre&gt;</description>
    <dc:creator>Doug Carlson</dc:creator>
    <dc:date>2012-04-19T12:37:00</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.hardware.texas-instruments.msp430.gcc.user/10462">
    <title>Stack push inside inline assembly</title>
    <link>http://comments.gmane.org/gmane.comp.hardware.texas-instruments.msp430.gcc.user/10462</link>
    <description>&lt;pre&gt;Hi,

I feel quite foolish asking the following question... Please don't judge me too harshly...

In my MSPGCC based system I have got the following #defines which I use for critical (interrupts disabled) access around volatile memory which is modified by interrupt routines:

#define criticalStart() __asm__ __volatile__("push r2"::); __asm__ __volatile__("dint"::)
#define criticalEnd() __asm__ __volatile__("pop r2"::)

Usually I use this code to write to a counter which is decremented by my timer ISR, eg

void setTimeout(UInt16 timeout)
{
    // Other work before setting the volatile, ISR driven value
    criticalStart();
    busyTimeout = timeout;
    criticalEnd();
}

Today I am using Code composer for a new project and I tried a similar trick. After several hours of debugging, it turns out that my little "push r2" trick causes code composer to access local variables incorrectly, since these are accessed relative to the stack pointer.

For example, the following code does not function correctly because the "localTimer" variable is not written correctly (the memory access is one word off owing to the extra stack push).

while(true)
{
    UInt32 localTimer;
    criticalStart();
    localTimer = globalTimer;
    criticalEnd();
    if (localTimer == 0)
    {
        break;
    }
}


My question is, does GCC analyse the inline assembly code and notice that I have altered the stack, or have I just been *extremely* lucky for many years? Certainly code composer does not see that I have modified the stack.

I am going to change my critical macros like so (this is how I am now doing critical access in code composer, which, unless I am missing something, has no builtin way to do critical functions):

#define criticalStart() { UInt16 __oldInterruptStatus__ = READ_SR(); __asm__ __volatile__("dint"::)
#define criticalEnd() WRITE_SR(__oldInterruptStatus__); }

Any major issues with doing this? Should I instead wrap all reads and writes to volatile memory/variables with critical functions? I usually only wrap one line of code with the critical macros.

Also if anybody knows code composer v3.1 and knows a better way, please let me know.
Thanks,


-          Wayne
------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second 
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev_______________________________________________
Mspgcc-users mailing list
Mspgcc-users&amp;lt; at &amp;gt;lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
&lt;/pre&gt;</description>
    <dc:creator>Wayne Uroda</dc:creator>
    <dc:date>2012-04-17T07:53:08</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.hardware.texas-instruments.msp430.gcc.user/10457">
    <title>Newbie needs help: mspdebug v0.19 on OS X,FET430UIF and 5438A experimenter board</title>
    <link>http://comments.gmane.org/gmane.comp.hardware.texas-instruments.msp430.gcc.user/10457</link>
    <description>&lt;pre&gt;I'm pulling out my hair (and I don't have much to lose) trying to get mspdebug to talk to a MSP-EXP430F5438 experimenter board through TI's MSP-FET430UIF. Here's what I'm getting:

$ MSPDEBUG_TI3410_FW=/opt/local/lib/mspdebug/ti_3410.fw.ihex mspdebug -d /dev/tty*FET* uif 
MSPDebug version 0.19 - debugging tool for MSP430 MCUs
Copyright (C) 2009-2012 Daniel Beer &amp;lt;dlbeer&amp;lt; at &amp;gt;gmail.com&amp;gt;
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Trying to open UIF on /dev/tty.MSP-FET430UIF26230...
Initializing FET...
FET protocol version is 20401000
Configured for Spy-Bi-Wire
Set Vcc: 3000 mV
fet: FET returned error code 4 (Could not find device (or device not supported))
fet: command C_IDENT1 failed
fet: identify failed
Trying again...
Initializing FET...
FET protocol version is 20401000
Configured for Spy-Bi-Wire
Sending reset...
uif: read error: Operation timed out
warning: fet: reset failed
uif: read error: Operation timed out
warning: fet: set VCC failed
uif: read error: Operation timed out
fet: command C_IDENT1 failed
fet: identify failed
$ 

Here's my setup:

1. The mac is running Lion (10.7.3)
2. I've installed a tweaked TUSB3410 driver which creates the /dev/tty.MSP-FET… device when the FET is plugged in via USB
3. The 5438 experimenter board is plugged in via a ribbon cable to the FET
4. SW1 (power selector) switch on the experimenter board is all the way left in the "FET" position
5. When the FET powers up, the red LED flashes and goes out, then the green LED comes on solid
6. As soon as mspdebug runs, the red LED on the FET flashes and then stays on
7. The sticker on the back of the FET says v1.4a

Unfortunately, I don't have access to a windows machine (at the moment) so I haven't been able to check things out using official TI software. Suggestions are welcomed and appreciated.

Thanks,

Andy

------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
&lt;/pre&gt;</description>
    <dc:creator>Andy Turk</dc:creator>
    <dc:date>2012-04-15T18:14:21</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.hardware.texas-instruments.msp430.gcc.user/10455">
    <title>New TI v3 driver</title>
    <link>http://comments.gmane.org/gmane.comp.hardware.texas-instruments.msp430.gcc.user/10455</link>
    <description>&lt;pre&gt;Hi all,

TI has recently updated their driver which can be downloaded
here: http://processors.wiki.ti.com/index.php/MSP_Debug_Stack

You will get now the file slac460b.zip (instead of slac460a.zip)
and it refers to the firmware version 3.2.3.15.

The new version still needs a patch on 64Bit systems but I
could build it without the patch on a 32Bit System. 

The patch and the project files can be downloaded here:
http://sourceforge.net/projects/msp4linux/files/

The msp4linux project was updated to support the new lib and
there is a feature back which was once removed with the 
change from 0.3.0 to 0.4.0: the device database extractor.

The v3 driver stores a lot of information about all supported
targets in a internal database which is located in 

.../DLL430_v3/src/TI/DLL430/TemplateDeviceDb

The database extractor tool creates a library which can be
used to list this information. Type simply 'info' to get the
data from the attached target or info [name] to get it for
other targets:

mspdb_v3$ info MSP430F5438A
name            = MSP430F5438A  // target identification name
object_id       = 0     // 
psa_type        = 0     // 
trigger_1       = 8     // 
trigger_2       = 2     // 
trigger_3       = 10    // 
clock           = 2     // clock configuration type
clock_default   = 0x40f // clock configuration register default
state_storage   = 8     // state storage depth (0 for not existing)
cycle_counter   = 2     // cycle counter
cycle_op        = 1     // cycle counter operations
cond_level      = 2     // condition level
comp_level      = 2     // comperator level
emu_level       = 7     // emulation level
tr_op_modes     = 1     // trigger options modes
tr_dma_modes    = 1     // trigger dma modes
tr_rw_modes     = 1     // trigger read/write options modes
tr_reg_tr_op    = 1     // register trigger operation modes
tr_mask         = 0x1   // trigger mask
seq_max_states  = 3     // number of possible sequencer states
seq_start       = 4     // sequencer start value
seq_end         = 0     // sequencer end value
min_vcc         = 1800  // min voltage [mV]
max_vcc         = 3600  // max voltage [mV]
min_flash_vcc   = 1800  // max flash voltage [mV]
min_sec_vcc     = 2500  // [mV]
min_sec_vpp     = 6000  // [mV]
max_sec_vpp     = 7000  // [mV]
has_test_vpp    = 1     // 
quick_mem_read  = 1     // 
psach           = 0     // 
has_fram        = 0     // 
power_test_reg_mask     = 0x0   // 
test_reg_enable_lpm5    = 0x0   // 
test_reg_disable_lpm5   = 0x0   // 
power_test_reg3VMask    = 0x0   // 
test_reg3V_enable_lpm5  = 0x0   // 
test_reg3V_disable_lpm5 = 0x0   // 
sFll            = 0     // 

List of memory sections

main             0x5c00  0x40000 0        4       16     FLASH
information      0x1800  0x200   0        4       16     FLASH
boot             0x1000  0x800   0        4       16     FLASH
bootcode         0x1b00  0x100   0        1       16     ROM
system           0x1c00  0x4000  0        1       16     RAM
peripheral16bit  0x0     0x1000  4096     1       16     REGISTER
CPU              0x0     0x10    0        1       20     REGISTER
EEM              0x0     0x80    0        1       20     REGISTER

This is a very first version of the reworked extractor tool
and will be extended within the next version.

Regards Hubert
&lt;/pre&gt;</description>
    <dc:creator>qbert1&lt; at &gt;gmx.de</dc:creator>
    <dc:date>2012-04-12T20:12:30</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.comp.hardware.texas-instruments.msp430.gcc.user">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.comp.hardware.texas-instruments.msp430.gcc.user</link>
  </textinput>
</rdf:RDF>

