Re: [Mspgcc-users] msp430x1612 header

[Peter Bigot]

The x variants were an early attempt to simplify identifying processors
where part number variation did not affect the compiler, at a time when
the MSP430 product line was quite limited.  Introduction of additional
processor families broke those assumptions, particularly in the need to
vary the addresses and presence of different peripherals.

In 2013 when I last updated msp430mcu (may not have been released) there
were north of 450 distinct chip IDs that affected code generation or
peripheral address.  The generic ID originally spelled msp430x16x
covered six of them.

Peter


On Thu, Mar 30, 2017 at 8:11 PM, Norrathep Rattanavipanon 
wrote:

> Thanks I just found out that I need to include periph.x. Just curious is
> there any difference for x1612 vs f1612 in terms of hardware configuration?
> Or is x1612 just renamed to f1612?
>
> On Thu, Mar 30, 2017 at 4:51 PM, David W. Schultz <
> david.schu...@earthlink.net> wrote:
>
> > On 03/30/2017 06:38 PM, Norrathep Rattanavipanon wrote:
> > > Thank you so much for your help, David. Now it compiles perfectly past
> > > that point but I run into another issue (I'm not sure if this is the
> > > right place to post please let me know if its not):
> > >
> > > /usr/lib/gcc/msp430/4.6.3/../../../../msp430/bin/ld: cannot represent
> > > machine `msp:110'
> > >
> >
> > There should be a linker script available as well in the same location.
> > If you have given the compiler the path to that directory it should find
> > it.
> >
> > -I /usr/ti/gcc/include
> >
> > Is what I use.
> >
> > TI moved a lot of information, like device register addresses, from the
> > .h files into the linker scripts some time ago. You should use the
> > provided linker scripts and they will resolve symbols like WDTCTL.
> >
> > --
> > David W. Schultz
> > http://home.earthlink.net/~david.schultz
> > "Life without stock is barely worth living..." - Anthony Bourdain
> >
> > 
> > --
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > ___
> > Mspgcc-users mailing list
> > Mspgcc-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/mspgcc-users
> >
>
>
>
> --
> Norrathep (Oak) Rattanavipanon
> M.S. in Computer Science
> University of California - Irvine
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Mspgcc-users mailing list
> Mspgcc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] TI compiler

[Peter Bigot]

On Fri, Mar 3, 2017 at 12:30 PM, DJ Delorie  wrote:

> Also, if you're REALLY constrained to size, you might consider getting
> the crt0.S source file from newlib and modifying it yourself to really
> strip out the parts you don't need.  Most embedded code really only
> needs to set up the stack and watchdog, then jump to main().
>

Be careful with this.  TI's Code Composer compiler originally had a
stripped down crt0 that didn't bother clearing the bss section.  This meant
any static variable definition (including globals) would not necessarily be
cleared on power up.  So if you rely on a variable being null to indicate
that some initialization is necessary your program may or may not work.

The advice is also dubious if you're using C++ as there may be static
constructors that need to be invoked (and yes, modern C++ if used carefully
is appropriate for embedded programming even on constrained chips like
MSP430).

In short, if you muck with the crt0 code be very sure you know the effect
of stripping things out.

Peter
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] TI compiler

[Peter Bigot]

I think it's pretty unlikely msp430-libc would work with upstream gcc,
though I admit I haven't tried it.

http://pabigot.github.io/bsp430/msp430elf.html has some outdated
suggestions for building customized newlib and trimming out functionality
that isn't needed.

Glad to know people are still getting value out of mspgcc.  I'm afraid I
haven't even fired it up for a couple years (mostly doing either ARM
Cortex-M or Node.js these days).

Peter

On Fri, Mar 3, 2017 at 8:03 AM, Nick Clifton  wrote:

> Hi Bob,
>
> > As far as I can see, the 'bloat' is in library funcs (newlib?).
>
> If the bloat is indeed in the library funcs why not just compile with
> gcc and then link in the old, mspcc C library instead of newlib ?
>
> Cheers
>   Nick
>
>
>
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> Mspgcc-users mailing list
> Mspgcc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] assembler vs extension words

[Peter Bigot]

Just to note: this list doesn't transport patches.  Sorry.

Peter (still lurking, no longer active)

On Wed, Feb 3, 2016 at 6:29 AM, Nick Clifton  wrote:

> Hi David,
>
> I am having some trouble using the rpt functionality of the CPUX. While
>> attempting to assemble some code for the msp430fr5969 I was surprised
>> with this error:
>>
>> repeat count cannot be used with rrux
>>
>> In response to:
>> rpt r15 { rrux.w r6
>>
>
>
> Oops - this is definitely a bug.  You should report it ... :-)
>
> The problem is that RRUX is a synthetic instruction, and GAS is
> incorrectly checking it as if it were RRUM, which does not accept a RPT
> count.
>
> After some fiddling around I was able to
>> generate code that worked but I had to bang it in using .word
>> directives. objdump produced:
>>
>> rpt r15 { rrcx.wr6
>>
>> Which is almost but not quite correct because it ignores the little
>> detail of the extension word having the ZC bit set.
>>
>
> True - this is really the same bug.  GAS is not encoding RRUX correctly,
> so it is not being decoded correctly either.
>
>
> Which brings up another problem. Not only is the use of rpt not
>> documented for the GNU assembler,
>>
>
> This is because there is no real documentation from TI describing how the
> RPT pseudo-instruction ought to work.  I assumed that they must have an
> "assembler programming for the MSP430 " guide somewhere that described this
> feature, and that I have just not seen it.  In my opinion the GNU assembler
> documentation should not be documenting features that are supposed to be a
> standard part of the architecture's assembler.
>
> there isn't any hint of how to set the
>> ZC bit in the extension word.
>>
>
> It has to be through the use of different opcode mnemonics, ie RRUX vs
> RRCX.
>
>
> slau367 is a bit thin in describing the repeat feature as well. It
>> barely gets a mention in the description of the extension word and
>> appears a few times in examples. Other than that there is nothing.
>>
>
> Agreed - it is very frustrating.
>
> There is also very little documentation on synthetic instructions and how
> they ought to be implemented.
>
> Anyway, please try out the attached patch and let me know if it works for
> you.
>
> Cheers
>   Nick
>
>
>
>
>
> --
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140
> ___
> Mspgcc-users mailing list
> Mspgcc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
>
>
--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] Instruction reordering

[Peter Bigot]

Your colleague is mistaken regarding re-ordering of access to
volatile-qualified objects.  David's description is correct and nicely
detailed.  In the example a will always be written before b unless the
compiler is broken.

(I should point out that mspgcc in the 3.2.3 era in fact probably *was*
broken with respect to correct ordering of some volatile operations,
because of a hack intended to improve peripheral register access
performance. There were errors in volatile behavior when I started
maintenance that didn't get cleaned up until sometime around August 2011.
There's probably traffic in the list archive around that time that explains
the problem.)

MSP430 writes of 16-bit values in any version of mspgcc I released would be
atomic except if they occurred to an object declared with the "packed"
attribute, in which case the byte values would be written separately to
prevent alignment problems.  (There were bugs in this usage too.)

I also use ARM Cortex devices these days, and am very pleased to see that
TI is moving the MSP432 to using CMSIS-Core--compatible peripheral
structure definitions as of March 2016 (
http://processors.wiki.ti.com/index.php/MSP432_CMSIS_Update?DCMP=epd-mcu-msp-gen=MSP432CMSIS).
If the Tiva and CC3K folks were that adaptable I might still use TI chips.

Peter

On Fri, Nov 27, 2015 at 9:04 PM, Wayne Uroda  wrote:

> Thanks very much David.
>
> I already disable interrupts when I need an atomic operation, such as a
> write to 32 bit variable or a read-modify-write on a 16bit variable.
>
> Am I right to assume that simple writes to 16 bit variables are always
> atomic on MSP430? Eg done = 0xabcd, the CPU doesn't do two byte writes or
> anything dumb like that, the memory will be X (don't care) before the write
> and will be 0xabcd after, or should I disable interrupts for all writes to
> shared memory (shared with an ISR)?
>
>
> My colleague asserts that the compiler is even free to reorder volatile
> accesses, like
>
> volatile int a;
> volatile int b;
> int c;
>
> int main()
> {
> a = 5;
> b = 0;
> c = 1;
> return 0;
> }
>
> You are saying that the compiler will always write a before b, even
> without a memory barrier. Is that right?
>
> But in the above, the write to c can happen anywhere, as far as I
> understand.
>
> Lastly, this compiler (3.2.3) is only used on our legacy projects. More
> recently we are using the last LTS of mspgcc before Ti/RH started their
> port.
> I've not seriously tried to use the new RH compiler, and my company is
> largely moving away from MSP430 towards ARM Cortex now.
>
> Thanks
> - Wayne
>
>
>
> > On 27 Nov 2015, at 23:19, David Brown  wrote:
> >
> >> On 27/11/15 12:32, Wayne Uroda wrote:
> >> Hello,
> >>
> >> I have a question about instruction reordering in the compiler.
> >>
> >> In this blog
> >> http://preshing.com/20120625/memory-ordering-at-compile-time/ It says
> >> that a compiler barrier should be used where writes to memory must
> >> not be reordered.
> >
> > Looks like good information.
> >
> >>
> >> My MSP430 code is all bare metal, foreground-background code and I am
> >> not using any type of RTOS, so it could be considered lock-free.
> >>
> >> Anyway, a new employee at my work pointed out that the compiler is
> >> free to reorder my memory writes, even those marked volatile. I said
> >> that I had never actually seen mspgcc do this, but now I am curious:
> >> will mspgcc reorder memory writes, eg to global variables? Is this
> >> dependent on the msp430 side of gcc (the backend), or more on the
> >> AST/RTL side?
> >
> > The compiler can re-order any reads or writes it likes, except volatile
> > accesses.  The order of volatile accesses will always match the source
> > code.  But the compiler can move non-volatile reads and writes back and
> > forth between volatile accesses.
> >
> > So if you have non-volatile variables a, b, c, and volatile variables u,
> > v, and source code like this:
> >
> > a = 1;
> > u = 100;
> > b = 2;
> > v = 200;
> > c = 3;
> >
> > Then the compiler can generate code like this:
> >
> > a = 1;
> > c = 3;
> > u = 100;
> > v = 200;
> > b = 2;
> >
> > But it may not generate code like this:
> >
> > a = 1;
> > v = 200;
> > b = 2;
> > u = 100;
> > c = 3;
> >
> > (The same applies to reads.)
> >
> > The volatile accesses must be exact, in the same number and the same
> > order with respect to other volatile accesses.  But the non-volatile
> > accesses can be moved around as much as the compiler wants.
> >
> > Note that variable accesses can also be moved around with respect to
> > function calls, /if/ the compiler knows the function does not make
> > volatile accesses.
> >
> > The compiler can also eliminate "dead" stores, or unused reads.  Given:
> >
> > a = 1;
> > u = 100;
> > a = 2;
> > v = 200;
> > a = 3;
> >
> > The compiler can generate:
> >
> > u = 100;
> > v = 200;
> > a = 3;
> >
> > or
> >
> > a = 3;
> > u = 100;
> > v = 100;
> >
> >
> >>
> >> 

Re: [Mspgcc-users] New MSP430 GCC version release available!

[Peter Bigot]

Thanks for the update.

Please note the mspgcc-users mailing list has historically had a maximum
message length of 40 kB, and does not allow attachments.  A couple of your
messages have exceeded this limit and I've passed them through, but that's
why you may see delays on your postings.

Also may I suggest TI make the effort to rebase the next compiler release
on gcc 5.2 since that was released last July (three months after 5.1).  I
don't know if they have a 5.3 coming up before you expect your version to
be out, but you might want to coordinate with the GNU folks on that.

On Fri, Sep 25, 2015 at 3:07 AM, Ghannouchi, Youssef 
wrote:

> Hello GCC-enthusiasts,
>
> I have seen some questions and feedbacks related to the email below and I
> would like to clarify some points.
>
> 1.   Versioning
>
> a.   The MSP430 GCC standalone package is container which has its own
> version. The latest version is v3.5.0.0. Please refer to versioning scheme
> for the package described below.
>
> b.  The MSP430 GCC standalone package has a software manifest included
> in the package (attached also GCC_14r1_manifest.pdf) which describe in
> details all sub components and their version.
>
> c.   The package contains:
>
>i.  GGC
> 4.9.1
>
>  ii.  GDB
> 7.5.0
>
> iii.
> binutils 2.23
>
>iv.  Tcl
> 8.4.1
>
>  v.
> MSP430 Debug Stack 3.5.1.1
>
>vi.  MSP430
> Support Files 1.173
>
>   vii.  MSP430
> GDB Agent 6.0.14.5
>
>
>
> 2.   MSP430 GCC 5.1
>
> a.   The MSP430 GCC standalone package v3.5.0.0 uses the GCC 4.9.1.
> The purpose of this package was to give a quick update on GCC compiler
> including the latest bug fixes to allow our customers continuing their
> development easily.
>
> b.  We are working on preparing an MSP430 compiler based on GCC 5.1.
> This package is expected to be released by end of this year. I will keep
> informed.
>
>
> Thank you for the valuable feedbacks, we really appreciate it.
> We would like to continue improving MSP430 GCC offer, so please feel free
> to send any suggestions or recommendations.
> For better tracking and handling please use TI e2e community<
> https://e2e.ti.com/> to submit your requests.
>
> Best regards,
> 
> Youssef Ghannouchi
> Product Manager - Texas Instruments Inc.
>
>
>
> Texas Instruments Deutschland GmbH, Haggertystr. 1, D-85356 Freising.
> Amtsgericht München HRB 40960. Geschäftsführer: Dr. Wolfram Tietscher.
> Vorsitzender des Aufsichtsrates: Andreas Schwaiger
>
>
> From: Ghannouchi, Youssef
> Sent: Sunday, September 20, 2015 6:18 PM
> To: 'GCC for MSP430 - http://mspgcc.sf.net'
> Cc: 'Brendan Conoboy (b...@redhat.com)'; Miller, Greg; Mitnacht, Thomas
> Subject: New MSP430 GCC version release available!
>
> Hello GCC-enthusiasts,
> We are pleased to announce a new stand-alone & open source release
> (v3.5.0.0)  of MSP430 GCC available for download here<
> http://software-dl.ti.com/msp430/msp430_public_sw/mcu/msp430/MSPGCC/3_05_00_00/index_FDS.html
> >!
> The stand-alone package includes all binaries, the source code and MSP430
> device specific support files.
> The MSP430 GCC build is also available in CCSv6 App Center on all
> platforms (Windows, Linux and Mac OSX).
>
>
> · Highlights
>
> o   MSP430 GCC compiler latest build (14r1-364)
>
> o   MSP430 GCC for Mac OS X (beta release)
>
> o   A new MSP430 GCC User Guide
>
>
>
> · Package Content
>
> o   Full Packages
>
> §  msp430-gcc-full-linux-installer-3.5.0.0.run: MSP430 GCC Linux installer
> incl. support files and debug stack and USB drivers - apply chmod x before
> executing the package
>
> §  msp430-gcc-full-osx-installer-3.5.0.0-beta.zip: MSP430 GCC Mac OS X
> installer incl. support files and debug stack and USB drivers - beta release
>
> §  msp430-gcc-full-windows-installer-3.5.0.0.exe: MSP430 GCC Windows
> installer incl. support files and debug stack and USB drivers
>
> o   Compiler Only Packages
>
> §  msp430-gcc-linux-installer-3.5.0.0.run: MSP430 GCC Linux installer -
> compiler only - apply chmod x before executing the package
>
> §  msp430-gcc-osx-installer-3.5.0.0-beta.zip: MSP430 GCC Mac OS X
> installer - compiler only - beta release
>
> §  msp430-gcc-windows-installer-3.5.0.0.exe: MSP430 GCC Windows installer
> - compiler only
>
> o   MSP430 Support Files
>
> §  msp430-gcc-support-files.zip: MSP430 Header and linker Files
>
> o   MSP430 GCC Sources files
>
> §  msp430-gcc-source.tar.bz2: MSP430 GCC source files
>
>
>
> · What's New
>
> o   Key Changes to MSP430 GCC
>
> 

[Mspgcc-users] Fwd: New MSP430 GCC version release available!

[Peter Bigot]

My archive of msp430-elf releases at https://github.com/pabigot/msp430-elf
has been updated to include 3.05.00.00.  The bottom of the README includes
a description of the version numbering used by TI.  This new release does
include a few fixes/enhancements in the compiler, the first since
3.02.03.00, but is fundamentally the same GCC version as the original TI
release one year ago.

I no longer use MSP430 and at some point will stop updating my archive.
Earlier this summer I was using the upstream gcc+binutils (5.0.0-based at
the time, selected specifically for C++14 support), built as documented at
http://pabigot.github.io/bsp430/msp430elf.html.  Stock GNU tools work fine
with MSP430 now, though they sometimes do lag in applying patches that
appear in the TI fork.  Only the device-specific headers and linker scripts
from TI (also in my archive) are necessary when using upstream versions.

Peter


On Sun, Sep 20, 2015 at 11:31 PM, Mark Rages  wrote:

> On Sun, Sep 20, 2015 at 10:17 AM, Ghannouchi, Youssef
>  wrote:
> > Hello GCC-enthusiasts,
> > We are pleased to announce a new stand-alone & open source release
> (v3.5.0.0)  of MSP430 GCC available for download here<
> http://software-dl.ti.com/msp430/msp430_public_sw/mcu/msp430/MSPGCC/3_05_00_00/index_FDS.html
> >!
> > The stand-alone package includes all binaries, the source code and
> MSP430 device specific support files.
> > The MSP430 GCC build is also available in CCSv6 App Center on all
> platforms (Windows, Linux and Mac OSX).
>
> What version of GCC is it?  Neither 3.5.0 nor 14r1-364 are GCC version
> numbers.  Development of GCC 3.x ended a decade ago.
>
> Regards,
> Mark
>
>
> --
> ___
> Mspgcc-users mailing list
> Mspgcc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
>
--
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] New MSP430 stand-alone GCC version release available!

[Peter Bigot]

I'm unaware of instructions for building from the TI/RedHat forked source,
but the upstream GNU packages are mature.
http://pabigot.github.io/bsp430/msp430elf.html has details on building the
toolchain from them.

Peter

On Sat, Apr 11, 2015 at 5:55 PM, Lev Serebryakov l...@serebryakov.spb.ru
wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA512

 On 23/02/2015 17:15, Ghannouchi, Youssef wrote:

  Are here any instructions to build this from sources? I have problems
 from very beginning with this so named release (I didn't seen
 releases worse, to be honest):

 (1) Sources could not be downloaded automatically. You need browser.
 What should distributive build cluster do?

 (2) Sources tarball doesn't contains any version indication in its name

 (3) There are no instructions at all!

  ./configure --prefix=/usr/local --target=mdp430  gmake all

  fails in early stages with different problems, looks like it is very
 Linux-specific (stock binutils/gcc could be build virtually anywhere!)

  I want to update FreeBSD port/package for ancient msp430gcc, but it
 looks impossible :-(


  Hello GCC-enthusiasts,
 
  We are pleased to announce a new stand-alone  open source release
  (v3.02.03.00) on the external web! This release is the stand-alone
  equivalent to the MSP430 GCC support in CCSv6 App Center and
  includes all binaries, the source code and MSP430 device specific
  support files.
 
 
  · What's new in this release?
 
  o   Key Changes to GCC:
 
  §  Fixed initialization of .data section
 
  §  Fixed detection of hardware multiply (for MSP430FR5739).
 
  o   Key Changes to Header  Support Files:
 
  §  Update linker scripts to fix initialization of .data section in
  large memory devices.
 
  §  Change asm to __asm__ in iomacros.h (for C99 compatibility).
 
  o   Please refer to the release
  noteshttp://software-dl.ti.com/msp430/msp430_public_sw/mcu/msp430/MSP
 GCC/3_02_03_00/index_FDS.html
  for more details.
 
 
  · How to get it?
 
  o   Use the Stand-alone  Open Source downloads from the GCC tools
  folderhttp://www.ti.com/tool/msp430-gcc-opensource
 
  o   Update through CCS v6.x installation will be available in the
  coming days.  Please note that updating GCC compiler will also
  automatically update the GCC MSP430 device specific support files.
 
  §  Update your CCS v6.x installation (Help - Search for updates)
  to the latest version and visit the CCS App Center under (Help -
  Getting Started) Basic migration advice and links to GCC
  documentation is provided in the CCSv6 for MSP430 user's
  guidehttp://www.ti.com/lit/pdf/slau157
 
 
  Best regards, Youssef Ghannouchi
 
   Youssef Ghannouchi Product Manager
  - Texas Instruments Inc.
 
 
 
 
 
 
  --
 - 
 
 
 Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
  from Actuate! Instantly Supercharge Your Business Reports and
  Dashboards with Interactivity, Sharing, Native Excel Exports, App
  Integration  more Get technology previously reserved for
  billion-dollar corporations, FREE
  http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.
 clktrk
 
 
 
 
  ___ Mspgcc-users
  mailing list Mspgcc-users@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/mspgcc-users
 


 - --
 Black Lion AKA Lev Serebryakov
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v2

 iQJ8BAEBCgBmBQJVKaZFXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
 ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF
 QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePx9gP/jtMTR4YpltOLGrxgJHXYLNs
 T18+R8XOLjOMIFAIn8HeHH2IBgTfCNz/Y/6WmUbzyHSdmiDwqiVQnaF3fqjgYluM
 +9mt5qIHcdWFRm8CnDmfL0K+fTJTlGN4ei4zrRftldxAYy8KGmINJciuxesJCy2R
 6WLHCir5xmGW1079RH0nQ8Mh/Z8BxxVsCDE6rWe3/0EBPGhCHilf6VEnWHN1Em/b
 +zMzRcl7nzVWx6ppLQBE0ffbR4u/eVmnFEBVOmoAk1lSWGurFg3YnVWXel+dJ5Pt
 Z3XTVWRsMFx3yxIyk3nAsccrtwD2Pmog8Qqex6nNr8pMLNL+IBhJsqUsegbGRT6l
 h07RMUZONs7nO7Juow8MWPwaJX71azZE7BSQ/DpdMKpuQetumlQ6h0nEehcT+YoX
 IxcUdO2ywTwGkqMMmB3cP041KmBY+/E5jAsnlkdQFCva5JRCX6cpm3RDglDu0a9H
 ZSCBPgX92pzDkesHpi43jl0kB4KH7vEXuNpvncpkooWzAxI1/6nEg0vOAYkDcxyL
 mcI2Ju8bL6sCHTSZ42cJkRo/RyLIsPUB0iCCk2DiOtxoTs+K4o1h4RhdX5R0vTFC
 n0Y2Kt0yAExeJ76xcNBnOrya5ByqU2jJh40jpKJHLLFBKe7C4V93BbLAu0mpZ/ee
 SDlfYq0NDziDA1hsuL9a
 =UuS8
 -END PGP SIGNATURE-


 --
 BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
 Develop your own process in accordance with the BPMN 2 standard
 Learn Process modeling best practices with Bonita BPM through live
 exercises
 http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual-
 event?utm_
 source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF
 ___
 Mspgcc-users mailing list
 Mspgcc-users@lists.sourceforge.net
 

Re: [Mspgcc-users] code size

[Peter Bigot]

On Fri, Dec 12, 2014 at 4:43 AM, Kees Schoenmakers ksli...@gmail.com
wrote:

 I tried the newer msp-GCC (TI/RedHat) distribution on my project(s).

 It still builds with _far_ more code then my present msp430-gcc
 (4.7.0). This compiler
 has also some minor habits but produces compact code.

 So for the moment I will not switch to the newer version, my project
 would not fit in the flash.


Yes, code size is not as one might wish.  See
http://e2e.ti.com/support/development_tools/compiler/f/343/p/384317/1356674#1356674
for some information, as well as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64027

Those issues, unfortunately, are not solved by linker optimizations.  (IRT
Eric: I was unaware of the visibility attribute, so haven't run into that,
though I can see it will be useful in the future.)

My core blockers for msp430-elf are an official patch for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64160 and a new release of the
support headers/linker scripts that reverts the broken initialization
infrastructure (which I assume TI is working on).

But since mspgcc doesn't build on Ubuntu 14.04 the code size issue does
become more important.  The E2E response hints that we're running into an
organizational conflict of interest at TI.

Peter
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] .data initialization not working

[Peter Bigot]

Nick: Are you saying that the linker scripts are changing so that a global
variable definition like this:

int myvar = 43;

will result in myvar being stored in RAM, and no initialization of it so
the value of myvar when main starts is not 43?

What you wrote seems to imply this, and it matches what Olivier's reported,
but not what I've experienced.

It's also a clear violation of the C language required behavior, which TI
has been known to do in their own compiler in pre-elf linker days.

(

Peter

On Mon, Dec 8, 2014 at 5:55 AM, Nicholas Clifton ni...@redhat.com wrote:

 Hi Olivier,

  When porting some programs to the latest MSPGCC version from RedHat/TI, I
  noticed that ALL initialized global variables in my C code are not
  initialized by the crt0 code.

 Are you using your own linker script or a linker script from an older
 release ?

 The problem is that MSP430 linker scripts used to place the .data
 section into the ROM memory region and then code in crt0.o would copy
 the data into RAM at program startup.  Newer linker scripts place the
 .data section directly into the RAM or HIFRAM memory regions, so no
 copying is needed.


I'm curious how the linker can place initialized data into RAM on a device
and have it work after a power-cycle.  Are you saying that the linker
scripts are changing so that a global variable definition like this:

int myvar = 43;

will result in myvar being stored in RAM, and that its initialization has
been removed so the value of myvar when main starts is not 43?

What you wrote seems to imply this, and it matches what Olivier's reported,
but not what I've experienced.

It's also a clear violation of the behavior required by the C language,
which TI has been known to ignore in their own compiler in pre-elf linker
days when we could not trust that a variable defined by:

int myzero;

would have a zero value when main started.


 A second part of this problem is that an optimization was added to help
 reduce the size of the startup code for small programs.  The code in
 crt0.o was split up into small files and crt0.o was then converted into
 a library.  When an application is linked against the crt0 library only
 the pieces of startup code that it really needed would be brought into
 the executable.  Thus for example if a program never returned from
 main() then crt0 code to call exit() after main is not needed and so all
 of the cleanup code in the C library could be left out.


This seems to be redundant with -fcode-sections -fdata-sections
-Wl,-gc-sections.  What was the argument for using a more complex solution?



 In order for this optimization to work however, the cooperation of the
 compiler and assembler are needed.  They are expected to create
 unresolved references to special symbols whenever they detect that a
 certain feature of crt0 will be needed.  So for example the compiler
 creates a reference to __crt0_call_exit if it compiles a function called
 main that has an execution path that leads to the function returning.

 One of the parts of crt0 that can be omitted is (or rather was) the
 copying of data from ROM to RAM.  The need for this part of crt0 was
 detected by the assembler where it would create a special symbol
 __crt0_movedata whenever the .data section was used.  As part of a
 ratification of linker scripts however the decision was made to move
 .data into RAM and so the crt0 library and the assembler were updated to
 remove the use of the __crt0_movedata symbol.


 So ... you have three options:

1. Stick with your solution of adding (back) the movedata function.
 You may want to add code to skip calling memmove if __datastart ==
 __romdatastart since memmove does not cope with this situation.

2. Change your linker script to place the .data section into RAM.
 Note - you will also want to make sure that the .upper.data and
 .lower.data sections are also placed into RAM.

3. Complain to TI that you want the movedata functionality restored
 and they will fix it.  (Well I assume that they will.  Probably by
 asking me to do it. :-)


Thanks for your efforts.

Peter
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] .data initialization not working

[Peter Bigot]

Unfortunately this list doesn't support attachments.  Perhaps somebody
could put it on E2E and add a pointer.

Interesting that TI proposed a solution that doesn't work for ROM resident
applications, which are all but the most infinitesimal subset of the
applications that use an MSP430.  (It's so implausible I'm half convinced I
don't understand exactly what's happened here.)

Peter

On Mon, Dec 8, 2014 at 8:36 AM, Nicholas Clifton ni...@redhat.com wrote:

 Hi Guys,

 I have attached a patch which will restore the old movedata
 functionality to the toolchain.


 Strange - the attachment disappeared.  Here it is again.

 Cheers
   Nick



 --
 Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
 from Actuate! Instantly Supercharge Your Business Reports and Dashboards
 with Interactivity, Sharing, Native Excel Exports, App Integration  more
 Get technology previously reserved for billion-dollar corporations, FREE

 http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk
 ___
 Mspgcc-users mailing list
 Mspgcc-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mspgcc-users


--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] .data initialization not working

[Peter Bigot]

On Mon, Dec 8, 2014 at 9:01 AM, Paul Sokolovsky pmis...@gmail.com wrote:

 Hello,

 On Mon, 8 Dec 2014 08:42:28 -0600
 Peter Bigot big...@acm.org wrote:

  Unfortunately this list doesn't support attachments.  Perhaps somebody
  could put it on E2E and add a pointer.

 Or maybe RedHat even has version control system, maybe even with web
 interface?

 
  Interesting that TI proposed a solution that doesn't work for ROM
  resident applications, which are all but the most infinitesimal
  subset of the applications that use an MSP430.  (It's so implausible
  I'm half convinced I don't understand exactly what's happened here.)

 Peter, can you please consider maintaining mspgcc for couple years
 more, while dear esteemed vendors sort out issue how to teleport
 application code out of thin air into RAM?


Unfortunately, no.  I switched all my development machines to Ubuntu 14.04
this weekend, and mspgcc won't build because it uses outdated binutils and
gcc sources.  I backported some of the changes, but the host gcc ICEs on a
gcc 4.7.2 source file not obviously related to msp430.  So that's the end
of that.

It'd probably be pretty easy to fork my msp430-elf repository and upstream
gcc and fix about half the issues we're discussing, but I'm irritated
enough with how TI's managing the MSP430 product line these days that I'm
not really motivated to keep trying to bail them out.

More importantly, I've found an interesting position that actually pays me
for what I can do, so I really need to focus on that.  There we're using
ARM chips; much nicer.

Peter (going back to work now)
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] .data initialization not working

[Peter Bigot]

This is a place to report these; other places would be the TI forums; see
http://e2e.ti.com/support/development_tools/compiler/f/343/t/384148

It'd help if you provide a standalone program with the sort of
initialization expressions that aren't working for you, along with the
exact command line you're using.  From my experience, global variables with
initializers are constructed properly.  (Note that if you use -minrt you
are telling the compiler/linker to strip out the static initialization
routines.  Generally not a good idea.)

Peter

On Sat, Dec 6, 2014 at 5:03 PM, Olivier Girard olgir...@gmail.com wrote:

 Hi all,

 I just want to start a new thread regarding another issue I mentioned in an
 earlier mail.

 When porting some programs to the latest MSPGCC version from RedHat/TI, I
 noticed that ALL initialized global variables in my C code are not
 initialized by the crt0 code.

 After looking around in the crt* sources, I noticed there is a procedure
 meant to do that in the msp430-elf/tools/libgloss/msp430/crt_movedata.S
 file.
 When compiling my program using the standard linker scripts provided with
 the toolchain, I can't see this procedure anywhere in the linked
 executable.

 I was not able to see if the problem lays in the linker script itself or in
 the compiled crt0 procedures.
 However, I can restore the proper functionality by re-writing the
 crt_movedata procedure directly in my C code and calling it first thing
 when entering the main():

 ...
 extern const unsigned char * __datastart;
 extern const unsigned char * __romdatastart;
 extern const unsigned int__romdatacopysize;

 void my_crt_movedata(void) {
   __asm__ __volatile__(
 mov #__datastart,   R12 \n\t
 mov #__romdatastart,R13 \n\t
 mov #__romdatacopysize, R14 \n\t
 call #memmove
   );
 }

 int main(void) {

 my_crt_movedata();

 WDTCTL = WDTPW | WDTHOLD;  // Disable watchdog timer
 ...

 As this solution is definitely not acceptable, does someone has an idea
 about what currently goes wrong in the current toolchain release (crt ?
 linker script ? ...).

 Is this mailing list also the right place to report this kind of issues ?

 Thanks a lot,
 Olivier

 PS: currently running:
 msp430-elf-gcc (GCC) 4.9.1 20140707 (prerelease (msp430-14r1-98)) (GNUPro
 14r1) (Based on: GCC 4.8 GDB 7.7 Binutils 2.24 Newlib 2.1)


 --
 Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
 from Actuate! Instantly Supercharge Your Business Reports and Dashboards
 with Interactivity, Sharing, Native Excel Exports, App Integration  more
 Get technology previously reserved for billion-dollar corporations, FREE

 http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk
 ___
 Mspgcc-users mailing list
 Mspgcc-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mspgcc-users


--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] Disable watchdog timer in crt0.S BSS initialization

[Peter Bigot]

Assuming this was meant to be cc'd to the list.  TI: Please take note of
this thread.

On Wed, Dec 3, 2014 at 9:11 PM, Przemek Klosowski 
przemek.klosow...@gmail.com wrote:

 On Wed, Dec 3, 2014 at 7:47 PM, Peter Bigot big...@acm.org wrote:
  The existing solution is wrong in a couple ways: first the address of
  WDTCTL should not be hard-coded (there are three possible locations
 across
  the current set of MCUs, with 0x15c being wrong for non-5xx MCUS
 including
  the new FR2xx/FR4xx ones),

 I see only two addresses: 0x15C and 0x120.
 I loaded the peripheral register data from thje linker script files
 into a sqlite database to have a good overview of the peripherals
 across the MSP430 line:

 perl -lane '($f)=($ARGV=~m#s/(.*)/per#); ($p,$l)=/__(.*) = (.*);/;
 warn $ARGV $_ if $f eq ; print $f $p $l'
 /usr/msp430/lib/ldscripts/*/periph.x   x

 sqlite3 msp430.db
 create table c (chip, dev, adr);
 .mode list
 .separator ‘ ‘
 .import x c


Yes, I did something like this with the analysis subdirectory of msp430mcu,
but text-file based:
https://sourceforge.net/p/mspgcc/msp430mcu/ci/master/tree/analysis/

I haven't bothered to replicate that for the new headers; grep | sort |
uniq handles most of my needs.



 The WDTCTL addresses can be extracted by:
select distinct adr from c where dev like 'wdtctl';

 and it shows 15c and 120 (the former tends to be in 4/5/6xxx series
 but not universally so)


 llc[83]$ grep WDTCTL msp430fr4133.h
#define WDTCTL_   0x01CC/* Watchdog Timer Control */


 The database turns out to be useful to find stuff like 'what OTHER
 devices are at 0x120 (it turns out that it's PMMCTL0)

   select distinct dev from c where dev not like 'wdtctl%' and adr like
 '0x0120';

 whereas 0x15c sometimes holds ADC12MEM14 and MPY32CTL0


 llc[86]$ grep -h 015C *.h | sort | uniq
#define ADC12MEM14_   0x015C/* ADC12 Conversion Memory 14 */
#define MPY32CTL0_0x015C/* MPY32 Control Register 0 */
#define SYSSNIV_  0x015C/* System NMI vector generator */
#define UCA0IFG_  0x015C/* USCI A0 Interrupt Flags Register
*/
#define WDTCTL_   0x015C/* Watchdog Timer Control */

TI: you really need to fix the infrastructure so the Red Hat folks can
refer to peripheral registers symbolically in infrastructure code instead
of hard-coding addresses as integer constants.

DO NOT use names in the user namespace like WDTCTL, as in the CCS cmd files:

llc[215]$ grep WDTCTL msp430f5438a.cmd
WDTCTL = 0x015C;
WDTCTL_L   = 0x015C;
WDTCTL_H   = 0x015D;

Use a double-underscore prefix (__WDTCTL) or negotiate with the GNU folks
to come up with something that will conflict with neither the GNU toolchain
nor intrude on the user namespace.  See
http://www.mail-archive.com/mspgcc-users@lists.sourceforge.net/msg12212.html
if you missed the start of this.  You'll need to change iomacros.h to use
something like this:

#define sfrb_(x,x_) volatile __MSPGCC_PERIPHERAL__ unsigned char x
__asm__(__ #x)
#define sfrb(x,x_) extern sfrb_(x,x_)

so that object files referring to peripheral registers reference the
symbolic name instead of embedding a constant that might be wrong if the
code's in a library linked into applications for multiple MCUs.

Peter
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] Disable watchdog timer in crt0.S BSS initialization

[Peter Bigot]

On Wed, Dec 3, 2014 at 3:54 PM, Olivier Girard olgir...@gmail.com wrote:

 Hi all,

 I am currently updating the verification environment of the openMSP430 to
 support the new Redhat/TI GCC toolchain.

 The first thing I noticed is that the *crt0* code by default assumes that
 the watchdog WDTCTL register is mapped at 0x015c...
 Does someone knows if there is a magic switch to change the default
 behavior and map the register to 0x0120 ? (I hope to avoid a re-compile of
 the crt0.S stuff)

 Here is the snippet:
 ...
 Disassembly of section .text:

 c010 __start:
 c010: 31 40 00 04 mov #1024, r1 ;#0x0400

 c014 .Loc.39.1:
 c014: b2 40 80 5a mov #23168, *0x015c* ;#0x5a80
 c018: 5c 01
 ...


Interesting.

The existing solution is wrong in a couple ways: first the address of
WDTCTL should not be hard-coded (there are three possible locations across
the current set of MCUs, with 0x15c being wrong for non-5xx MCUS including
the new FR2xx/FR4xx ones), and second the reset value can't be hard-coded
because different clock rates are used on different MCUs, and the right bit
pattern for one will leave another misconfigured once the CRT code
completes.

mspgcc worked around the first issue by defining symbols for all the
registers, so they didn't have to be resolved until non-relocatable link
time.  Oddly, Code Composer Studio's linker files do this, but the ones
TI's providing for GCC don't.  (Absence of symbols also complicates
hardware multiply because if symbols were used instead of address values
some of the MPY32 variation points could be eliminated.)

The second issue can be resolved by creating a reset value based on reading
the power-up value.  The code sequence necessary is:

mov.b   __WDTCTL, r5
bis #0x5a08, r5
mov r5, __wdt_clear_value

unless that doesn't work for the new FR2xx/4xx WDT peripheral.

(Not that this helps you, but somebody should probably file a bug report
against newlib, which is where those files live.)

Peter
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] New MSP430 stand-alone GCC version release available!

[Peter Bigot]

Thanks Thomas.

https://github.com/pabigot/msp430-elf has been updated with these
releases.  I'm not sure why the version jumped from 2.01.01.00 to
3.02.02.00 since the GCC version apparently didn't change but we'll run
with it.

In the gcc_rh branch the only change I made was to remove the execute bits
from the header files and move the contents back to the include directory
from the msp430-gcc-support-files directory they're now in.  Note that the
TI versions now use Unix line endings, so to identify content differences
from old versions you need to add -b or -w to the diff command.

In the sources branch the only change was to move the tools directory up
one level, and to remove some .gitignore files that were preventing the
archive from containing certain derived files.

There are changes in the TI sources that appear to need to be backported to
upstream (e.g. the support for longer C++ template names); somebody might
need to file an upstream bug report to get that to happen.  There are also
a variety of issues reported on gcc bugzilla and E2E in both the headers
and toolchain that are still outstanding including (by inspection) the
hardware multiplier issues.

FYI: The best information I've collected on how to report bugs in the
toolchain is in the README displayed at:
https://github.com/pabigot/msp430-elf

Thomas, I for one very much appreciate both the new releases and the fact
you're announcing them here.

Peter


On Thu, Nov 27, 2014 at 4:51 AM, Mitnacht, Thomas t-mitna...@ti.com wrote:

 Hello GCC-enthusiasts,
 We just posted a new stand-alone  open source release (v3.02.02.00) on
 the external web!

 This release is the stand-alone equivalent to the MSP430 GCC support in
 CCSv6 App Center and includes all binaries, the source code and MSP430
 device specific support files.
 What's new in this release?

 • Large memory support in GCC (linker files update)

 • Fixed loading of program into GDB with function in high memory.

 • Latest MSP430 device support (MSP430FR69xx, MSP430FR68xx,
 MSP430FR59xx, MSP430FR58xx, RF430FRL15xH)

 • Several bug fixes (see release notes
 http://software-dl.ti.com/msp430/msp430_public_sw/mcu/msp430/MSPGCC/3_02_02_00/index_FDS.html
 )

 How to get it?

 • Update your CCS v6.x installation (Help - Search for updates)
 to the latest version and visit the CCS App Center under (Help - Getting
 Started)
 Basic migration advice and links to GCC documentation is provided in the
 CCSv6 for MSP430 user’s guidehttp://www.ti.com/lit/pdf/slau157

 • Use the Stand-alone  Open Source downloads from the GCC tools
 folderhttp://www.ti.com/tool/msp430-gcc-opensource

 Thanks,
 Thomas Mitnacht
 
 MSP430 Development Tools Manager • Ultra-Low Power MCUs
 Texas Instruments • Freising • +49 8161 80 3002



 Texas Instruments Deutschland GmbH, Haggertystr. 1, D-85356 Freising.
 Amtsgericht München HRB 40960. Geschäftsführer: Dr. Wolfram Tietscher.
 Vorsitzender des Aufsichtsrates: Andreas Schwaiger




 --
 Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
 from Actuate! Instantly Supercharge Your Business Reports and Dashboards
 with Interactivity, Sharing, Native Excel Exports, App Integration  more
 Get technology previously reserved for billion-dollar corporations, FREE

 http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk
 ___
 Mspgcc-users mailing list
 Mspgcc-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mspgcc-users


--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] New MSP430 stand-alone GCC version release available!

[Peter Bigot]

On Thu, Nov 27, 2014 at 10:42 AM, Paul Sokolovsky pmis...@gmail.com wrote:

 Hello Peter,

 On Thu, 27 Nov 2014 06:23:40 -0600
 Peter Bigot big...@acm.org wrote:

  In the gcc_rh branch the only change I made was to remove the execute
  bits from the header files and move the contents back to the include
  directory from the msp430-gcc-support-files directory they're now
  in.  Note that the TI versions now use Unix line endings, so to
  identify content differences from old versions you need to add -b or
  -w to the diff command.

 Ah, too bad they were not dos2unix'ed before the import!


My intent is that these be archival; I'll muck with metadata like execute
bits and the containing directory name in an attempt to maintain
consistency across releases, but I won't change the content of individual
files.



 And here's something I wanted to ask for a while - did you or somebody
 else considered adding msp430 toolchain to http://crosstool-ng.org/ ?


Nope.  I'm not interested in more things to maintain; my solution for
msp430elf toolchain building is described here:
http://pabigot.github.io/bsp430/msp430elf.html

That page includes a link to the most recent version of my build script
posted here some months ago.  If somebody wants to use that as a basis for
other work, feel free.  I don't think it's got enough creativity to warrant
a copyright and in any case it'd fall under the BSD-3-Clause licensing of
BSP430.

Peter
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] msp430-elf incorrect hwmult inference

[Peter Bigot]

Since I haven't seen a response, I've gone ahead and made
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63953 to record the absence of
the FR5xx/6xx MCUs from the hard-coded list in upstream gcc.

Peter

On Wed, Nov 12, 2014 at 10:45 AM, Peter Bigot big...@acm.org wrote:

 Just noticed that integer multiplication is broken in upstream msp430-elf
 on msp430fr5969, apparently because gcc is hard-coding the list of MCUs and
 deciding which hardware multiplier to use based on that.  None of the FR5
 chips are in any of those hard-coded lists.  Interestingly, some FR2/FR4
 ones are listed.

 It does work if you explicitly add '-mhwmult=f5series' but the whole point
 of -mmcu=foo is to set the correct flags for device foo.

 This is a really lousy design choice.  TI folks: we had the toolchain
 fully decoupled from the device list with msp430mcu four years ago in
 mspgcc, allowing the set of supported devices to be updated without
 breaking the toolchain.

 Why was this solution chosen?

 Peter


--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

[Mspgcc-users] msp430-elf incorrect hwmult in newlib

[Peter Bigot]

Unrelated to the issue of hard-coding MCUs, this one needs attention from
Red Hat:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63901

The short version is newlib gets built with support only for a default
-mhwmult=16 which causes the MCU to reset when invoking strtoul in an
application targeting -mhwmult=f5series, because there is no MPY peripheral
at the addresses where the operands are written.  mhwmult needs to be one
of the features that distinguish multilib selection.

It'd also probably be better to make the default in msp430_output_labelref
select msp430_no_hwmult which will (at least theoretically) work on every
MCU.

Confirmed present in today's trunk revisions of gcc, binutils, and newlib
using the build script at:
https://github.com/pabigot/bsp430/blob/master/maintainer/msp430-elf-build

I'm working around it by defaulting gcc to select f5series since those are
the MCUs I'm developing with this week.

Peter

From d6a368e5ca6cfbf7c99be1df07770779da2a5dc4 Mon Sep 17 00:00:00 2001
From: Peter A. Bigot p...@pabigot.com
Date: Sat, 15 Nov 2014 21:11:12 -0600
Subject: [PATCH] HACK: msp430 use -mhwmult=auto select f5_series

Work around https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63901
---
 gcc/config/msp430/msp430.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/config/msp430/msp430.c b/gcc/config/msp430/msp430.c
index fe97f27..e4d20b2 100644
--- a/gcc/config/msp430/msp430.c
+++ b/gcc/config/msp430/msp430.c
@@ -2173,7 +2173,7 @@ msp430_use_f5_series_hwmult (void)
   static const char * cached_match = NULL;
   static bool cached_result;

-  if (msp430_hwmult_type == F5SERIES)
+  if ((msp430_hwmult_type == F5SERIES) || (msp430_hwmult_type == AUTO))
 return true;

   if (target_mcu == NULL || msp430_hwmult_type != AUTO)
-- 
1.8.5.5
--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://pubads.g.doubleclick.net/gampad/clk?id=154624111iu=/4140/ostg.clktrk___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

[Mspgcc-users] msp430-elf incorrect hwmult inference

[Peter Bigot]

Just noticed that integer multiplication is broken in upstream msp430-elf
on msp430fr5969, apparently because gcc is hard-coding the list of MCUs and
deciding which hardware multiplier to use based on that.  None of the FR5
chips are in any of those hard-coded lists.  Interestingly, some FR2/FR4
ones are listed.

It does work if you explicitly add '-mhwmult=f5series' but the whole point
of -mmcu=foo is to set the correct flags for device foo.

This is a really lousy design choice.  TI folks: we had the toolchain fully
decoupled from the device list with msp430mcu four years ago in mspgcc,
allowing the set of supported devices to be updated without breaking the
toolchain.

Why was this solution chosen?

Peter
--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://pubads.g.doubleclick.net/gampad/clk?id=154624111iu=/4140/ostg.clktrk___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] msp430-elf issue with large code

[Peter Bigot]

That's fixed the compiler problems.  Seems to be some problems with newlib
in large memory mode, but that could be an error in my bridge to it.

Thanks for the prompt fix.

Peter

On Mon, Nov 3, 2014 at 5:44 AM, Nicholas Clifton ni...@redhat.com wrote:

 Hi Peter,

  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63709


 This should be resolved now.

 Cheers
   Nick



--
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] replacing libgloss in msp430-elf

[Peter Bigot]

On Mon, Sep 22, 2014 at 2:17 AM, Nicholas Clifton ni...@redhat.com wrote:
 Hi Peter

 Ping.


 [DJ is on vacation, so I am standing in for him...]

Thanks for responding.


 Perhaps moving the cio-enabled nosys to a libcio.a?  Then we'd need a
 -mcio option to gcc to enable it, but could default to doing the
 generic nosys thing...


 I like that approach; it makes clear that the system interface is
 still CIO even when not using -msim, and it gives application
 developers the appropriate level of control when CIO is not desired.
 Making selection of -mcio a positive decision (not default) also helps
 reveal when an application unintentionally introduces dependencies
 such as calls to sbrk (malloc) for newlib internal data structures
 that most mspgcc developers would be surprised to find happening (they
 did not occur with the same functions in msp430-libc).

 What needs to be done to get this into place?  Do you need an
 enhancement request in gcc and/or newlib bugzilla?


 Yes - if you want Red Hat to do this.  But of course you can do the work
 yourself if you prefer.

That would seem to be the most likely path to success.

 Absent any coordinated action on this, I'm going to send patches to
 newlib to remove the special-case override of libnosys in msp430
 libgloss, and to gcc to eliminate the automatic addition of -lnosys
 when -msim is absent in gcc.


 Both of which are perfectly reasonable, and I see no reason why they should
 not be accepted.

gcc: https://gcc.gnu.org/ml/gcc-patches/2014-09/msg01809.html
newlib: https://sourceware.org/ml/newlib/2014/msg00465.html

I'd appreciate it if you or DJ would shepherd these through: I don't
think anybody on either list is likely to merge them otherwise.
Thanks.

Peter

--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] replacing libgloss in msp430-elf

[Peter Bigot]

On Mon, Sep 22, 2014 at 10:49 AM, Nicholas Clifton ni...@redhat.com wrote:
 Hi Peter,

 gcc: https://gcc.gnu.org/ml/gcc-patches/2014-09/msg01809.html
 newlib: https://sourceware.org/ml/newlib/2014/msg00465.html

 I'd appreciate it if you or DJ would shepherd these through: I don't
 think anybody on either list is likely to merge them otherwise.


 Both patches have now been approved and applied to the mainline sources.

 Cheers
   Nick

Thank you very much.  For the first time I have a working msp430-elf
toolchain built from upstream sources with no patches (and it's gcc
5.0.0).

I looked at the changes to gcc 4.9.1 that are in the TI msp430-elf
2.0.0 (Red Hat GNUPro 14r1) which add full support for 20-bit
addresses and are not upstreamed yet.  They seem pretty pervasive:
major changes to the set of supported integer types.

It's not really feasible to extract those changes and apply them to a
non-bundled source directory since the base version isn't exactly GCC
4.9.1.If you or TI could provide information on whether those
patches are likely to get refactored and merged upstream, and any
timeline information that's available, I think most folks here would
be interested.

Peter

--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] replacing libgloss in msp430-elf

[Peter Bigot]

On Mon, Sep 22, 2014 at 11:40 AM, DJ Delorie d...@redhat.com wrote:

 It's not really feasible to extract those changes and apply them to a
 non-bundled source directory since the base version isn't exactly GCC
 4.9.1.If you or TI could provide information on whether those
 patches are likely to get refactored and merged upstream, and any
 timeline information that's available, I think most folks here would
 be interested.

 You need my __intN patch set, currently being reviewed upstream.  Some
 parts have been approved and applied, but you still need the main
 conversion (3/5, pending libg++ review) and the msp430-specific part
 (5/5, just waiting on part 3/5).  This patch set is based on the
 TI-specific patch in their 4.9 sources.

 https://gcc.gnu.org/ml/gcc-patches/2014-08/threads.html#01398

Thanks.  As it's in-progress, I'll just wait until it appears in the
tree.  I mostly don't use 20-bit on msp430-elf: it takes up too much
space compared to mspgcc since (AFAIK) there's no compact/medium modes
so lots of things like size_t take 32 bits of memory when they could
take 16 for most applications.  If I need more memory for a project I
use ARM processors where I don't have to deal with split address
spaces.

FWIW: There are one or two unverified bug reports from me in gcc's
bugzilla that I'd hit doing 20-bit support in mspgcc that can probably
be closed now that part 2/5 (PRECISION != BITSIZE) is in.

Peter

--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] replacing libgloss in msp430-elf

[Peter Bigot]

Ping.

On Thu, Jun 5, 2014 at 5:55 PM, Peter Bigot big...@acm.org wrote:
 On Thu, Jun 5, 2014 at 4:48 PM, DJ Delorie d...@redhat.com wrote:

 The reason msp430 is different is because CIO *can* be used on real
 hardware, to communicate through a hardware debugger or emulator pod.

 Perhaps moving the cio-enabled nosys to a libcio.a?  Then we'd need a
 -mcio option to gcc to enable it, but could default to doing the
 generic nosys thing...

 I like that approach; it makes clear that the system interface is
 still CIO even when not using -msim, and it gives application
 developers the appropriate level of control when CIO is not desired.
 Making selection of -mcio a positive decision (not default) also helps
 reveal when an application unintentionally introduces dependencies
 such as calls to sbrk (malloc) for newlib internal data structures
 that most mspgcc developers would be surprised to find happening (they
 did not occur with the same functions in msp430-libc).

 What needs to be done to get this into place?  Do you need an
 enhancement request in gcc and/or newlib bugzilla?

Absent any coordinated action on this, I'm going to send patches to
newlib to remove the special-case override of libnosys in msp430
libgloss, and to gcc to eliminate the automatic addition of -lnosys
when -msim is absent in gcc.

Peter

--
Slashdot TV.  Video for Nerds.  Stuff that Matters.
http://pubads.g.doubleclick.net/gampad/clk?id=160591471iu=/4140/ostg.clktrk
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] No clue for thsi....

[Peter Bigot]

On Mon, Sep 15, 2014 at 1:57 AM, DJ Delorie d...@redhat.com wrote:

 -mmcu=msp430f449 -O2 -Wall -Wno-old-style-declaration  -std=c99

 By specifying -std=c99 you have disabled all the GNU extensions, including 
 asm.

 Try --std=gnuc99 instead, or replace asm with __asm__ in those headers.

DJ is entirely correct here.  To make it more clear, the file in which
these bare asm occur is the iomacros.h from TI's header distribution.
mspgcc's version of that file used the __asm__ syntax.

TI would need to fix this or it'll break again on the next update.

Peter

--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] msp430-elf-gcc (GCC) 4.9.1 20140707 (prerelease (msp430-14r1-10)) (GNUPro 14r1) (Based on: GCC 4.8 GDB 7.7 Binutils 2.24 Newlib 2.1)

[Peter Bigot]

On Wed, Sep 10, 2014 at 9:31 AM, Ben Ransford b...@ransford.org wrote:
 On Sep 10, 2014, at 7:19 AM, Kees Schoenmakers ksli...@gmail.com wrote:
 I found the archives for the newest msp430-gcc on the TI site via
 .
 http://www.ti.com/tool/MSP430-3P-GCC-MSPGCC-TPDE

 The production version of GCC for MSP430, which TI announced* on August 18,
 lives here:

   http://www.ti.com/tool/msp430-gcc-opensource

 ... whereas the URL you mentioned seems to refer to a beta release.

 I don't know whether the production version fixes the syntax error you saw, 
 but
 perhaps it's worth a try.

TI seems to change the naming conventions of the source releases with
each package, which also makes it difficult to figure out what's going
on.  2.00.00's msp430-gcc-14r1-10-source.tar.bz2 is bitwise identical
to 2.01.01's msp430-gcc-source.tar.bz2.  Either there is no difference
in the toolchain between 2.00.00 and 2.01.01, or the source archive
http://software-dl.ti.com/msp430/msp430_public_sw/mcu/msp430/MSPGCC/latest/exports/msp430-gcc-source.tar.bz2
was not updated.

The 2.01.01 headers files in
http://software-dl.ti.com/msp430/msp430_public_sw/mcu/msp430/MSPGCC/latest/exports/msp430-support-files.zip
are slightly different: USBRAM sections in linker files, cleanup of
some RTC defines.

Neither situation would fix the issue with the interrupt declaration;
I don't know what the problem is there; probably the new toolchain
requires a different interrupt declaration syntax than you're using.

Peter

--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] msp430-elf-gcc (GCC) 4.9.1 20140707 (prerelease (msp430-14r1-10)) (GNUPro 14r1) (Based on: GCC 4.8 GDB 7.7 Binutils 2.24 Newlib 2.1)

[Peter Bigot]

That makes sense and is a good practice.

Could you ensure that the source tar files and support files include
that version information in the file name?  E.g.
msp430-gcc-source-2_x_x.tar.bz2 and msp430-gcc-support-2_x_1.zip?
Where the prefix msp430-gcc- is consistent (don't drop the gcc
unless the support files are supposed to work with CCS and IAR too);
x indicates a placeholder dont-care; and assuming that the build
number never involves any source changes so should pretty much always
be zero and can be dropped from source-only packaging.

It'd also be consistent with best practices if, when those archives
were unpacked, the contents appeared in a directory that matched the
base name of the tar file, rather than a bare unversioned source or
include directory.

This would carry the easy-to-identify information over to the parts of
the distribution that currently lack it.

Thanks for your consideration.

Peter

On Wed, Sep 10, 2014 at 10:30 AM, Pfeiffer, Markus m-pfeif...@ti.com wrote:
 The versioning of our package works as follows:

 1. Digit: GCC Version
 2. Digit: Debug stack version
 3. Digit: Header/linker file version
 4. Digit: Build number

 This basically means that the delta from 2.0.0.0 to 2.1.1.0 is:
 - Identical GCC version
 - Updated Debug Stack
 - Updated header/linker files

 Why did we do this?
 We're shipping stand-alone packages  distributions that include all of the 
 above. With the version scheme you instantly see if we just updated support 
 files OR the debug Stack OR the actual compiler. This will hopefully help you 
 to determine where you want to update or not.

 Markus


 Texas Instruments Deutschland GmbH, Haggertystr. 1, D-85356 Freising. 
 Amtsgericht M?nchen HRB 40960. Gesch?ftsf?hrer: Dr. Wolfram Tietscher. 
 Vorsitzender des Aufsichtsrates: Andreas Schwaiger

 -Original Message-
 From: Peter Bigot [mailto:big...@acm.org]
 Sent: Wednesday, September 10, 2014 5:13 PM
 To: Ben Ransford
 Cc: Kees Schoenmakers; GCC for MSP430 - http://mspgcc.sf.net
 Subject: Re: [Mspgcc-users] msp430-elf-gcc (GCC) 4.9.1 20140707 (prerelease 
 (msp430-14r1-10)) (GNUPro 14r1) (Based on: GCC 4.8 GDB 7.7 Binutils 2.24 
 Newlib 2.1)

 On Wed, Sep 10, 2014 at 9:31 AM, Ben Ransford b...@ransford.org wrote:
 On Sep 10, 2014, at 7:19 AM, Kees Schoenmakers ksli...@gmail.com wrote:
 I found the archives for the newest msp430-gcc on the TI site via .
 http://www.ti.com/tool/MSP430-3P-GCC-MSPGCC-TPDE

 The production version of GCC for MSP430, which TI announced* on
 August 18, lives here:

   http://www.ti.com/tool/msp430-gcc-opensource

 ... whereas the URL you mentioned seems to refer to a beta release.

 I don't know whether the production version fixes the syntax error you
 saw, but perhaps it's worth a try.

 TI seems to change the naming conventions of the source releases with each 
 package, which also makes it difficult to figure out what's going on.  
 2.00.00's msp430-gcc-14r1-10-source.tar.bz2 is bitwise identical to 2.01.01's 
 msp430-gcc-source.tar.bz2.  Either there is no difference in the toolchain 
 between 2.00.00 and 2.01.01, or the source archive
 http://software-dl.ti.com/msp430/msp430_public_sw/mcu/msp430/MSPGCC/latest/exports/msp430-gcc-source.tar.bz2
 was not updated.

 The 2.01.01 headers files in
 http://software-dl.ti.com/msp430/msp430_public_sw/mcu/msp430/MSPGCC/latest/exports/msp430-support-files.zip
 are slightly different: USBRAM sections in linker files, cleanup of some RTC 
 defines.

 Neither situation would fix the issue with the interrupt declaration; I don't 
 know what the problem is there; probably the new toolchain requires a 
 different interrupt declaration syntax than you're using.

 Peter

 --
 Want excitement?
 Manually upgrade your production database.
 When you want reliability, choose Perforce Perforce version control. 
 Predictably reliable.
 http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk
 ___
 Mspgcc-users mailing list
 Mspgcc-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mspgcc-users


--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] Trouble using builtin function in ISR

[Peter Bigot]

You're not using mspgcc, you're using msp430-elf which is the upstream
version.  It uses different functions; I don't remember offhand how
they spelled the names, but they'll be in a header somewhere.  Should
also be compatible with  any Code Composer Studio instructions you
come across.

Peter

On Wed, Aug 13, 2014 at 12:58 PM, Christopher Toledo
uberscient...@gmail.com wrote:
 I created a gist outlining my problem here:
 https://gist.github.com/uberscientist/baa627f9779d2d08ca87

 I'll summarize:
 I create an ISR, attempt to use __bic_SR_register_on_exit inside it and I
 get an error saying:
 error: MSP430 builtin functions only work inside interrupt handlers

 How do you manipulate the SR from ISRs? Thanks!

 --

 ___
 Mspgcc-users mailing list
 Mspgcc-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mspgcc-users


--
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] tilib: MSP430_FET_FwUpdate: MSP-FET430UIF Firmware erased - Bootloader active (error = 56)

[Peter Bigot]

Run the firmware update as root.

Peter

On Thu, Jul 3, 2014 at 5:55 PM, Fávero Santos favero.san...@gmail.com wrote:
 Hello!

 I just did the flashing process on my bricked fet. The only change is that
 it initializes normally now.  When I try to access tilib with it, the board
 requires a fw update. When I insert the cmd, mspdebug tilib
 --allow-fw-update, I get stuck when it's trying to initialize the
 bootloader. Here the message:

 mspdebug tilib --allow-fw-update
 MSPDebug version 0.22 - debugging tool for MSP430 MCUs
 Copyright (C) 2009-2013 Daniel Beer dlb...@gmail.com
 This is free software; see the source for copying conditions.  There is NO
 warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

 MSP430_GetNumberOfUsbIfs
 MSP430_GetNameOfUsbIf
 Found FET: /dev/serial/by-id/../../ttyACM0
 MSP430_Initialize: /dev/serial/by-id/../../ttyACM0
 FET firmware update is required.
 Starting firmware update (this may take some time)...
 Initializing bootloader...
 Initializing bootloader...
 Initializing bootloader...
 tilib: MSP430_FET_FwUpdate: MSP-FET430UIF Firmware erased - Bootloader
 active (error = 56)
 tilib: device initialization failed

 As I said before, the bricked fet do its led initialization (3 red blinks,
 1 red blink sustained and then green sustained).

 Weird... Is it possible that the boostrap loader cannot find my firmware?
 Ps. In linux, driver is ACM0 and firmware version is 3.

 Thanks!

 Fávero

 FS

 *If it doesn't starts with you, it dies with you. *
 Julian Casablancas


 On Wed, Jul 2, 2014 at 8:13 PM, Chris Liechti cliec...@gmx.net wrote:

 Am 02.07.2014 16:58, schrieb Fávero Santos: 3) Last night I went to a
 friend's lab and managed to get a copy of a
   v2firm.

 i suggest you use your friends JTAG interface to flash yours.

 if you open the MSP-FET430UIF, you'll find a connector with one row of 5
 pins. this is the JTAG interface of the MSP430 in there and it is
 compatible with the 14 pin cable, just plug it in on the correct edge
 (connect pin 1 on 14 pin header).

 the USB interface must be plugged in to provide power but then you
 should be able to write the firmware with your friends JTAG box to your
 MSP-FET430UIF, just like you'd program any firmware on a board.

 unfortunately does the layout of the MSP-FET430UIF NOT connect the
 ROM-BSL of the contained MSP430 (at least not on previous versions of
 the board, the pins to start the BSL are not connected correctly), so if
 the firmware is broken, there is no other way than using an other JTAG
 interface to recover.

 chris


 --
 Open source business process management suite built on Java and Eclipse
 Turn processes into business applications with Bonita BPM Community Edition
 Quickly connect people, data, and systems into organized workflows
 Winner of BOSSIE, CODIE, OW2 and Gartner awards
 http://p.sf.net/sfu/Bonitasoft
 ___
 Mspgcc-users mailing list
 Mspgcc-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mspgcc-users


 --
 Open source business process management suite built on Java and Eclipse
 Turn processes into business applications with Bonita BPM Community Edition
 Quickly connect people, data, and systems into organized workflows
 Winner of BOSSIE, CODIE, OW2 and Gartner awards
 http://p.sf.net/sfu/Bonitasoft
 ___
 Mspgcc-users mailing list
 Mspgcc-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mspgcc-users


--
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] What happened to the mediawiki?

[Peter Bigot]

SourceForge killed off the hosted applications, and I forgot to move
the data somewhere else beforehand.  There should be a backup
available somewhere; if somebody wants to volunteer to handle this I
can make that person an administrator.  Otherwise, I won't be getting
to it for about two weeks.

Peter

On Thu, Jun 26, 2014 at 8:46 AM, Wouter Wieleman wiel...@gmail.com wrote:
 I wanted to look something up in the mspgcc wiki today, but it seems that
 the whole wiki is gone... All old links redirect to mspgcc sourceforge
 homepage.

 Does anybody knows what happened?

 --
 Open source business process management suite built on Java and Eclipse
 Turn processes into business applications with Bonita BPM Community Edition
 Quickly connect people, data, and systems into organized workflows
 Winner of BOSSIE, CODIE, OW2 and Gartner awards
 http://p.sf.net/sfu/Bonitasoft
 ___
 Mspgcc-users mailing list
 Mspgcc-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mspgcc-users


--
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] Packaging for msp430-elf-*

[Peter Bigot]

My recommendation is to look at what MacPorts does for gcc-arm or some
other cross-compilation GNU toolchain that produces binutils, gcc,
gdb, and library/header packages, and replicate that using the msp430
target flags.  That would seem to be the best way to produce packages
that are compatible with what users will expect.

Peter

On Thu, Jun 26, 2014 at 9:01 PM, Aljaž Srebrnič a2pirates...@gmail.com wrote:
 On 26/giu/2014, at 21:59, DJ Delorie d...@redhat.com wrote:


 Also, why are you building msp430-elf-gcc in two steps, Peter? Can I
 build newlib first and then msp430-elf-gcc?

 How do you build newlib without a C compiler?

 Ah, yes, sorry. What I meant was can msp430-elf-gcc be built without newlib? 
 I wanted to create a separate package for newlib.

 --
 Aljaž Srebrnič a.k.a g5pw
 My public key:  http://bit.ly/g5pw_pubkey


 --
 Open source business process management suite built on Java and Eclipse
 Turn processes into business applications with Bonita BPM Community Edition
 Quickly connect people, data, and systems into organized workflows
 Winner of BOSSIE, CODIE, OW2 and Gartner awards
 http://p.sf.net/sfu/Bonitasoft
 ___
 Mspgcc-users mailing list
 Mspgcc-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mspgcc-users

--
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] MSP430 instruction pipeline

[Peter Bigot]

On the whole I agree with Eric that there is little public information
about the internal CPU architecture.  If you still want to dig around,
the three data sources I'd recommend are:

* the CPU sections of the various family users guides, in particular
the instruction timing tables.  Differences among the instructions
based on source and destination alternatives, as well as the same
instruction on CPU and CPUX, suggest pipeline differences.

* various postings on
http://e2e.ti.com/support/microcontrollers/msp430/default.aspx, though
realize that most will be speculation.

* experimentation to time the duration of different sequences.
https://github.com/pabigot/bsp430/blob/master/examples/platform/cpu42/main.c
 uses a low-speed clock technique that tests whether erratum CPU42
(the CPUX bug about EINT without NOP) is present on a particular
device.  Adapt that to use a clock source synchronized with MCLK
instead, and put the reads around the sequence to be timed instead of
adjacent.

Peter

On Mon, Jun 16, 2014 at 10:36 PM, Jose Luis Honorato L.
joseluishonor...@gmail.com wrote:
 Hi,

 An e-mail from Peter a few days ago hinted the existence of an instruction
 pipeline in msp430. It is barely mentioned in the docs and Google results
 only seem to mention the lack of information about it.

 I'd like to read more, does anyone know where to look?

 Thanks in advance,
 Jose

 --
 HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
 Find What Matters Most in Your Big Data with HPCC Systems
 Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
 Leverages Graph Analysis for Fast Processing  Easy Data Exploration
 http://p.sf.net/sfu/hpccsystems
 ___
 Mspgcc-users mailing list
 Mspgcc-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mspgcc-users


--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing  Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

[Mspgcc-users] bug in TI in430.h implementation

[Peter Bigot]

(Cross-posted from
http://e2e.ti.com/support/microcontrollers/msp430/f/166/t/348108.aspx
since it's not clear how TI wants to receive bug reports related to
the new toolchain.)

Back when I added intrinsics to mspgcc I got confirmation that CCS and
IAR both implicitly added the required NOP after a DINT instruction
generated with _disable_interrupts().  (The MSP430 instruction set
explains that this is necessary to eliminate the possibility of
interrupting a subsequent pipelined instruction.)

The implementation of _disable_interrupts() in in430.h from TI's
GCC_RH_20140508.zip does not include this required instruction, making
it inconsistent with all other MSP430 toolchains.  (Fortunately,
msp430-elf does generate a warning in this situation.)

Interestingly, the implementation of _enable_interrupts()
unconditionally adds a NOP after EINT, even though that workaround is
arguably required only on certain devices with a specific erratum, and
this behavior is AFAIK also inconsistent with other toolchains.

msp430-elf should behave as close to CCS and IAR as possible so
developers don't have to work around toolchain-specific
inconsistencies in how these operations are implemented.

TI, please fix this for the next header release.

Please also add a monotonically increasing version number to in430.h
or iomacros.h so applications can work around bugs like this.

Thanks.

Peter

--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing  Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] MSP430 simulator in gdb

[Peter Bigot]

On Tue, Jun 3, 2014 at 6:35 PM, DJ Delorie d...@redhat.com wrote:

 You can do that with the RH newlib as long as you don't link in
 libgloss's versions of the low-level routines - i.e. remove -lgloss
 from your link line and add -lbspacm.

 To clarify: don't link in -lnosys if you're not compiling with -msim
 or don't link in -lsim if you are compiling with -msim

 Both of these are linked at the same point as libc and libgcc, by the
 gcc driver, depending on whether or not you use the -msim option.

Yes, first impressions suggest if I could get rid of libgloss entirely
I could do what I want.

But since gcc's LIB_SPEC helpfully adds -lnosys for me at no extra
charge when I don't use -msim, how can I avoid linking it in?

Peter

--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their 
applications. Written by three acclaimed leaders in the field, 
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

[Mspgcc-users] replacing libgloss in msp430-elf

[Peter Bigot]

Starting a new thread since this is off-topic for MSP430 simulator in gdb.

The discussion is how to take advantage of newlib's libc
infrastructure while replacing the system interface that is by default
provided by libgloss: i.e. implementations of
read()/write()/sbrk()/gettimeofday() and other functions that
interface with a host environment (hardware, OS framework, simulator,
whatever).

The msp430-elf port appears to make this difficult in two ways:

1) gcc has a hard-coded LIB_SPEC that automatically adds -lnosys
whenever  the user fails to specify the simulator as the target.  The
need in the situation being discussed is to provide an alternative
implementation to -lnosys.  I've worked around this by removing
%{!msim:-lnosys} from LIB_SPEC and building a new toolchain.

2) The msp430 port of newlib is nearly unique in discarding the
libnosys implementation provided by newlib in favor of its own
crippled implementation.  (Of the dozen+ supported newlib targets
spu-* is the only other one that does this).  I've worked around this
by patching the msp430 target to remove the CIO-based -lnosys provided
libgloss/msp430/Makefile.in and instead keep the default
config_libnosys=true, leveraging the standard libgloss stub system
function implementation.

I've verified that with this toolchain I can use the newlib standard
option -specs=nosys.specs to link applications with the stubbed
version from libgloss for cases where I don't want to replace the
implementation.  I've also done enough testing to be convinced I can
provide an alternative implementation of the system interface
functions, as is normally permitted by newlib.

However, the changes necessary to make this work require building a
special version of the toolchain with modified upstream sources.
Works for me; not really acceptable to most users.  So presumably this
isn't the way I'm supposed to do this.

How am I supposed to do this?

Peter

On Thu, Jun 5, 2014 at 6:09 AM, Peter Bigot big...@acm.org wrote:
 On Tue, Jun 3, 2014 at 6:35 PM, DJ Delorie d...@redhat.com wrote:

 You can do that with the RH newlib as long as you don't link in
 libgloss's versions of the low-level routines - i.e. remove -lgloss
 from your link line and add -lbspacm.

 To clarify: don't link in -lnosys if you're not compiling with -msim
 or don't link in -lsim if you are compiling with -msim

 Both of these are linked at the same point as libc and libgcc, by the
 gcc driver, depending on whether or not you use the -msim option.

 Yes, first impressions suggest if I could get rid of libgloss entirely
 I could do what I want.

 But since gcc's LIB_SPEC helpfully adds -lnosys for me at no extra
 charge when I don't use -msim, how can I avoid linking it in?

 Peter

--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their 
applications. Written by three acclaimed leaders in the field, 
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] replacing libgloss in msp430-elf

[Peter Bigot]

On Thu, Jun 5, 2014 at 4:48 PM, DJ Delorie d...@redhat.com wrote:

 The reason msp430 is different is because CIO *can* be used on real
 hardware, to communicate through a hardware debugger or emulator pod.

 Perhaps moving the cio-enabled nosys to a libcio.a?  Then we'd need a
 -mcio option to gcc to enable it, but could default to doing the
 generic nosys thing...

I like that approach; it makes clear that the system interface is
still CIO even when not using -msim, and it gives application
developers the appropriate level of control when CIO is not desired.
Making selection of -mcio a positive decision (not default) also helps
reveal when an application unintentionally introduces dependencies
such as calls to sbrk (malloc) for newlib internal data structures
that most mspgcc developers would be surprised to find happening (they
did not occur with the same functions in msp430-libc).

What needs to be done to get this into place?  Do you need an
enhancement request in gcc and/or newlib bugzilla?

Peer

--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their 
applications. Written by three acclaimed leaders in the field, 
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] MSP430 simulator in gdb

[Peter Bigot]

On Tue, Jun 3, 2014 at 1:10 PM, Mark Rages markra...@gmail.com wrote:
 On Tue, Jun 3, 2014 at 11:57 AM, DJ Delorie d...@redhat.com wrote:


  Is there any best way to pass data in / out of the simulator?  I
  guess I can use the run program and set up a memory region for the
  input data, and write a little main() to feed it into through the
  algorithm.  But if there's an easier way, I'd like to hear about it
  before I do it the hard way.

 If you link in your input data via a linker script, and write() out
 the output data to stdout and redirect it, it should be pretty easy to
 set up.


 Wait, a write() syscall made in the msp430 binary can show up on stdout of
 the simulator?  How does that work?  Do I need to link in any special
 function for that?

You need to be using msp430-elf-gcc for that feature, not mspgcc as
described in your first email.  I don't believe msp430-elf is packaged
by debian yet, though you can probably use the precompiled version
available from TI (details elsewhere in the archive).

Peter

--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their 
applications. Written by three acclaimed leaders in the field, 
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] MSP430 simulator in gdb

[Peter Bigot]

On Tue, Jun 3, 2014 at 1:26 PM, DJ Delorie d...@redhat.com wrote:

 Wait, a write() syscall made in the msp430 binary can show up on stdout of
 the simulator?  How does that work?  Do I need to link in any special
 function for that?

 The RH simulator (msp430-elf-run, not msp430-run) supports TI's CIO
 interface, at least for write(), which means the RH simulator can
 write to stdout (we use it for testing).  CIO supports a range of file
 I/O operations, but we only implemented write().

 The code in libgloss (part of newlib) has an implementation of CIO
 and write() that works with the simulator.

Somewhat off the specific topic but relevant to the feature: when I
last asked there was no public documentation on this CIO interface.
It communicates with something through an undocumented structure
__CIOBUF__TYPE___ but provides no information on what parameters are
expected for the dozen functions listed (of which two are
implemented).  Looking at the source, I guess it's probably related to
the more complete tic6x CIO implementation.

Will TI be providing sufficient documentation on the CIO API that the
msp430 implementation can be completed, thus making the system
interface usable in other frameworks?

I personally would wish that newlib prefer APIs that are not
proprietary.  My intent for my own msp430-elf projects is to implement
a msp430 libgloss approach that's much closer to what was done in the
arm target for libgloss.  If there's a chance that'd be adopted
upstream as an alternative to the CIO one, it'd motivate me to make
that a priority.

(FWIW: I now have official support for msp430-elf in BSP430, and lack
of a robust system interface is all that's stopping me from being able
to develop real applications in the new toolchain.)

Peter

--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their 
applications. Written by three acclaimed leaders in the field, 
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] MSP430 simulator in gdb

[Peter Bigot]

On Tue, Jun 3, 2014 at 1:55 PM, DJ Delorie d...@redhat.com wrote:

 Will TI be providing sufficient documentation on the CIO API that the
 msp430 implementation can be completed, thus making the system
 interface usable in other frameworks?

 I have enough information to finish the msp interface, I've just had
 no reason to do so so far.

That doesn't really help the rest of us, though.

  CIO doesn't have exit() though so the RH
 simulator *also* has its own syscall interface, just for that call.
 If you just want to exit cleanly a branch-to-self opcode will also
 trigger an exit(0) from the RH simulator.

Which is fine, but I'm not interested in interfacing with either the
TI or RH simulators.  I'm interfacing with other external hardware
including LCDs and FAT file systems, and I want to re-use the standard
libc interface at the application layer.

 I personally would wish that newlib prefer APIs that are not
 proprietary.  My intent for my own msp430-elf projects is to implement
 a msp430 libgloss approach that's much closer to what was done in the
 arm target for libgloss.  If there's a chance that'd be adopted
 upstream as an alternative to the CIO one, it'd motivate me to make
 that a priority.

 CIO was used at TI's request, to be compatible with their simulators
 and their hardware drivers - I.e. a CIO library in your app would work
 in the simulator *and* on real hardware - I think this works with
 msp430-elf-gdb also.

Perfectly understandable that since TI's paying you to do this, they
get to choose the default implementation.

Like Mark, one of my needs is for input as well as output.  For ARM, I
can take a binary toolchain from launchpad with a pre-built newlib and
substitute a new system interface that meets my requirements.  As long
as I can do the same thing for the msp430 one, I'll have no issues
with the default solution being CIO.

Peter

--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their 
applications. Written by three acclaimed leaders in the field, 
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] MSP430 simulator in gdb

[Peter Bigot]

On Tue, Jun 3, 2014 at 2:55 PM, DJ Delorie d...@redhat.com wrote:
 file systems, and I want to re-use the standard libc interface at
 the application layer.

 Could you elaborate on this?  Are you talking about real hardware
 talking to real peripherals, or is there a host involved?

I'd already outlined my expectations in the earlier thread; see for
example 
http://www.mail-archive.com/mspgcc-users@lists.sourceforge.net/msg12038.html.
 If the msp430 version supplies a weak definition of _write() (not
write()) that goes through CIO, we're good because I can replace it
with one that delegates to a descriptor-specific implementation.  If
the definitions aren't weak, we're probably not good.

I'll hold off on further comment until I have an opportunity to see
what actually needs to be done to make this work.  I expect something
that allows me to do for the msp430 what I did for ARM as described
at: http://pabigot.github.io/bspacm/newlib.html#newlib_sys

Peter

--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their 
applications. Written by three acclaimed leaders in the field, 
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] bug in binutils master specific to msp430-elf

[Peter Bigot]

On Sun, Jun 1, 2014 at 11:15 PM, Alan Modra amo...@gmail.com wrote:
 On Sun, Jun 01, 2014 at 07:54:58PM -0500, Peter Bigot wrote:
 77ac17b8453f60adabaa8931930e2bbe0499757d is the first bad commit
 commit 77ac17b8453f60adabaa8931930e2bbe0499757d
 Author: Hans-Peter Nilsson h...@bitrange.com
 Date:   Wed May 28 18:20:16 2014 +0200

 ld: Split GENSCRIPTS rule from dependencies to fix tdir_'s.

 * Makefile.am: Change all rules with ${GENSCRIPTS}
 invocations to be just dependencies.
 ($(ALL_EMULATION_SOURCES) $(ALL_64_EMULATION_SOURCES))
 (run-genscripts): New rules.
 * Makefile.in: Regenerate.

 It's because msp, along with bfin and score, take an extra argument to
 the genscript invocation.  I think the following should cure the
 problem you're seeing, but it leads to a bunch of warnings

 Makefile:2400: warning: overriding commands for target `eelf32bfin.c'
 Makefile:2105: warning: ignoring old commands for target `eelf32bfin.c'
 Makefile:2406: warning: overriding commands for target `eelf32bfinfd.c'
 Makefile:2105: warning: ignoring old commands for target `eelf32bfinfd.c'
 Makefile:2940: warning: overriding commands for target `emsp430.c'
 Makefile:2105: warning: ignoring old commands for target `emsp430.c'
 Makefile:2945: warning: overriding commands for target `emsp430X.c'
 Makefile:2105: warning: ignoring old commands for target `emsp430X.c'
 Makefile:3048: warning: overriding commands for target `escore3_elf.c'
 Makefile:2105: warning: ignoring old commands for target `escore3_elf.c'
 Makefile:3053: warning: overriding commands for target `escore7_elf.c'
 Makefile:2105: warning: ignoring old commands for target `escore7_elf.c'

 I think I'll look at a different solution, renaming some ld/emulparams
 files instead.

Thanks; your commit ce46249c155b7 fixes it for me.

Peter

--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their 
applications. Written by three acclaimed leaders in the field, 
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

[Mspgcc-users] bug in binutils master specific to msp430-elf

[Peter Bigot]

I build msp430-elf toolchains using the latest material in the
gcc-4_9-branch of gcc, master of binutils, and master of newlib.  In
what follows I've set RHINC to point to the include directory from
GCC_RH-20140508  that has the headers and linker scripts.

There is a fault in binutils introduced at 77ac17b8 which causes
msp430-elf-ld to fail to link applications.  I get this behavior:

llc[186]$ cat x.c
#include msp430.h

void main (void)
{
}

llc[187]$ /usr/local/msp430-elf-dev-20140601h/bin/msp430-elf-gcc
-mmcu=msp430f5438a -I${RHINC} -T${RHINC}/msp430f5438a.ld x.c

llc[188]$ /usr/local/msp430-elf-dev-20140601j/bin/msp430-elf-gcc
-mmcu=msp430f5438a -I${RHINC} -T${RHINC}/msp430f5438a.ld x.c
/usr/local/msp430-elf-dev-20140601h/lib/gcc/msp430-elf/4.9.1/../../../../msp430-elf/bin/ld:
target  not found
collect2: error: ld returned 1 exit status

The second produces a diagnostic from open_output in ld/ldlang.c where
output_target is an empty string.

The only difference between these two chains is the version of binutils:

llc[189]$  cat /usr/local/msp430-elf-dev-20140601h/.sha1.binutils
77ac17b8453f60adabaa8931930e2bbe0499757d
llc[190]$  cat /usr/local/msp430-elf-dev-20140601j/.sha1.binutils
9854d43d40fc116d72a24583f53e34f91cf4098b

A cursory look at the commit doesn't explain why this might happen,
unless msp430 requires that ${GENSCRIPTS} be invoked for some reason.

77ac17b8453f60adabaa8931930e2bbe0499757d is the first bad commit
commit 77ac17b8453f60adabaa8931930e2bbe0499757d
Author: Hans-Peter Nilsson h...@bitrange.com
Date:   Wed May 28 18:20:16 2014 +0200

ld: Split GENSCRIPTS rule from dependencies to fix tdir_'s.

* Makefile.am: Change all rules with ${GENSCRIPTS}
invocations to be just dependencies.
($(ALL_EMULATION_SOURCES) $(ALL_64_EMULATION_SOURCES))
(run-genscripts): New rules.
* Makefile.in: Regenerate.

:04 04 bd02f74300dab8958bc24165a23661e0d939889f
388df7b3ae54aabf53d35973a09bcc94fa1f91b5 M  ld

--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their 
applications. Written by three acclaimed leaders in the field, 
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] Are here any msp430-elf target full toolchain build instructions a'la gcc-arm-embedded?

[Peter Bigot]

A chain of messages related to building and packaging is available at:

http://www.mail-archive.com/mspgcc-users@lists.sourceforge.net/msg12028.html

At least two of us have successfully built toolchains with those
instructions; how to convert them into packaging for a particular
distribution isn't something that's likely to come from this list.  My
recommendation is follow the distribution's standard practices for
cross-compilation toolchains and look to existing solutions like AVR
and ARM for guidance.

TI makes some material available on:
http://www.ti.com/tool/msp430-gcc-opensource

Personally I would not package a vendor-supplied fork, but that's a
policy decision for the distribution.

I notice that the most recent TI toolchain 371 (which is an update to
version 317 that comes with the CCS 6.0.0-190 release) has been posted
there in binary and source form.  The old source releases have been
removed.  I've reminded TI that the GPL licensing may require that
they remain available but am leaving any fights in that battle to
anybody who cares.

The upstream software (gcc, binutils, newlib) is incomplete: you do
need the headers and linker files from TI, which are available on TI's
page.   TI has not provided recommended integration practices for the
headers and linker scripts, nor promises related to
maintenance/compatibility/etc, so we're on our own.  In the days of
mspgcc those were carefully separated out as msp430mcu so you could
update the available MCUs without updating the toolchain; it would be
nice if new packaging solutions followed that practice.  Although I've
preferred to install those out-of-tree and add compiler flags so the
toolchain locates them, I think it's better to follow Eric's
recommendations in
http://www.mail-archive.com/mspgcc-users%40lists.sourceforge.net/msg12046.html
and overlay them into the toolchain installation directory so they're
found without special arguments.

I noticed that __delay_cycles has been pushed to gcc trunk (though not
gcc-4_9-branch) so when I finish some other projects I'll be coming
back and checking out the latest versions of everything.  newlib-nano
does work, though I'm still unhappy with the vendor-specific and
undocumented sys interface, and may fork an alternative.  C++ is
viable but using C++ runtime features is probably not practical due to
code size.

Once I've switched to using msp430-elf-gcc all pretense that mspgcc is
supported will vanish.  Unofficially, that's already occurred.

Peter


On Mon, May 19, 2014 at 3:52 AM, Lev Serebryakov l...@serebryakov.spb.ru 
wrote:
 Hello, DJ.
 You wrote 19 мая 2014 г., 1:15:28:

  It looks like that this toolchain is not ready for packaging :(

  binutils-2.24 could not build newlib-2.1 (known problem, according to this
  list).

  Latest binutils (2.24.51) could not be built by itself, due to errors:

 cc -DHAVE_CONFIG_H -I. 
 -I/usr/home/lev/FreeBSD/ports/devel/gcc-msp430-embedded/work/binutils-2.24.51/binutils
   -I. 
 -I/usr/home/lev/FreeBSD/ports/devel/gcc-msp430-embedded/work/binutils-2.24.51/binutils
  -I../bfd 
 -I/usr/home/lev/FreeBSD/ports/devel/gcc-msp430-embedded/work/binutils-2.24.51/binutils/../bfd
  
 -I/usr/home/lev/FreeBSD/ports/devel/gcc-msp430-embedded/work/binutils-2.24.51/binutils/../include
  
 -DLOCALEDIR=\/usr/home/lev/FreeBSD/ports/devel/gcc-msp430-embedded/work/install/gcc-msp430-embedded-2.24.51.4.9.0.2.1.0/share/locale\
  -Dbin_dummy_emulation=bin_vanilla_emulation  -W -Wall -Wstrict-prototypes 
 -Wmissing-prototypes -Wshadow -Werror -O2 -pipe -fno-strict-aliasing 
 -Wno-error -MT bucomm.o -MD -MP -MF .deps/bucomm.Tpo -c -o bucomm.o 
 /usr/home/lev/FreeBSD/ports/devel/gcc-msp430-embedded/work/binutils-2.24.51/binutils/bucomm.c
 /usr/home/lev/FreeBSD/ports/devel/gcc-msp430-embedded/work/binutils-2.24.51/binutils/bucomm.c:130:1:
  error: variable has incomplete type 'void'
 fatal VPARAMS ((const char *format, ...))
 ^
 /usr/home/lev/FreeBSD/ports/devel/gcc-msp430-embedded/work/binutils-2.24.51/binutils/bucomm.c:130:6:
  error: expected ';' after top level declarator
 fatal VPARAMS ((const char *format, ...))
  ^
  ;
 2 errors generated.
 gmake[6]: *** [bucomm.o] Error 1


  And there is not intermediate snapshots between them!

 --
 // Black Lion AKA Lev Serebryakov l...@serebryakov.spb.ru


 --
 Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
 Instantly run your Selenium tests across 300+ browser/OS combos.
 Get unparalleled scalability from the best Selenium testing platform available
 Simple to use. Nothing to install. Get started now for free.
 http://p.sf.net/sfu/SauceLabs
 ___
 Mspgcc-users mailing list
 Mspgcc-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mspgcc-users

--
Accelerate Dev Cycles with Automated Cross-Browser 

Re: [Mspgcc-users] Are here any msp430-elf target full toolchain build instructions a'la gcc-arm-embedded?

[Peter Bigot]

On Mon, May 19, 2014 at 8:36 AM, Lev Serebryakov l...@serebryakov.spb.ru 
wrote:
 Hello, Peter.
 You wrote 19 мая 2014 г., 15:04:05:

 PB A chain of messages related to building and packaging is available at:
 PB 
 http://www.mail-archive.com/mspgcc-users@lists.sourceforge.net/msg12028.html
 PB At least two of us have successfully built toolchains with those
 PB instructions; how to convert them into packaging for a particular
 PB distribution isn't something that's likely to come from this list.  My
 PB recommendation is follow the distribution's standard practices for
 PB cross-compilation toolchains and look to existing solutions like AVR
 PB and ARM for guidance.
   Problem with this instructions starts from very beginning:

 binutils git://sourceware.org/git/binutils-gdb.git master
 gcc git://gcc.gnu.org/git/gcc.git gcc-4_9-branch
 newlib git://sourceware.org/git/newlib.git master

  Not-released software could not be packaged! We could only refer to stable,
 non-changeable, tarballs on vendor's server, not to some git revision or
 some ${packaghename}.tar.bz2, which could be changed (re-rolled) under same
 name :(

This is a distribution policy.  Most distributions have a solution for
that problem, based on an archived canonical tarball.  Some, like
Yocto, even extend that to support packaging never-released versions
through reference to a git SHA1 or SVN commit in a public repository
branch that the maintainers promise to never rebase.

There are also release branches in those repositories which you could
try (gcc-4_9-branch is one of them).

  It is not exactly how to convert them into packaging for a particular 
 distribution
 isn't something that's likely to come from this list., it is discussion
 about status of toolchain which, as I could say now, is not ready for
 distro-packaging due to absence of any suitable releases, may be,
 snapshot-quality, but stable in sense of content.

If you mean that strictly, I don't think it'll be true for
msp430-elf-gcc until all the component packages have stable releases
that are known to interoperate, and possibly never unless TI promises
not to changed (re-rolled) under same name the pieces that are only
available from them, and makes the material compatible with those
stable releases rather than just their fork.

You may be waiting a while.

 PB Personally I would not package a vendor-supplied fork, but that's a
 PB policy decision for the distribution.
  Yep, but on other hand it is stable, well-named file :)

Perhaps.  Certainly using that instead of the upstream versions is a
choice a distribution might make.

 PB Once I've switched to using msp430-elf-gcc all pretense that mspgcc is
 PB supported will vanish.  Unofficially, that's already occurred.
  Anyway, thank you for all you work on mspgcc!

You're welcome.

Peter

--
Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free.
http://p.sf.net/sfu/SauceLabs
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] msp430-elf-gcc upcoming release

[Peter Bigot]

On Tue, Apr 22, 2014 at 1:00 PM, DJ Delorie d...@redhat.com wrote:
 * __delay_cycles() didn't get back-ported from the version that TI
 published back in December

 My bad.  I can provide it if anyone needs it, but I'll see about
 adding it to the 4.9 branch.

Any idea when this might happen?  I appreciate the offer for a private
patch, but this feature needs to be upstream and on trunk as well as
the release branch.

FWIW, I'm unable to find the sources for msp430-130423-317 as
delivered in CCS6 on http://www.ti.com/tool/msp430-gcc-opensource.  If
any TI folks are still here, that really ought to be addressed.

Peter

--
Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free.
http://p.sf.net/sfu/SauceLabs
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] msp430-elf-gcc upcoming release

[Peter Bigot]

On Wed, Apr 23, 2014 at 9:14 AM, Grant Edwards
grant.b.edwa...@gmail.com wrote:
 On 2014-04-22, DJ Delorie d...@redhat.com wrote:

 I was surprised to see DJ's comment that there actually was no
 standard system interface; the standard interface I was referring to
 is the one documented at http://neptune.billgatliff.com/newlib.html

 The key to a successfully ported newlib is providing stubs that
  bridge the gap between the functionality newlib needs, and what your
  target system can provide.

 This bridge is what I was referring to.  Newlib calls read() but does
 not provide an implementation of it.  Libgloss provides various
 target-specific implementations of read(), the one I wrote for msp430
 uses CIO to communicate with the simulator/debugger.

 Why is newlib calling read(), and from what is it expecting to read?

 I was expecting for MSP430 to also simply implement the functions
 stubbed in newlib's libnosys, but at first glance it looks like the
 CIO one uses different names, and maybe doesn't support all the same
 functions.

 Hmmm... it should be all the same names.  I only changed the existing
 libgloss hooks.  But, I don't always do all the hooks, usually only
 write() and exit() are needed for our testing.

 Again, why should newlib be calling write() and what is it expecting
 to write _to_?

 What does it expect exit() to do?

Again: whatever the environment wants it to do.  In my case, I'm using
printf(3c) in my code, and I want it to output to one of the UARTs,
which newlib accommodates by using write(2) to descriptor 1, just like
any other standard C library.   This works because I supply a _write()
function that does that.   Or maybe it sends the data to an LCD.
Maybe exit() starts blinking a red LED if the return code isn't zero.
Whatever any of the system functions do, it's my choice, and I like
that newlib allows me that control.

Peter

--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] msp430-elf-gcc upcoming release

[Peter Bigot]

On Wed, Apr 23, 2014 at 9:57 AM, Grant Edwards
grant.b.edwa...@gmail.com wrote:
 On 2014-04-23, Peter Bigot big...@acm.org wrote:

 Again: whatever the environment wants it to do.  In my case, I'm
 using printf(3c) in my code, and I want it to output to one of the
 UARTs, which newlib accommodates by using write(2) to descriptor 1,
 just like any other standard C library.

 This works because I supply a _write() function that does that.

 But it's not called like a normal C function, it goes through some
 sort of syscall interface so you don't actually link your _write()
 function with newlib?

See http://pabigot.github.io/bspacm/newlib.html#newlib_sys


 Or maybe it sends the data to an LCD. Maybe exit() starts blinking a
 red LED if the return code isn't zero. Whatever any of the system
 functions do, it's my choice, and I like that newlib allows me that
 control.

 Hmm. Is there an option to build a non-hosted version of newlib which
 doesn't assume any underlying OS support.

Yes, also described at that link, and possibly at the gatliff link I
gave earlier.

Peter


 --
 Grant Edwards   grant.b.edwardsYow! Is it 1974?  What's
   at   for SUPPER?  Can I spend
   gmail.commy COLLEGE FUND in one
wild afternoon??


 --
 Start Your Social Network Today - Download eXo Platform
 Build your Enterprise Intranet with eXo Platform Software
 Java Based Open Source Intranet - Social, Extensible, Cloud Ready
 Get Started Now And Turn Your Intranet Into A Collaboration Platform
 http://p.sf.net/sfu/ExoPlatform
 ___
 Mspgcc-users mailing list
 Mspgcc-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mspgcc-users

--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

[Mspgcc-users] msp430-elf-gcc upcoming release

[Peter Bigot]

Back in mid April GCC forked off a branch for 4.9.0, which will be the
first release of GCC that supports the MSP430.  I've verified basic
functionality with:

binutils git://sourceware.org/git/binutils-gdb.git master
gcc git://gcc.gnu.org/git/gcc.git gcc-4_9-branch
newlib git://sourceware.org/git/newlib.git master

A couple issues:

* The only headers/linker scripts available are from
GCC_RH_20131206.zip; memory.ld and peripherals.ld for each MCU need to
be manually combined to get something binutils can process

* __delay_cycles() didn't get back-ported from the version that TI
published back in December

msp430-elf-gdb also doesn't appear to work with mspdebug:

(gdb) target remote :2000
Remote debugging using :2000
Reply contains invalid hex digit 59

I expect there'll be some issues with newlib as well; it appears to
use a unique syscall interface that I haven't tried to reverse
engineer.  However, I'm unsure the flags I used are appropriate (they
derive from the ones used for arm-gcc).  I do know that newlib without
the nano enhancements will not be acceptable for MSP430 work.  Insight
from Red Hat on a complete set of recommended flags known to work
together would be appreciated.

Below is the script I use for building, with
/opt/{binutils,gcc,newlib} being git workspaces checking out the
branches named above.  To help ensure the new toolchain is as good as
possible when it's first released, mspgcc users please try it and
report problems to Red Hat through whatever mechanism they prefer,
either here or on the upstream toolchain support lists.

Peter

TODATE=$(date +%Y%m%d)
PREFIX=/usr/local/msp430-elf-dev-${TODATE}
rm -rf ${PREFIX}
export PATH=${PREFIX}/bin:${PATH}

rm -rf binutils  mkdir binutils  cd binutils
/opt/binutils/configure --prefix=${PREFIX} --target=msp430-elf 21 | tee co
make -j8 21 | tee mo
make install 21 | tee moi
cd ..

rm -rf gcc  mkdir gcc  cd gcc
/opt/gcc/configure --prefix=${PREFIX} --target=msp430-elf
--with-newlib --enable-languages=c,c++ 21 | tee co
make -j12 all-host 21 | tee moah
make install-host 21 | tee moiah
cd ..

rm -rf newlib  mkdir newlib  cd newlib
/opt/newlib/configure \
  --prefix=${PREFIX} \
  --target=msp430-elf \
  --disable-newlib-supplied-syscalls\
  --enable-newlib-reent-small   \
  --disable-newlib-fvwrite-in-streamio  \
  --disable-newlib-fseek-optimization   \
  --disable-newlib-wide-orient  \
  --enable-newlib-nano-malloc   \
  --disable-newlib-unbuf-stream-opt \
  --enable-lite-exit\
  --enable-newlib-global-atexit \
  --disable-nls
 21 | tee co
make 21 | tee mo
make install 21 | tee moi
cd ..

cd gcc
make -j12 all-target 21 | tee moat
make install-target 21 | tee moiat
cd ..

--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] msp430-elf-gcc upcoming release

[Peter Bigot]

On Tue, Apr 22, 2014 at 5:00 PM, Daniel Beer dlb...@gmail.com wrote:
 On Tue, Apr 22, 2014 at 10:34:30AM -0500, Peter Bigot wrote:
 msp430-elf-gdb also doesn't appear to work with mspdebug:

 (gdb) target remote :2000
 Remote debugging using :2000
 Reply contains invalid hex digit 59

 I have a possible fix for this, but I haven't tried it myself. The
 problem is that it's not possible to simultaneously satisfy
 msp430-elf-gdb and msp430-gdb:

Maybe a command-line argument?

This fix works, by the way.  Very nice.

Peter


 diff --git a/ui/gdb.c b/ui/gdb.c
 index c500d83..8590667 100644
 --- a/ui/gdb.c
 +++ b/ui/gdb.c
 @@ -239,11 +239,8 @@ static int run_final_status(struct gdb_data *data)
 address_t value = regs[i];
 int j;

 -   /* NOTE: this only gives GDB the lower 16 bits of each
 -*   register. It complains if we give the full data.
 -*/
 gdb_printf(data, %02x:, i);
 -   for (j = 0; j  2; j++) {
 +   for (j = 0; j  4; j++) {
 gdb_printf(data, %02x, value  0xff);
 value = 8;
 }

--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] msp430-elf-gcc upcoming release

[Peter Bigot]

On Tue, Apr 22, 2014 at 4:53 PM, Grant Edwards
grant.b.edwa...@gmail.com wrote:
 On 2014-04-22, Peter Bigot big...@acm.org wrote:

 I expect there'll be some issues with newlib as well; it appears to
 use a unique syscall interface that I haven't tried to reverse
 engineer.

 I don't understand.  A syscall API is usually the interface between
 libc code (which is running in user mode) and an underlying OS kernel
 that's running in protected mode.  Into what What OS kernel is newlib
 expecting to be able to make syscalls?

Whatever simulated environment is provided by the application or the
framework newlib links to, so as to support stdc library functions.

I was surprised to see DJ's comment that there actually was no
standard system interface; the standard interface I was referring to
is the one documented at http://neptune.billgatliff.com/newlib.html
which matches what I found in gcc-arm-embedded.  I have a (IMO) very
nice infrastructure supporting a variety of memory allocators and file
descriptors for BSPACM (a cross-vendor ARM Cortex-M infrastructure;
http://pabigot.github.io/bspacm/newlib.html#newlib_sys).

I was expecting for MSP430 to also simply implement the functions
stubbed in newlib's libnosys, but at first glance it looks like the
CIO one uses different names, and maybe doesn't support all the same
functions.


 For example, the syscall interface I deal with is the API between
 either glibc or uclibc and the Linux kernel.  It's architecture
 specific, since the the mechanism for swithcing to/from protected mode
 usually has to be done in assembler.  It's typically something like:

   * Load parameters in to specific registers

   * Execute some variety of SWI instruction to generate a hardware
 exception/interrupt.

 --
 Grant Edwards   grant.b.edwardsYow! Actually, what I'd
   at   like is a little toy
   gmail.comspaceship!!


 --
 Start Your Social Network Today - Download eXo Platform
 Build your Enterprise Intranet with eXo Platform Software
 Java Based Open Source Intranet - Social, Extensible, Cloud Ready
 Get Started Now And Turn Your Intranet Into A Collaboration Platform
 http://p.sf.net/sfu/ExoPlatform
 ___
 Mspgcc-users mailing list
 Mspgcc-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mspgcc-users

--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] Executing code from RAM

[Peter Bigot]

On Fri, Apr 18, 2014 at 3:55 AM, Tomek Lorek tlo...@gmail.com wrote:
 Suppose you have a app() function:

 __attribute__((section(.app_main)))
 void app() {
   // body
 }

 Copy-paste error: it should be
 __attribute__((section(.mysection)))
 void app() {
   // body
 }

 this is aligned with position forced with
 __attribute__((section(.mysection)))

 Best Regards,
 Tomek

 2014-04-18 10:53 GMT+02:00 Tomek Lorek tlo...@gmail.com:
 Hi,
 I'd like to make some functions to be executed from RAM. There are
 some nice examples of how this can be done in CCS (e.g
 http://embedded-funk.blogspot.com/2013/11/running-c-function-in-ram-on-msp430.html)
 but the syntax of TI linker's .cmd file is not compatibile with GNU ld
 (specifically the load and run parts of .ram_code : load =
 FLASH_RAM_CODE, run = RAM_CODE makes ld to raise the syntax error).

 Suppose you have a app() function:

 __attribute__((section(.app_main)))
 void app() {
   // body
 }

 The code needs to be copied from flash (position forced with
 __attribute__((section(.mysection to RAM (with memcpy), but
 assuming they have the same name how to make the microcontroller run
 the copied function from RAM not the original one from flash when
 called app();

Without looking at the example code you cited: don't give them the same name.

In general, create a pointer-to-function and invoke through it.

  void (* fp)() = ram_where_code_copied;
  fp();

Peter

 ?

 Thanks in advance!

 Best Regareds,
 Tomek

 --
 Learn Graph Databases - Download FREE O'Reilly Book
 Graph Databases is the definitive new guide to graph databases and their
 applications. Written by three acclaimed leaders in the field,
 this first edition is now available. Download your free book today!
 http://p.sf.net/sfu/NeoTech
 ___
 Mspgcc-users mailing list
 Mspgcc-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mspgcc-users

--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] Can the RESET_VECTOR be redefined at compile time to a specific value?

[Peter Bigot]

 For what you're doing, you'll want to become familiar with the crt0.S
script from the libgcc/config/msp430 directory of the mspgcc gcc
source.  For simple things you won't need a custom linker script; for
complex things, make sure your modified version doesn't deviate too
far from the standard ones.

Yes, if you define a naked function named _reset_vector__ that's in
section .init0 the mspgcc linker scripts will use it instead of the
default one.

You'd want to do something like:

__attribute__((__naked__,__section__(.init0)))
void _reset_vector (void)
{
   /* stuff goes here */
}

Peter

On Fri, Apr 18, 2014 at 12:08 PM, Tomek Lorek tlo...@gmail.com wrote:
 Hi,
 My use case is the following: I have a bootloader (up to 4K in size,
 residing at 0x4400 to 0x5400) that has a main() function and
 application (starting from 0x4800) – they are organized as 2 separate
 projects (I want the bootloader to be flashed only once and not
 changed later).

 I am using mspgcc.

 Bootloader and application linker scripts are defined so that their
 .text sections (that go to “rom” memory region) are separated but they
 use the same “vector” memory region for .vector section (although the
 bootloader does not use any interrupts other than reset):

 bootloader’s linker script excerpt:
 MEMORY {
   …
   rom (rx) : ORIGIN = 0x4400, LENGTH = 0x1000 /* END=0x5400,
 size 4K - bootloader code */
   rom_app (rx) : ORIGIN = 0x5400, LENGTH = 0xab80 /* END=0xff80,
 size 43904 - the field-updatable application */
   vectors  : ORIGIN = 0xff80, LENGTH = 0x0080 /* END=0x1,
 size 128 as 64 2-byte segments */
   …
 }

 and the application’s linker script excerpt:

 MEMORY {
   …
   rom (rx) : ORIGIN = 0x5400, LENGTH = 0xab80 /* END=0xff80,
 size 43904 */
   vectors  : ORIGIN = 0xff80, LENGTH = 0x0080 /* END=0x1,
 size 128 as 64 2-byte segments */
   …
 }

 I need the bootloader’s init code and main() function be executed upon
 power up of the microcontroller. And this would be the case if I only
 flash the bootloader’s .elf onto the flash (0xFFFE pointing to
 bootloader’s main() function).

 But when I then program the application’s image onto the flash the
 0xFFFE will point to the application’s reset vector which is not a
 bootloader anymore. I'd like to configure my application so that it
 always fills 0xFFFE with a fixed address (0x4400).

 The rest of the story is that when bootloader is started then of
 course the bootloader needs to jump to and execute the application’s
 entry point (0x5400) including the app's watchdog preparation, stack
 init etc.

 Is that doable? How can I define in the application’s code that the
 reset vector (0xFFFE) shall contain the bootloader’s init code
 (0x4400)?

 Best Regards,
 Tomek

 --
 Learn Graph Databases - Download FREE O'Reilly Book
 Graph Databases is the definitive new guide to graph databases and their
 applications. Written by three acclaimed leaders in the field,
 this first edition is now available. Download your free book today!
 http://p.sf.net/sfu/NeoTech
 ___
 Mspgcc-users mailing list
 Mspgcc-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mspgcc-users

--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] Can the RESET_VECTOR be redefined at compile time to a specific value?

[Peter Bigot]

On Fri, Apr 18, 2014 at 1:34 PM, Tomek Lorek tlo...@gmail.com wrote:
 2014-04-18 19:40 GMT+02:00 Peter Bigot big...@acm.org:
 Thanks Peter!

 Yes, if you define a naked function named _reset_vector__ that's in
 section .init0 the mspgcc linker scripts will use it instead of the
 default one.

 You'd want to do something like:

 __attribute__((__naked__,__section__(.init0)))
 void _reset_vector (void)
 {
/* stuff goes here */
 }

 I;m not sure If I understand your hint correctly - the method above
 gives me the possibility of redefining the _reset_vector function
 body, but not the address.

Yes.  The address of the redefined function will be what's placed into
the vector table at the address where the MSP430 will load it on
power-up.  I'm really not clear on how you're trying to accomplish
your goal; you can try to rework the linker script if you want, but as
I understand your intent it won't work.

Looks like you've already discovered SYSRIVECT in SYSCTL, which could
be relevant too if you're working on an MCU that supports it.  At a
high level what you'd need to do is have your modified reset vector
determine whether it needs to do any reconfiguration, do so, then jump
to the reset vector of the selected application.  Accomplishing this
is left as an exercise for the developer and has little to do with
mspgcc, though others here may be able to provide additional help.

Peter


 I will try to rework the linker script or my application to something like 
 this:

 MEMORY
 {
 ...
 init0: ORIGIN = 0x4400, LENGTH = 0x2
 ...

 }

 SECTIONS
 {
   .init0
   {
 *(.init0)
   }  init0
 }

 and see if that works.

 Best Regards,
 Tomek

--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] Can the RESET_VECTOR be redefined at compile time to a specific value?

[Peter Bigot]

Re-reading your original post, I had focused on your last sentence,
which in context wasn't the right question.

You don't change anything in the boot loader.  You replace the
memory.ld script for applications with one that puts the .vectors
region somewhere other than 0xff80, and keeps the flash size and
offset from overlapping the bootloader.   The bootloader then copies
from the application .vectors into RAM.  No need to change the main
linker script at all, just provide a different memory.ld.

You could also look at TinyOS and Contiki which I believe have
solutions for this problem.

Peter

On Fri, Apr 18, 2014 at 3:02 PM, Peter Bigot big...@acm.org wrote:
 On Fri, Apr 18, 2014 at 1:34 PM, Tomek Lorek tlo...@gmail.com wrote:
 2014-04-18 19:40 GMT+02:00 Peter Bigot big...@acm.org:
 Thanks Peter!

 Yes, if you define a naked function named _reset_vector__ that's in
 section .init0 the mspgcc linker scripts will use it instead of the
 default one.

 You'd want to do something like:

 __attribute__((__naked__,__section__(.init0)))
 void _reset_vector (void)
 {
/* stuff goes here */
 }

 I;m not sure If I understand your hint correctly - the method above
 gives me the possibility of redefining the _reset_vector function
 body, but not the address.

 Yes.  The address of the redefined function will be what's placed into
 the vector table at the address where the MSP430 will load it on
 power-up.  I'm really not clear on how you're trying to accomplish
 your goal; you can try to rework the linker script if you want, but as
 I understand your intent it won't work.

 Looks like you've already discovered SYSRIVECT in SYSCTL, which could
 be relevant too if you're working on an MCU that supports it.  At a
 high level what you'd need to do is have your modified reset vector
 determine whether it needs to do any reconfiguration, do so, then jump
 to the reset vector of the selected application.  Accomplishing this
 is left as an exercise for the developer and has little to do with
 mspgcc, though others here may be able to provide additional help.

 Peter


 I will try to rework the linker script or my application to something like 
 this:

 MEMORY
 {
 ...
 init0: ORIGIN = 0x4400, LENGTH = 0x2
 ...

 }

 SECTIONS
 {
   .init0
   {
 *(.init0)
   }  init0
 }

 and see if that works.

 Best Regards,
 Tomek

--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] Minimum optimizations required to use inline functions

[Peter Bigot]

On Sat, Apr 12, 2014 at 8:43 PM, Wayne Uroda w.ur...@gmail.com wrote:
 Hi,

 I make extensive use of inline functions in my code, as below:

 extern inline void setClockLine(Bool value)
 { ... }

 Sometimes I put these definitions in .c files, sometimes in .h files (I'm
 not sure if that makes a difference, apart from scope).

It does.  See (for example): http://m68hc11.serveftp.org/inline-1.php

This explains your linker error, assuming you don't have a
non-extern/non-inline definition in a .c file.

I generally use static inline definitions placed in headers.  Since
-Os can affect whether a function is actually inlined, there's also
attribute __always_inline__ that can be added to encourage the
compiler more strongly (might even be an error if it can't be
inlined).

I haven't tried -Og to see if it does anything.

Peter

--
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test  Deployment 
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] Bug in MSP430-AS

[Peter Bigot]

Please clarify whether you are using msp430-as (from mspgcc) or
msp430-elf-as (from upstream binutils).  Several bugs like this were
fixed for mspgcc, but I don't believe RH picked up the fixes.  There's
discussion in the archive around February 2012 on this, and it's fully
documented on the mspgcc wiki but SourceForge isn't serving up those
pages right now.

Peter

On Mon, Mar 24, 2014 at 4:53 AM, Kees Schoenmakers ksli...@gmail.com wrote:
 Hello All,

 I have a project which is build with IAR in the past and contains a
 couple of assembly sources.
 When building it with the lastest binutils(msp430-as) I am struck with
 a bug in calculation of offsets. ALL versions of msp430-as, the latest
 included, generate faulty code here.

 I simplified one code sample to

 intern1:mov #1,r15
dec r14
jz  lab1
nop
jmp lab2

 intern2:dec r15
jnz intern2
ret

 lab1:   mov #2,r14
   callintern1
   callintern2
   ret

 lab2:   mov #3,r13
   ret
   .end

 When I assemble it with
 msp430-as -c bug430as.S

 the resulting code shows weird offsets for the 'jumps' (jmp, jz jnz),
 even the calls...

 What is happening here?  In the final linked binary with a lot of .c
 and .S files the offsets are also wrong in the same way.
 Another project, solely of .c files runs well

 Kees

 --
 Learn Graph Databases - Download FREE O'Reilly Book
 Graph Databases is the definitive new guide to graph databases and their
 applications. Written by three acclaimed leaders in the field,
 this first edition is now available. Download your free book today!
 http://p.sf.net/sfu/13534_NeoTech
 ___
 Mspgcc-users mailing list
 Mspgcc-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mspgcc-users


--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] msp430-elf size optimizations - some notes and a patch

[Peter Bigot]

On Thu, Mar 6, 2014 at 6:05 AM, David Brown da...@westcontrol.com wrote:
 Will the __intN stuff ever make it into mainline?  The msp430 port may
 be the only chip that needs __int20, but there are other chips that
 could benefit from different integer sizes - perhaps __int24 on the
 8-bit AVR, or __int40 on some devices with DSP-style accumulators.

I'd hope that it's done in a way that allows that, though I haven't
looked at what DJ did.  Speaking as somebody who did all this in gcc
almost two years ago, part of what's needed was already there, but it
had some bugs (which I reported, and one of which Nick later
rediscovered in the RH port).  There are a lot of other issues for
full msp430 20-bit support too (mostly to do with address/non-address
value differences), many of which were solved in mspgcc.

Hopefully the new clean-room implementation, done by folks who know
more about gcc, will address the flaws in mspgcc's approach and be
acceptable upstream.

Peter

--
Subversion Kills Productivity. Get off Subversion  Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works. 
Faster operations. Version large binaries.  Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] msp430-elf size optimizations - some notes and a patch

[Peter Bigot]

Is it the intent to fully support C++ in this port, inclusive of
static initializers and exceptions?   (Exclusive of features that
require host support like threads, though it'd be good if chrono
could be used with various MSP430 clocks providing the underlying
timers.)

Proper support for C++11 in msp430-elf-gcc sometime soon would be one
of the things that will slow my move to ARM-based microcontrollers.  I
can respect flags that disable its support; I don't want to have to
add flags to put support back, or find language-mandated features do
not work.  (The move to ARM is inevitable, though; MSP430 just doesn't
stack up so well anymore, even for ultra-low-power applications).

Peter

On Thu, Mar 6, 2014 at 12:07 PM, DJ Delorie d...@redhat.com wrote:

 Er, that reminds me, I missed some stuff in the doc about removing
 Java support... sigh.

 I added this:


 Lastly, there's a GCC option -minrt that tells gcc to use a minimum
 runtime for programs that do not need static initializers or
 constructors (popular in C++ and Java). Note that this is different
 than initialized data (like int j = 5;), this is for functions that
 need to be called before main() is. You can also forcibly remove the
 extra language support in your linker script by discarding anything
 from crtbegin/crtend:

   /DISCARD/ : { *crtbegin*.o(*) *crtend*.o(*) }

 Don't forget to take out the KEEP's for crtbegin/end too, though ;-)


 --
 Subversion Kills Productivity. Get off Subversion  Make the Move to Perforce.
 With Perforce, you get hassle-free workflows. Merge that actually works.
 Faster operations. Version large binaries.  Built-in WAN optimization and the
 freedom to use Git, Perforce or both. Make the move to Perforce.
 http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk
 ___
 Mspgcc-users mailing list
 Mspgcc-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mspgcc-users

--
Subversion Kills Productivity. Get off Subversion  Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works. 
Faster operations. Version large binaries.  Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] msp430-elf size optimizations - some notes and a patch

[Peter Bigot]

On Thu, Mar 6, 2014 at 12:47 PM, DJ Delorie d...@redhat.com wrote:
 If you have enough flash/ram, yes.  We fully test C++ in our
 simulators, so if gcc/newlib support it in general, it should work for
 msp430 also.

Great.  I'll try that out once it looks like all the TI patches are
applied to the 4.9 development branch.

 (Exclusive of features that require host support like threads,
 though it'd be good if chrono could be used with various MSP430
 clocks providing the underlying timers.)

 Well, if you want *peripheral* support in the runtime libraries,
 that's a different story ;-)

No, I (very much) don't want gcc or newlib to do the peripheral
interface.  I am hopeful, though, that I can use the standard
templates by providing my own underlying implementation for (for
example) std::system_clock and std::high_resolution_clock.  Haven't
looked into the details yet, though.

Peter

--
Subversion Kills Productivity. Get off Subversion  Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works. 
Faster operations. Version large binaries.  Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] RFC: ATTENTION ALL PORTS/PACKAGES MAINTAINERS!

[Peter Bigot]

Most mspgcc package names pre-date the conception of RH's implementation by
some number of years.  I agree issuing new packages with a different
toolchain under the same name would be unwise.

A clean distinction is that mspgcc traditionally used msp430-cmd while
msp430 gcc uniformly uses msp430-elf-cmd for all toolchain commands.  If
that distinction were reflected in the package names, it might be very
simple to have parallel installations.

Peter



On Wed, Jan 29, 2014 at 9:15 AM, Peter Johansson rockets4k...@gmail.comwrote:

 Apologies for shouting in the subject, but I believe this is critical
 issue for all ports/packages maintainers.

 I implore you to read Peter Bigot's post of September 23, 2013
 regarding the naming of GCC releases for the MSP430, the summary of
 which follows:

  To help reduce confusion, though, I propose the following nomenclature:
 
  * mspgcc refers specifically to the toolchain started by Dmitry Diky and
  Chris Liechti and finished by me;
 
  * gcc refers generically to the upstream toolchain GNU C;
 
  * msp430 gcc (or gcc msp430) would refer to the new port of msp430 to the
  upstream toolchain.

 The number of different versions of GCC for the MSP430 in the past has
 caused no end of confusion, and Red Hat's new version is likely to
 continue this trend unless appropriate measures are taken, and taken
 soon.  (It could be argued that this confusion is already
 happening...)

 While it seems clear that Red Hat's version will be the long term
 future for GCC for the MSP430, there are many people (myself included)
 who will be sticking with Peter's version until such time as Red Hat's
 version has been formally released and thoroughly tested.  However,
 Red Hat's version will only see broad use (and testing) if it is also
 included in packaged formats.

 As such, I strongly suggest that all package maintainers include
 *both* versions for the foreseeable future.  Unfortunately, it appears
 that many distributions already have package names that contradict
 Peter's proposed naming scheme.

 It is my hope that this thread can be used to sort out this mess and
 provide for some package naming standards going forward.

 Please discuss.

 -p.


 --
 WatchGuard Dimension instantly turns raw network data into actionable
 security intelligence. It gives you real-time visual feedback on key
 security issues and trends.  Skip the complicated setup - simply import
 a virtual appliance and go from zero to informed in seconds.

 http://pubads.g.doubleclick.net/gampad/clk?id=123612991iu=/4140/ostg.clktrk
 ___
 Mspgcc-users mailing list
 Mspgcc-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mspgcc-users

--
WatchGuard Dimension instantly turns raw network data into actionable 
security intelligence. It gives you real-time visual feedback on key
security issues and trends.  Skip the complicated setup - simply import
a virtual appliance and go from zero to informed in seconds.
http://pubads.g.doubleclick.net/gampad/clk?id=123612991iu=/4140/ostg.clktrk___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] Miscompiled crtbegin in large model?

[Peter Bigot]

This looks an awful lot like
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52856 (at least from the
familiar diff).

Peter


On Mon, Dec 30, 2013 at 7:07 AM, nick clifton ni...@redhat.com wrote:

 Hi Lorenzo,
  Anyway I opened a bug on the gcc report system; I even devised a two
  liner which reproduces the issue, so at least they can look at it
  easily.

 For which I thank you very much... :-)

 I have a patch which fixes the problem - at least for the test case you
 supplied.  I am running it through some local regressions tests before
 submitting it to the FSF, but if you fancy having a go yourself, here it
 is:

 Index: stor-layout.c
 ===
 --- stor-layout.c   (revision 206241)
 +++ stor-layout.c   (working copy)
 @@ -2816,7 +2816,8 @@
   enum machine_mode target_mode,
   rtx *mmin, rtx *mmax)
   {
 -  unsigned size = GET_MODE_BITSIZE (mode);
 +  /* PR 59613: Use the precision of the mode, not its bitsize.  */
 +  unsigned size = GET_MODE_PRECISION (mode);
 unsigned HOST_WIDE_INT min_val, max_val;

 gcc_assert (size = HOST_BITS_PER_WIDE_INT);

 In my defense I should point out that this is a bug in generic gcc code
 and not the MSP430 backend.  Of course I also should have picked up this
 problem a long time ago rather than letting it get out into the wilds.
 Ho Hum.

 Cheers
Nick Clifton

 PS.
For anyone following this thread who wants to see the GCC bug report,
 it can be found here:

 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59613


 --
 Rapidly troubleshoot problems before they affect your business. Most IT
 organizations don't have a clear picture of how application performance
 affects their revenue. With AppDynamics, you get 100% visibility into your
 Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics
 Pro!
 http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
 ___
 Mspgcc-users mailing list
 Mspgcc-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mspgcc-users

--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] Miscompiled crtbegin in large model?

[Peter Bigot]

Unlike your previous question, this is purely an msp430-elf-gcc issue so
isn't something I would normally respond to.  Both TI and RH have people
monitoring this list, and I expect them to reply on-list with advice,
though perhaps not until the holidays are over.

Since I'm here, though, I expect that issues with a pure upstream build
should be raised on the official gcc or binutils mailing lists.  I
recommend first trying it with the pre-built toolchains available from TI,
as there may be changes that have not yet been integrated upstream.

Peter


On Fri, Dec 27, 2013 at 8:05 AM, Lorenzo Marcantonio 
l.marcanto...@logossrl.com wrote:

 Got the 'blinking led' working on the 5529... tried to test the thing
 with the large model (-mlarge to every msp430-elf-gcc invocation).

 Well, nothing happened. It hangs before main. Exactly in frame_dummy, from
 crtbegin.o (built from the mess in libgcc/crtstuff.c). I dumped the files
 from
 the compiler build (found in lib/gcc/msp430-elf/4.9.0/430x/large) so it
 shouldn't be something from my test program...

 The source code has this fragment:

   if (__register_frame_info)
 __register_frame_info (__EH_FRAME_BEGIN__, object);

 In small model the object code is like this:

 009e frame_dummy:
   9e:   3e 40 00 00 mov #0, r14 ;
 a0: R_MSP430_16_BYTE__register_frame_info
   a2:   0e 93   cmp #0, r14 ;r3 As==00
   a4:   00 24   jz  $+2 ;abs 0xa6
 a4: R_MSP430_10_PCREL   .L32
   a6:   3c 40 00 00 mov #0, r12 ;
 a8: R_MSP430_16_BYTE.eh_frame
   aa:   3d 40 00 00 mov #0, r13 ;
 ac: R_MSP430_16_BYTE.bss+0x4
   ae:   8e 12   callr14 ;

 00b0 .L32:

 __register_frame_info is a weak external, which is undefined, so the linker
 'locates' it to 0. The result is

 4524 frame_dummy:
 4524:   3e 40 00 00 mov #0, r14 ;  HERE IS
 LOCATED
 4528:   0e 93   cmp #0, r14 ;r3 As==00
 452a:   05 24   jz  $+12;abs 0x4536
 452c:   3c 40 04 44 mov #17412, r12 ;#0x4404
 4530:   3d 40 82 24 mov #9346,  r13 ;#0x2482
 4534:   8e 12   callr14 ;

 4536 .L32:

 Here zero is obviously zero, so the call is skipped (as intended:D)

 When linking the large model crtbegin.o, the generated code is really
 different:

 015e frame_dummy:
  15e:   8c 00 00 00 mova#0, r12 ;
 15e: R_MSP430X_ABS20_ADR_SRC.eh_frame
  162:   8d 00 00 00 mova#0, r13 ;
 162: R_MSP430X_ABS20_ADR_SRC.bss+0x6
  166:   b0 13 00 00 calla   #0  ;0x0
 166: R_MSP430X_ABS20_ADR_DST
  __register_frame_info

 Where is the condition check? Obviously after location the result is this:

 45fe frame_dummy:
 45fe:   8c 00 08 44 mova#17416, r12 ;0x04408
 4602:   8d 00 f2 24 mova#9458,  r13 ;0x024f2
 4606:   b0 13 00 00 calla   #0  ;0x0  HERE
 IS LOCATED

 That calla #0 doesn't seem very legal to me...

 So... is this expected, it's a known bug or needs to be reported? (and
 where) I
 know that 20-bit support is beta (I built it from trunk...) so I'm not
 worrying
 too much.

 Suggestions appreciated

 --
 Lorenzo Marcantonio
 Logos Srl


 --
 Rapidly troubleshoot problems before they affect your business. Most IT
 organizations don't have a clear picture of how application performance
 affects their revenue. With AppDynamics, you get 100% visibility into your
 Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics
 Pro!
 http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
 ___
 Mspgcc-users mailing list
 Mspgcc-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mspgcc-users

--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] Linker script for new gcc?

[Peter Bigot]

msp430mcu only works with mspgcc, not with RH gcc (msp430-elf).  File
names, installation path, and other characteristics are not compatible with
the new toolchain.

You need the GCC_RH_20131206.zip from the Get Software link at:
http://www.ti.com/tool/msp430-gcc-opensource

Peter



On Thu, Dec 26, 2013 at 6:35 AM, Lorenzo Marcantonio 
l.marcanto...@logossrl.com wrote:

 I'm trying to build the 'new' toolchain, following the instruction here:

 http://sourceforge.net/apps/mediawiki/mspgcc/index.php?title=Install:redhat

 I'll need to use one of the big MSP (the 20 bit parts), so AFAIK that's
 the road to follow. I think is called the uniarch compiler, am I right?

 Done the binutils (got the 2.24.51.20131021 version from the repo), gcc
 (4.9.0 experimental) and newlib. mspdebug is working too (getting the
 FET working was another epic story, anyway). No gdb for the moment, I'm
 not yet there. Also picked the latest msp430mcu package (20130321),
 seems to be aligned with GIT.

 Now for testing the thing: newlib built so the compiler is working (it
 made a large version, too). Tried to make the MSP-EXP430G2-LaunchPad
 firmware which is a) small and b) theorically already ported to mspgcc.

 Issues found:
 - The 'autoinclude' needed an #include msp430.h to work, actually. In
   fact to make #include work I had to rebuild everything with the
   sysroot feature enable (pointing to /usr/local/msp430-elf)o
 - The interrupt macros had to be replaced with the
   __attribute__((interrupt()))_ equivalent stuff

 Now the compiler works and I got the launchpad.o file (which is already
 a good result). However the link pass bomb out saying:

 cannot open linker script file msp430g2553/memory.ld: No such file or
 directory

 AFAIK that's requested (as documented in
 http://gcc.gnu.org/onlinedocs/gcc/MSP430-Options.html) by a spec entry
 in msp430.h (in the gcc sources); I think the relevant fragment is this:

 %{!T*:%{!msim:%{mmcu=*:--script=%*/memory.ld %--script=%*/peripherals.ld}}}

 I think the idea is 'when not targeting the simulator add these two
 linker scripts to the link stage'. Fine for me HOWEVER msp430mcu doesn't
 provide memory.ld and peripherals.ld ... it gives memory.x and periph.h!
 Are these the same thing? is msp430mcu in need of an update for this new
 gcc feature?

 I tried giving it the obviously renamed files but it obviously don't
 work... I feel the x files are only fragments of the needed stuff (for
 comparison I looked into the msp430.ld from binutils), like section
 declaration and architecture and other things I have no idea of:P

 In short it says:
 - launchpad.elf section `.text' will not fit in region `ram'
 - crt0.S:23: undefined reference to `__stack (and other vital stuff)
 - undefined reference to `__bis_status_register' (isn't that a builtin?
   or must it be replaced with BIS_SR?)

 The link command is

 msp430-elf-gcc -mmcu=msp430g2553 -o launchpad.elf launchpad.o

 stracing shows that ld is called in this way (resolved the pathnames
 and indented the thing )

 /usr/local/libexec/gcc/msp430-elf/4.9.0/ld
 --sysroot=/usr/local/msp430-elf
 -o launchpad.elf
 /usr/local/msp430-elf/lib/crt0.o
 /usr/local/lib/gcc/msp430-elf/4.9.0/crtbegin.o
 -L/usr/local/lib/gcc/msp430-elf/4.9.0
 -L/usr/local/lib/gcc
 -L/usr/local/msp430-elf/lib
 -L/usr/local/msp430-elf/lib
 launchpad.o
 -lgcc
 --start-group
 -lc
 -lgcc
 -lnosys
 --end-group
 --script=msp430g2553/memory.ld
 --script=msp430g2553/peripherals.ld
 -lgcc
 /usr/local/lib/gcc/msp430-elf/4.9.0/crtend.o
 /usr/local/msp430-elf/lib/crtn.o
 -lgcc

 No idea about the group thing, but it really wants to be sure to include
 libgcc, it seems:P

 Any suggestion on how to make it work? Hopefully an updated msp430mcu?
 The alternative would be a manual merge (msp430 seems to provide the
 missing vital declarations) which would be a) painful and b) really
 unelegant.
 Or manual link (maybe even worse)

 Thanks in advance

 --
 Lorenzo Marcantonio
 Logos Srl


 --
 Rapidly troubleshoot problems before they affect your business. Most IT
 organizations don't have a clear picture of how application performance
 affects their revenue. With AppDynamics, you get 100% visibility into your
 Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics
 Pro!
 http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
 ___
 Mspgcc-users mailing list
 Mspgcc-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mspgcc-users

--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 

Re: [Mspgcc-users] Any insight on what targets _endless_loop__ in libcrt0

[Peter Bigot]

__endless_loop__ is placed in section .fini0 (the last of the nine reserved
finalization sections).  One way it can be reached in a normal application
is falling off the end of main().  It is what follows any other
finalization routines, including __stop_progExec__, which is normally empty
and appears in section .fini9.  __stop_progExec__ is jumped to by exit(3c)
if the macro definition of exit() from stdlib.h in msp430-libc is invoked.

So: Returning from main(), invoking exit(3c), or other magic that causes
code to jump into the finalization sections.

Peter


On Fri, Dec 20, 2013 at 6:31 PM, Andrew McLaren and...@aratika.co.nzwrote:

 Hi all,

 I've got a situation where some logic (running on a 439 MSP430) ends up in
 _endless_loop__ which is part of libcrt0. This can happen after the logic
 has been happily running some intensive test logic for hours, and I'm
 trying
 to ascertain how it could end up there. The debugger is not giving me a lot
 of help (specifically no traceback of how it got here).

 There is always a possibility that some memory corruption of mine has let
 the logic go awol, and by its nature if it hits this logic it will be
 trapped here. What I suspect is more likely is that _endless_loop__ is the
 deliberate target of an unrecoverable error in one of the C functions
 (which
 itself is no doubt triggered by something I have done!).

 Can someone who understands the msp C runtime support give me any insights
 into the intent behind _endless_loop__, and in what situations it could be
 invoked. If I understand this better it may give me some clues where to
 look.

 Thanks, regards, and a great Christmas to all.

 Andrew


 --
 Rapidly troubleshoot problems before they affect your business. Most IT
 organizations don't have a clear picture of how application performance
 affects their revenue. With AppDynamics, you get 100% visibility into your
 Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics
 Pro!
 http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
 ___
 Mspgcc-users mailing list
 Mspgcc-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mspgcc-users


--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] Writing an ISR in pure assembly

[Peter Bigot]

See https://github.com/pabigot/freertos-mspgcc for FreeRTOS using MSPGCC as
of mid 2012.  The use of naked is in Source/portable/GCC/MSP430, but does
not apply to the timer ISR itself.  It was not necessary to use external
assembly sources.

http://pabigot.github.io/bsp430/freertos_8h.html may also be useful.

As I recall I did have FreeRTOS working under BSP430 and so supporting all
MCUs in the product line.  The freertos-bsp430 repository was intended to
supersede freertos-mspgcc; at this point there is no public difference,
though I seem to have some pending updates in my local workspace.  None of
that is actively supported but it could be if people find it useful.

Peter

On Tue, Dec 10, 2013 at 9:48 PM, Wayne Uroda w.ur...@gmail.com wrote:

 Hello,

 I am trying to port FreeRTOS to the MSP430F5519.

 In order to write the context switching part, I need to write a timer
 interrupt service routine in pure assembly (the compiler right now is doing
 some extra push before I can do anything in the ISR, even with nothing in
 the body...)

 How can I place a function (defined in an assembly file) into the vector
 table?

 Thanks,

 - Wayne


 --
 Rapidly troubleshoot problems before they affect your business. Most IT
 organizations don't have a clear picture of how application performance
 affects their revenue. With AppDynamics, you get 100% visibility into your
 Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics
 Pro!
 http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
 ___
 Mspgcc-users mailing list
 Mspgcc-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mspgcc-users


--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] Writing an ISR in pure assembly

[Peter Bigot]

Yes, the interrupt attribute causes the function to be named __isr_X where
X is the word offset of the interrupt from the vector table start (viz.,
the value of the attribute's parameter divided by two).  Those symbols are
used to initialize the vector table in crt0ivtbl.o.

Thus, if you're using the MSP430F5438A where USCI_A1_VECTOR is 0x5C
(decimal 92), the corresponding interrupt vector to be installed will be
__isr_46.

Due to design decisions in the distant past there's no way to use the
constants from the MCU header to automatically create the corresponding
interrupt name in an assembly file.  But you can easily use -S on a C
source file that contains an interrupt routine to see what the assembly
source needs to look like.

Peter



On Wed, Dec 11, 2013 at 4:03 PM, Wayne Uroda w.ur...@gmail.com wrote:

 Even though I think it is sorted now, I still wonder (for my own knowledge
 and completeness) if there is a way to either override just one of the
 vector positions (or is there a magic name that given to the function
 accomplishes the same thing) or is there a way to override all of the
 vector table?

 I did it with the aid of nostartfiles many years ago (had need to write my
 own boot loader anyway) but I wonder if there is a way to do it without
 losing the startup routines.

 - Wayne



 On 11/12/2013, at 22:23, Peter Bigot big...@acm.org wrote:

 See https://github.com/pabigot/freertos-mspgcc for FreeRTOS using MSPGCC
 as of mid 2012.  The use of naked is in Source/portable/GCC/MSP430, but
 does not apply to the timer ISR itself.  It was not necessary to use
 external assembly sources.

 http://pabigot.github.io/bsp430/freertos_8h.html may also be useful.

 As I recall I did have FreeRTOS working under BSP430 and so supporting all
 MCUs in the product line.  The freertos-bsp430 repository was intended to
 supersede freertos-mspgcc; at this point there is no public difference,
 though I seem to have some pending updates in my local workspace.  None of
 that is actively supported but it could be if people find it useful.

 Peter

 On Tue, Dec 10, 2013 at 9:48 PM, Wayne Uroda w.ur...@gmail.com wrote:

 Hello,

 I am trying to port FreeRTOS to the MSP430F5519.

 In order to write the context switching part, I need to write a timer
 interrupt service routine in pure assembly (the compiler right now is
 doing
 some extra push before I can do anything in the ISR, even with nothing in
 the body...)

 How can I place a function (defined in an assembly file) into the vector
 table?

 Thanks,

 - Wayne


 --
 Rapidly troubleshoot problems before they affect your business. Most IT
 organizations don't have a clear picture of how application performance
 affects their revenue. With AppDynamics, you get 100% visibility into your
 Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics
 Pro!

 http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
 ___
 Mspgcc-users mailing list
 Mspgcc-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mspgcc-users



--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] MSPDebug unable to find 0451:f430

[Peter Bigot]

From my experience the V3 tilib interface is significantly faster than the
V2 uif interface for programming (maybe as much as 10x faster).  It's my
preferred version now.

If you do a firmware update and it appears to brick the UIF, see
http://forum.43oh.com/topic/4349-new-msp430f5529-usb-launchpad-released/?p=40492

Peter


On Sun, Nov 24, 2013 at 8:04 PM, Daniel Beer dlb...@gmail.com wrote:

 On Sun, Nov 24, 2013 at 05:54:31PM -0800, Eric Decker wrote:
  is it possible to use the
  ver 3 firmware with Linux dev boxes

 Hi Eric,

 Yes, it does compile on Linux, but requires patching. Patches for
 versions 460f and 460g are available here:

 http://mspdebug.sourceforge.net/tilib.html

 Cheers,
 Daniel

 --
 Daniel Beer dlb...@gmail.comwww.dlbeer.co.nz
 IRC: inittab (Freenode)PGP key: 2048D/160A553B


 --
 Shape the Mobile Experience: Free Subscription
 Software experts and developers: Be at the forefront of tech innovation.
 Intel(R) Software Adrenaline delivers strategic insight and game-changing
 conversations that shape the rapidly evolving mobile landscape. Sign up
 now.
 http://pubads.g.doubleclick.net/gampad/clk?id=63431311iu=/4140/ostg.clktrk
 ___
 Mspgcc-users mailing list
 Mspgcc-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mspgcc-users

--
Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing 
conversations that shape the rapidly evolving mobile landscape. Sign up now. 
http://pubads.g.doubleclick.net/gampad/clk?id=63431311iu=/4140/ostg.clktrk___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] GCC MSP430

[Peter Bigot]

To correct the mistaken description how mspgcc's library works without
getting into details you don't want to know:

mspgcc does not have one variant per chip, but the libraries do have
variants across the axes that affect code generation: three meaningful CPU
architectures (two used for libraries), hardware multiplier support (five
variants, but only two affect libraries), and memory model which supports
four binary options (7 variants are built, but six only apply to CPUX).

Comes down to 16 total variants, supporting 434 distinct MCUs.  Doesn't
take too long to build or too much space since msp430-libc isn't as large
as newlib.

Peter

On Mon, Sep 23, 2013 at 12:27 PM, DJ Delorie d...@redhat.com wrote:


 There are three multilibs that are built:

 430 - the default so it doesn't have a subdir - is for all non-430X
 processors.

 430x - for 430X series processors, but still using 16-bit pointers.

 430x/large - for 430X series processors using 20-bit pointers.


 For each of those, newlib is built using a common subset so it works
 for any (I hope) processor in that category.

 GCC (msp430-elf-gcc, not mspgcc) has two options it looks at:

   -mmcu=whatever - if whatever has 430x or 430X in it, you get
the 430x family.  Default is the 430 family.

   -mlarge - enables 20-bit pointers.

 IIRC there's also -mcpu= which specifies the family (430/430x)
 directly, for when the MCU name doesn't match the pattern.


 Also, keep in mind that newlib is not targetted specifically to the
 430's needs.  It's a generic runtime library so tends to be more one
 size fits all than one variant per chip like mspgcc's library.


 --
 October Webinars: Code for Performance
 Free Intel webinars can help you accelerate application performance.
 Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
 from
 the latest Intel processors and coprocessors. See abstracts and register 
 http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk
 ___
 Mspgcc-users mailing list
 Mspgcc-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mspgcc-users

--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] msp430-gdbproxy loses connection with target

[Peter Bigot]

Yeah, this is pretty far from mspgcc, but still on topic for MSP430.

There are three timer read solutions I use in BSP430, depending on the
relative speed of the clocks:

* If the clock source is synchronous to mclk, just read the counter.

* If it's asynchronous and is significantly slower, read the counter
repeatedly until two consecutive values are equal.

* If it's asynchronous and is about the same speed or faster than MCLK
dedicate a capture/compare register configured to capture both edges and
keep CCIS1 set, then toggle CCIS0 in the CCTL register to latch the counter
value.

There's an amusing little gotcha in that last one: if the timer clock is
slower than MCLK and you have SCS set, the captured count might not be
correct (SCS delays the capture until the next falling edge of the timer
clock).

Take into account that sometimes you need to also record the CCTL value and
know that it's consistent with the CCR value you select.   For example,
when trying to produce a 32-bit counter value you need to know whether an
overflow has been recorded.  My belief in the case of the
two-consecutive-reads-that-match solution is that the CCTL value between
the two reads will be correct; unfortunately the MSP430 user's guides don't
give enough detail on exactly how the clock updates are done to guarantee
that.

And be careful about reading CCR from within an interrupt handler triggered
by CCIFG, because if you use the IV interface the value you read might not
be the one that triggered the interrupt (clearing CCIFG enables an
overwrite of the captured value that would otherwise be signalled by the
COV bit).

http://pabigot.github.io/bsp430/timer_8h.html#h_periph_timer_hpl has some
additional details.  examples/platform/trxeb/timer_scs_test/main.c and
examples/misc/syncap/main.c both demonstrate some of the edge cases of
timer capture.



On Thu, Sep 19, 2013 at 3:08 PM, William Swanson swanson...@gmail.comwrote:

 On Thu, Sep 19, 2013 at 12:44 PM, Jesse Frey jmf...@alaska.edu wrote:
  When I need to read a timer asynchronously do three consecutive reads
 and do
  a bitwize majority function on them.

 Not to take this thread too far off-topic, but that approach doesn't
 work. For example, say your middle reading happens to catch the timer
 just as it is rolling over from 0x to 0x. Your three readings
 would then be:

 0x
 0xff00 /* meta-stable transition state */
 0x

 Your bit-wise majority function would return 0xff00, which is still
 wrong. Since the whole point of taking multiple readings is to avoid
 these meta-stable transition states, a bit-wise majority isn't good
 enough. You need to compare whole values until you see two that match.

 -William


 --
 LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
 1,500+ hours of tutorials including VisualStudio 2012, Windows 8,
 SharePoint
 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack
 includes
 Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13.
 http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk
 ___
 Mspgcc-users mailing list
 Mspgcc-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mspgcc-users

--
LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint
2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes
Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. 
http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] msp430-gdbproxy loses connection with target

[Peter Bigot]

MSP430FG4618 erratum TB18: MOV to TBCTL may clear TBR.

http://www.ti.com/lit/er/slaz368c/slaz368c.pdf page 9.

Peter


On Tue, Sep 17, 2013 at 11:09 PM, Andrew McLaren and...@aratika.co.nzwrote:

 Just to close the loop on this, I think I have found the problem (or at
 least what the 439 MSP doesn't like).

 The logic maintains a reference timebase using the timer B module (this
 simply ticks away in the background and maintains a reference counter). To
 obtain a time reference at any time, the logic stops the timer block, reads
 the TBR, and restarts the timer block. Nothing really fancy there.

 It was a bit of luck, but the only other relatively large MSP I had
 available was the 4618 on an experimenters board. This also has a USART, so
 there were only minimal code changes needed between the 439 and the 4618
 (the 4618 is a USART1 rather than a USART0, and that was pretty much it).
 However, the 4618 timer logic failed - when the timer was restarted, the
 TBR
 was cleared, whereas the 439 restarted (as expected) from where the TBR was
 stopped. This lead me to have a good look at how the timer block was
 stopped
 and restarted.

 To stop and restart the timer, the whole TBCTL was being rewritten, along
 the lines of;
 TBCTL = TBSSEL_1 | ID_3 | MC_0, and
 TBCTL = TBSSEL_1 | ID_3 | MC_2

 This worked fine on the 439 (or at least appeared to work fine!). However
 stopping the timer block this way appeared to clear the TBR on the 4618,
 even though the TBCLR bit wasn't being set. To get this to work correctly
 on
 the 4618, I modified this to just touch the mode control bits, along the
 lines of;
 TBCTL = TBCTL  ~MC0  ~MC1
 TBCTL = (TBCTL  ~MC0) | MC1

 This resolved the timer issues with the 4618, which now ran the logic with
 no problems. Moreover, the logic functioned without any of the loss of
 connectivity with the JTAG seen with the 439. Just out of curiousity, I
 rebuilt the logic for the 439 and ran that again, and it also worked 100%.
 I
 could turn the JTAG connectivity issues on and off simply by how I was
 touching the TBCTL register.

 A bit more playing and looking at the full TBCTL before I modify it, the
 only difference between two two is that in the first case TBIFG is being
 cleared, whereas in the modified case this is being left at its set state.
 As I'm not using TBIE or TBIFG, this doesn't affect me at all. While the
 second TBCTL strategy is explicitly only touching what is required, so is
 probably better, I can't see why the initial strategy should have caused
 any
 issues (and also why it should have cleared the TBR on 4618, but luckily it
 did!).

 Its curiousity value now, but if anyone can give me any insights into why
 this has happened, I'd like to know! Thanks for the help and pointers in
 resolving this.

 Andrew

 -Original Message-
 From: Eric Decker [mailto:cire...@gmail.com]
 Sent: Tuesday, 3 September 2013 10:57 a.m.
 To: and...@aratika.co.nz
 Cc: Daniel Beer; GCC for MSP430 - http://mspgcc.sf.net
 Subject: Re: [Mspgcc-users] msp430-gdbproxy loses connection with target


 have you verified that the board is getting the voltage that you think it
 should be?


 On Mon, Sep 2, 2013 at 3:38 PM, Andrew McLaren and...@aratika.co.nz
 wrote:


 
  On Tue, Aug 27, 2013 at 10:40:45AM +1200, Andrew McLaren wrote:
   It would have been easy if the problem had been gdbproxy,
  but no such
   luck. Now that mspdebug is running, I'm seeing exactly the same
   scenario here. The messages are a tad different, but I
  think they are
   saying the same thing. Everything works fine until mspdebug
  reports...
  
   fet: FET returned error code 18 (Could not determine device state)
   fet: polling failed
  
   Once again, eveything appears hung outboard of mspdebug until the
   target msp is repowered. If I simply try and restart
  mspdebug without
   doing this, it will report;
  
   TI3410 device is in boot config, setting active
   ti3410: TI_OPEN_PORT failed: A device attached to the system is not
   functioning
   ti3410: failed to set up port
 
  This looks like some kind of hardware problem. Have you tried
  different USB ports?
 
  Is the board powered externally, or does it draw power from the FET?
 
  Cheers,
  Daniel
 

 I've been having a bit of a play to try and isolate it, but haven't come up
 with anything conclusive (or really anthing at all).

 To answer your questions
 - the target board is powered by the FET
 - I've tried switching USB ports, but no change.

 I've also tried switching the target processor (another 439), but also no
 change. The only harware I haven't yet swapped out is the FET itself, but
 only have the single TI FET running. I do have an Olimex FET here, but
 having a few issues at present installing the drivers for that, so that is
 the next step.

 The ONLY thing I have found so far that resets the problem is repowering
 the
 target MSP, which leads me to think that is must be some context in that
 that is somehow being corrupted. I'd also 

Re: [Mspgcc-users] Unofficial Red Hat Port

[Peter Bigot]

msp430mcu in its current form will almost certainly not work with the new
compiler, unless somebody's forked it without telling me.  The headers get
mspgcc-specific material added, and the linker scripts are for the mspgcc
version of gdb.

It would make sense to have msp430mcu be the mechanism providing these
tools for gcc as well as mspgcc, since it's the obvious name for its
function.  Nobody's talked to me about that, though, so I assume TI's gone
a different route.

Peter


On Mon, Sep 16, 2013 at 11:52 AM, Thomas Taranowski t...@baringforge.comwrote:

 What's the current word on the msp430 variant header files and
 corresponding linker scripts?  Is there a plan to release those soon?  If
 not, has anyone testing been done of the compiler against Peter's linker
 scripts and header files?

 Thomas Taranowski | 425-442-9209 | skype: thomas.taranowski |
 baringforge.com



 On Sat, Sep 14, 2013 at 5:42 PM, DJ Delorie d...@redhat.com wrote:

 
   Correct me if I'm wrong here, but this only applies when the
   initialisation involves a constructor function rather than just
   assignment of a fixed value.
 
  Correct.
 
   are all run before main() is called.  These might add extra code space
   because the constructor calls can't be fully inlined here, but it
 should
   not be much.
 
  There is some startup code to go through the list of such functions,
  and call them all, too.  It's not much, but if every byte counts...
 


 --
 LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
 1,500+ hours of tutorials including VisualStudio 2012, Windows 8,
 SharePoint
 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack
 includes
 Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13.
 http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk
 ___
 Mspgcc-users mailing list
 Mspgcc-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mspgcc-users


--
LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint
2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes
Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. 
http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] Auto-Re: Mspgcc-users Digest, Vol 88, Issue 6

[Peter Bigot]

Just a reminder: if your mailer configuration generates spam to the list
eventually I'll notice and unsubscribe you.  Acknowledging receipt of a
digest, even if you do it in Chinese, is spam.

If you resubscribe and it does it again and I notice, you won't be allowed
to resubscribe any more.

Peter (often oblivious, but sometimes awake and in possession of a Babel
fish)


On Mon, Sep 16, 2013 at 12:15 PM, 徐维亚 1012002...@dqxy.ntu.edu.cn wrote:

 你的邮件已接受，谢谢！！

 --
 LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
 1,500+ hours of tutorials including VisualStudio 2012, Windows 8,
 SharePoint
 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack
 includes
 Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13.
 http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk
 ___
 Mspgcc-users mailing list
 Mspgcc-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mspgcc-users

--
LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint
2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes
Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. 
http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] Inconsistent d16/d20 attributes

[Peter Bigot]

C++ has never been officially supported by mspgcc, and this appears to
require a change to the compiler rather than simple header modification:
C++ apparently does something unexpected with attribute merges.

I've confirmed the behavior.  Please enter this as a bug at
https://sourceforge.net/p/mspgcc/bugs/.  If there is another mspgcc release
I'll may be able to fix it then.

Peter


On Mon, Sep 9, 2013 at 2:45 PM, Andrew Wygle awy...@berkeley.edu wrote:

 After further investigation, I discovered that this code is actually being
 compiled as C++. This explains the difference in our experience, but not
 the error itself. A minimally reproducible example:

 #include msp430.h
 #include stdint.h

 int main(int argc, char *argv[]) {
 uint8_t addr = 0x02;
 P4OUT |= addr;
 return 0;
 }

 Compiled with:

 msp430-g++ -mmcu=msp430fr5969 -c error.cpp -Os





 On Fri, Sep 6, 2013 at 11:35 AM, Peter Bigot big...@acm.org wrote:

 I'm unable to duplicate that with the following program using msp430-gcc
 -Os -mmcu=msp430fr5969 -c x.c and similar variants.

 The attributes are documented at
 https://sourceforge.net/apps/mediawiki/mspgcc/index.php?title=Gcc47:20-Bit_Designbut
  it should not be necessary for you to be aware of them for this sort of
 code.

 Peter

 #include msp430.h
 #include stdint.h

 extern uint8_t v;

 int doit ()
 {
   P4OUT |= v;
   return 1;
 }



 On Fri, Sep 6, 2013 at 12:14 PM, Andrew Wygle awy...@berkeley.eduwrote:

 Hello all,

 I'm new to this list, I've been using mspgcc to develop for the new
 MSP430FR5969 (the 64k FRAM MSP), and I recently ran into an error when
 trying to assign to port 4 of that device.

 The line of code is:
 P4OUT |= var;
 where var is an 8-bit unsigned integer less than 8 in this particular
 case.

 The reported error is:
 error: merged types have inconsistent d16/d20 attributes.

 This would seem to indicate some kind of data type width error. This is
 born out by the fact that if I change var to be an unsigned 16-bit
 integer,
 the assignment works just fine. However, P4 should be an 8-bit (byte)
 wide
 port. I'd never seen the d16/d20 notation before, and I wasn't able to
 find
 any information on it through Google, so I'd like to hopefully understand
 what I'm doing wrong and why I'm seeing this error.

 Thanks for the assistance.

 ~Andrew Wygle


 --
 Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
 Discover the easy way to master current and previous Microsoft
 technologies
 and advance your career. Get an incredible 1,500+ hours of step-by-step
 tutorial videos with LearnDevNow. Subscribe today and save!

 http://pubads.g.doubleclick.net/gampad/clk?id=58041391iu=/4140/ostg.clktrk
 ___
 Mspgcc-users mailing list
 Mspgcc-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mspgcc-users




--
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58041391iu=/4140/ostg.clktrk___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] Inconsistent d16/d20 attributes

[Peter Bigot]

I'm unable to duplicate that with the following program using msp430-gcc
-Os -mmcu=msp430fr5969 -c x.c and similar variants.

The attributes are documented at
https://sourceforge.net/apps/mediawiki/mspgcc/index.php?title=Gcc47:20-Bit_Designbut
it should not be necessary for you to be aware of them for this sort
of
code.

Peter

#include msp430.h
#include stdint.h

extern uint8_t v;

int doit ()
{
  P4OUT |= v;
  return 1;
}



On Fri, Sep 6, 2013 at 12:14 PM, Andrew Wygle awy...@berkeley.edu wrote:

 Hello all,

 I'm new to this list, I've been using mspgcc to develop for the new
 MSP430FR5969 (the 64k FRAM MSP), and I recently ran into an error when
 trying to assign to port 4 of that device.

 The line of code is:
 P4OUT |= var;
 where var is an 8-bit unsigned integer less than 8 in this particular case.

 The reported error is:
 error: merged types have inconsistent d16/d20 attributes.

 This would seem to indicate some kind of data type width error. This is
 born out by the fact that if I change var to be an unsigned 16-bit integer,
 the assignment works just fine. However, P4 should be an 8-bit (byte) wide
 port. I'd never seen the d16/d20 notation before, and I wasn't able to find
 any information on it through Google, so I'd like to hopefully understand
 what I'm doing wrong and why I'm seeing this error.

 Thanks for the assistance.

 ~Andrew Wygle


 --
 Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
 Discover the easy way to master current and previous Microsoft technologies
 and advance your career. Get an incredible 1,500+ hours of step-by-step
 tutorial videos with LearnDevNow. Subscribe today and save!
 http://pubads.g.doubleclick.net/gampad/clk?id=58041391iu=/4140/ostg.clktrk
 ___
 Mspgcc-users mailing list
 Mspgcc-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mspgcc-users


--
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58041391iu=/4140/ostg.clktrk___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] SR getting corrupted

[Peter Bigot]

On Thu, Sep 5, 2013 at 2:20 PM, ravim ravi.mandl...@gmail.com wrote:

 Thank you Gentlemen for the responses. I fear the same, my device does not
 wake up from LPM, and since everything depends on timer interrupt and it
 ceases to fire, the whole system does not other then interrupt of receiving
 packets.

 Here is my implementation of timer interrupt. Please correct me if I am
 doing it wrong.

 I call this initializeRandomTimer in main function
 void initializeRandomTimer(){

 BCSCTL3 |= LFXT1S_2;
 TACCTL0 = CCIE;
 TACCR0= 437 ;
 TACTL = MC_1 | TASSEL_1 | ID_3;


MC_1 is MC__UP, which counts up to CCR0 once then stops.

ID_3 divides the input clock by 8.

TASSEL_1 is TASSEL__ACLK which you configure to VLOCLK which is nominally
12 kHz.  If you're dividing by 8, it's about 1500 Hz, which wraps at about
43 minutes.  That you stop seeing activity after about 45-60 minutes (and
that VLOCLK is often slower then 12 kHz) makes this look like a candidate
source for the problem.

I didn't see anything where you clear TAR (reset it to zero, e.g. with
TACLR in the TACTL assignment), or where you reset the timer after the
first time it fires.   Look at whatever code is resetting your timer, and
make sure it's done right.   Or use MC_2 which does continuous, and reset
the target threshold with either:

  TACCR0 += 437;

or

 TACCR0 = TAR + 437;

in your interrupt routine (think about the differences and pick the one
appropriate to your needs).  If in normal operation your timer does fire
about every 300ms (437/1500) for the 45 minutes the system works then
perhaps this isn't the issue.  I'd still look pretty closely at the timer
configuration.

I don't know what this code you mention in your later mail does, but if it
does what its use implies it would not cause the problem.  (What it should
do is save SR, disable interrupts, then restore SR.  That'd be fine if
interrupts are enabled at all other times.)

bspIState_t  intState;
BSP_ENTER_CRITICAL_SECTION(intState);
BSP_EXIT_CRITICAL_SECTION(intState);

Peter


   }


 here is my ISR

 interrupt(TIMERA0_VECTOR) Timer_A (void)
 {
if(++sendInterval = SENDINTERVAL){
   radioReady=1;
  sendInterval = 0;

}

P1OUT ^= 0x01;
 if(++timercounter=20){
 globaltimer++;
 timercounter=0;
   // radioReady=1;
 }

 __bic_SR_register_on_exit(LPM1_bits);
 }


 and here is my for loop in main

 for(;;){

 //enter LPM1
 __bis_SR_register(LPM1_bits);

 //TIMER interrupt fired


 //If our radio is ready to fire
 if(radioReady==1){

mrfiPacket_t packet;
packet.frame[0] = 8+20;
packet.frame[RXPACKET_HEADER]  = TXHI;
sendPacket(LOWPOWER, packet);
 }

 }

 my global interrupts are enabled in main.  Timer gets stuck after an hour
 or so, when receiving a packet from similar other device.


 Thanks and Regards,
 Ravi


 On Thu, Sep 5, 2013 at 6:52 AM, Peter Bigot-4 [via MSP430 gcc - Users] 
 ml-node+s1086195n6866...@n5.nabble.com wrote:

  Are you sure that there is an interrupt that will wake you from LPM1,
 that
  it is firing, and that when it finishes it clears the LPM flags on the
  stack so that the MCU will return to active mode?  What you describe so
  far
  is exactly what should happen if no wakeup occurs.  You should be able to
  examine the SR value from mspdebug or gdb since it's r2.
 
 
  On Thu, Sep 5, 2013 at 3:06 AM, Wayne Uroda [hidden email]
 http://user/SendEmail.jtp?type=nodenode=6866i=0
  wrote:
 
   I don't think bt actually works correctly on mspgdb (at least it never
  has
   for me in the last 6 years). I recommend you check the sp directly with
  the
   info registers command (or simply i r). The sp is r1 if I recall
   correctly.
  
   Then you can dump the memory in your stack and do something of a manual
   backtrace - if you know the current pc (again available through the
   registers) and you have a full assembly listing it should be possible
 to
   spot the return addresses in the stack (or simply check every word, if
  it
   corresponds to a location in code just following where you called a
   function then it is likely a return address - note I've only ever done
  this
   in my own software which I know back-to-front and it is all 16bit
   addressing, no msp430x).
  
   Or, you could try mspdebug - I think it has many debugging features and
   probably has a working bt command (I am still use mspgdb though so
 I'm
   not sure).
  
   - Wayne
  
   On 05/09/2013, at 16:38, ravim [hidden email]
 http://user/SendEmail.jtp?type=nodenode=6866i=1
  wrote:
  
I am working on a project which involves CC2500 and msp430f2274. I
  have
   been
struggling with a bug for more than 4 weeks, and still unable to
 debug
   it.
My code stops working after an hour (just time, however device keep
receiving packets)
   
During my debugging, I have checked stack which

Re: [Mspgcc-users] SR getting corrupted

[Peter Bigot]

Are you sure that there is an interrupt that will wake you from LPM1, that
it is firing, and that when it finishes it clears the LPM flags on the
stack so that the MCU will return to active mode?  What you describe so far
is exactly what should happen if no wakeup occurs.  You should be able to
examine the SR value from mspdebug or gdb since it's r2.


On Thu, Sep 5, 2013 at 3:06 AM, Wayne Uroda w.ur...@gmail.com wrote:

 I don't think bt actually works correctly on mspgdb (at least it never has
 for me in the last 6 years). I recommend you check the sp directly with the
 info registers command (or simply i r). The sp is r1 if I recall
 correctly.

 Then you can dump the memory in your stack and do something of a manual
 backtrace - if you know the current pc (again available through the
 registers) and you have a full assembly listing it should be possible to
 spot the return addresses in the stack (or simply check every word, if it
 corresponds to a location in code just following where you called a
 function then it is likely a return address - note I've only ever done this
 in my own software which I know back-to-front and it is all 16bit
 addressing, no msp430x).

 Or, you could try mspdebug - I think it has many debugging features and
 probably has a working bt command (I am still use mspgdb though so I'm
 not sure).

 - Wayne

 On 05/09/2013, at 16:38, ravim ravi.mandl...@gmail.com wrote:

  I am working on a project which involves CC2500 and msp430f2274. I have
 been
  struggling with a bug for more than 4 weeks, and still unable to debug
 it.
  My code stops working after an hour (just time, however device keep
  receiving packets)
 
  During my debugging, I have checked stack which is fine. I checked
 globals
  too, which have legitimate values too.
 
  Whenever my code gets stuck, msp430-gdb bt  always always gives me just
 this
 
  0x8092 in main ()
 
  When I dissemble my code around that address,
 
  08084: b0 12 72 86   CALL#wor_start
 08088: b0 12 38 90   CALL#initializeRandomTimer
 0808c: 32 d2 EINT
 0808e: 32 d0 50 00   BIS #0x0050, SR
 08092: 5f 42 0e 02   MOV.B   radioReady, R15
 08096: 5f 93 CMP.B   #0x0001, R15
 
 
  I believe some how my SR is getting corrupted. I would really appreciate
 why
  it could be getting corrupted. I mean what could be possible reasons for
  getting SR corruption.
 
  Thanks and regards.
  Ravi
 
 
 
  --
  View this message in context:
 http://msp430-gcc-users.1086195.n5.nabble.com/SR-getting-corrupted-tp6864.html
  Sent from the MSP430 gcc - Users mailing list archive at Nabble.com.
 
 
 --
  Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
  Discover the easy way to master current and previous Microsoft
 technologies
  and advance your career. Get an incredible 1,500+ hours of step-by-step
  tutorial videos with LearnDevNow. Subscribe today and save!
 
 http://pubads.g.doubleclick.net/gampad/clk?id=58041391iu=/4140/ostg.clktrk
  ___
  Mspgcc-users mailing list
  Mspgcc-users@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/mspgcc-users


 --
 Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
 Discover the easy way to master current and previous Microsoft technologies
 and advance your career. Get an incredible 1,500+ hours of step-by-step
 tutorial videos with LearnDevNow. Subscribe today and save!
 http://pubads.g.doubleclick.net/gampad/clk?id=58041391iu=/4140/ostg.clktrk
 ___
 Mspgcc-users mailing list
 Mspgcc-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mspgcc-users

--
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58041391iu=/4140/ostg.clktrk___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] SR getting corrupted

[Peter Bigot]

It's not necessarily wrong, but if there's a control path through
sendPacket that leaves interrupts disabled what you observe would happen.
Test that by either looking for GIE to be clear in SR when sendPacket
returns, or work around it by using __bis_SR_register(LPM1_bits | GIE).

There is a more esoteric possibility at
https://sourceforge.net/p/mspgcc/bugs/341/ but I don't believe it affects
the 2xx MCUs.

Peter


On Thu, Sep 5, 2013 at 2:20 PM, ravim ravi.mandl...@gmail.com wrote:

 Thank you Gentlemen for the responses. I fear the same, my device does not
 wake up from LPM, and since everything depends on timer interrupt and it
 ceases to fire, the whole system does not other then interrupt of receiving
 packets.

 Here is my implementation of timer interrupt. Please correct me if I am
 doing it wrong.

 I call this initializeRandomTimer in main function
 void initializeRandomTimer(){

 BCSCTL3 |= LFXT1S_2;
 TACCTL0 = CCIE;
 TACCR0= 437 ;
 TACTL = MC_1 | TASSEL_1 | ID_3;
   }


 here is my ISR

 interrupt(TIMERA0_VECTOR) Timer_A (void)
 {
if(++sendInterval = SENDINTERVAL){
   radioReady=1;
  sendInterval = 0;

}

P1OUT ^= 0x01;
 if(++timercounter=20){
 globaltimer++;
 timercounter=0;
   // radioReady=1;
 }

 __bic_SR_register_on_exit(LPM1_bits);
 }


 and here is my for loop in main

 for(;;){

 //enter LPM1
 __bis_SR_register(LPM1_bits);

 //TIMER interrupt fired


 //If our radio is ready to fire
 if(radioReady==1){

mrfiPacket_t packet;
packet.frame[0] = 8+20;
packet.frame[RXPACKET_HEADER]  = TXHI;
sendPacket(LOWPOWER, packet);
 }

 }

 my global interrupts are enabled in main.  Timer gets stuck after an hour
 or so, when receiving a packet from similar other device.


 Thanks and Regards,
 Ravi


 On Thu, Sep 5, 2013 at 6:52 AM, Peter Bigot-4 [via MSP430 gcc - Users] 
 ml-node+s1086195n6866...@n5.nabble.com wrote:

  Are you sure that there is an interrupt that will wake you from LPM1,
 that
  it is firing, and that when it finishes it clears the LPM flags on the
  stack so that the MCU will return to active mode?  What you describe so
  far
  is exactly what should happen if no wakeup occurs.  You should be able to
  examine the SR value from mspdebug or gdb since it's r2.
 
 
  On Thu, Sep 5, 2013 at 3:06 AM, Wayne Uroda [hidden email]
 http://user/SendEmail.jtp?type=nodenode=6866i=0
  wrote:
 
   I don't think bt actually works correctly on mspgdb (at least it never
  has
   for me in the last 6 years). I recommend you check the sp directly with
  the
   info registers command (or simply i r). The sp is r1 if I recall
   correctly.
  
   Then you can dump the memory in your stack and do something of a manual
   backtrace - if you know the current pc (again available through the
   registers) and you have a full assembly listing it should be possible
 to
   spot the return addresses in the stack (or simply check every word, if
  it
   corresponds to a location in code just following where you called a
   function then it is likely a return address - note I've only ever done
  this
   in my own software which I know back-to-front and it is all 16bit
   addressing, no msp430x).
  
   Or, you could try mspdebug - I think it has many debugging features and
   probably has a working bt command (I am still use mspgdb though so
 I'm
   not sure).
  
   - Wayne
  
   On 05/09/2013, at 16:38, ravim [hidden email]
 http://user/SendEmail.jtp?type=nodenode=6866i=1
  wrote:
  
I am working on a project which involves CC2500 and msp430f2274. I
  have
   been
struggling with a bug for more than 4 weeks, and still unable to
 debug
   it.
My code stops working after an hour (just time, however device keep
receiving packets)
   
During my debugging, I have checked stack which is fine. I checked
   globals
too, which have legitimate values too.
   
Whenever my code gets stuck, msp430-gdb bt  always always gives me
  just
   this
   
0x8092 in main ()
   
When I dissemble my code around that address,
   
08084: b0 12 72 86   CALL#wor_start
   08088: b0 12 38 90   CALL#initializeRandomTimer
   0808c: 32 d2 EINT
   0808e: 32 d0 50 00   BIS #0x0050, SR
   08092: 5f 42 0e 02   MOV.B   radioReady, R15
   08096: 5f 93 CMP.B   #0x0001, R15
   
   
I believe some how my SR is getting corrupted. I would really
  appreciate
   why
it could be getting corrupted. I mean what could be possible reasons
  for
getting SR corruption.
   
Thanks and regards.
Ravi
   
   
   
--
View this message in context:
  
 
 http://msp430-gcc-users.1086195.n5.nabble.com/SR-getting-corrupted-tp6864.html
Sent from the MSP430 gcc - Users mailing list archive at Nabble.com

Re: [Mspgcc-users] Newcomer unable to compile a very simple program in ubuntu 13.04.

[Peter Bigot]

No.  Unless you are using a custom linker script you never need to
reference it directly.  Use -mmcu=whatever when compiling and linking: that
adds the appropriate linker paths and compiler flags.

Only if that fails do you have a problem with msp430-mcu (the package that
provides the linker scripts), which may not be installed depending on what
apt-get command you ran.

Peter

On Fri, Aug 9, 2013 at 6:42 AM, Rahimov sandror...@gmail.com wrote:

 Hi,
 The Linker is looking for the ldscript file memory.x in your system and
 cannot find it.. try to find it manually in your mspgcc installation folder
 smth. like this folder

 msp430\lib\ldscripts.. there should be this ld script file.. and try
 to give the phad to your script in compiler options with option -T

 -T scriptfile
--script=scriptfile
Use scriptfile as the linker script.  This script replaces ld’s
default linker script (rather than adding to it), so commandfile
must specify everything necessary to describe the output file.
If scriptfile does not exist in the current directory, ld
 looks
for it in the directories specified by any preceding -L options.

 Hope it helps,

 Regards



 On Fri, Aug 9, 2013 at 1:21 PM, Sigmatec Automação e Sistemas 
 sigtecha...@gmail.com wrote:

 
  Hello,
 
  I'm just starting to explore this platform and am unable to solve a
  configuration issue (I guess) in the first program I try, very simple,
  below. The set I use is the MSP430 Ultra-Low-Power MCUs eZ430-F2013
  Development Tool with ubuntu v13.04. The installed MSP430 toolchain is
  the default one from its apt-get command.
  include msp430x22x4.h
 
  volatile unsigned int i; // volatile to prevent optimization
 
  void main(void)
  {
  WDTCTL = WDTPW + WDTHOLD; // stop watchdog timer
  P1DIR |= 0X01; // set P1.0 to output direction
 
  for(;;) {
  P1OUT ^= 0x01; // toogle P1.0 exclusive-OR
  i = 5; // delay
  do (i--);
  while (i != 0);
  }
  }
 
  When I try to compile it under ubuntu 13.04 I receive the error message
  below,
 
  sigmatech@sigmatech:~/Desktop/ESL/code/MSP430$ msp430-gcc hello_word.c
  /usr/lib/gcc/msp430/4.6.3/../../../../msp430/bin/ld: cannot open linker
  script file memory.x: No such file or directory
  collect2: ld returned 1 exit
  status/usr/lib/gcc/msp430/4.6.3/../../../../msp430/bin/ld: cannot open
  linker script file memory.x: No such file or directory
  collect2: ld returned 1 exit status
 
  Could anyone help please?
 
  TIA
 
  Sigmatech
  PS - is there an emacs mode available?
 
 
 
 
 
 
 
 --
  Get 100% visibility into Java/.NET code with AppDynamics Lite!
  It's a free troubleshooting tool designed for production.
  Get down to code-level detail for bottlenecks, with 2% overhead.
  Download for free and get started troubleshooting in minutes.
 
 http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk
  ___
  Mspgcc-users mailing list
  Mspgcc-users@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/mspgcc-users
 


 --
 Get 100% visibility into Java/.NET code with AppDynamics Lite!
 It's a free troubleshooting tool designed for production.
 Get down to code-level detail for bottlenecks, with 2% overhead.
 Download for free and get started troubleshooting in minutes.
 http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk
 ___
 Mspgcc-users mailing list
 Mspgcc-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mspgcc-users


--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with 2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] Issue mspgcc-users@lists.sourceforge.net

[Peter Bigot]

-ma20 -msr20 is an incoherent combination of flags: you are asking for
20-bit object sizes and 20-bit support in interrupts in an application that
uses 16-bit code and data pointers.

Use the -mmemory-model option to select a supported combination (medium is
recommended), and don't use attributes on declarations unless you need to
mix memory models (which is not recommended).



On Tue, Aug 6, 2013 at 2:01 PM, Johnaltan Neves johnal...@gmail.com wrote:

 Hello,

 I'm trying compile my firmware using msp430-gcc using 20 bits. I can very
 well compile using source directives (__attribute__((__a20__)))  But if I
 try compile using -ma20 and -msr20 options it doesn't work and then this
 error appears:

 /usr/local/msp430/bin/msp430-gcc  ./LCDL.o ./TLC5941.o ./cpu.o ./dac.o
 ./delay.o ./main.o ./menu.o ./messenger.o ./metter.o ./mystring.o
 ./recorder.o ./system.o ./teclado.o  -mmcu=msp430fg4618 -lm -lc -lgcc -lfp
 -ma20 -msr20 -o espectro_tiny.elf
 /usr/local/msp430/lib/gcc/msp430/4.7.0/../../../../msp430/bin/ld: Warning:

 /usr/local/msp430/lib/gcc/msp430/4.7.0/../../../../msp430/lib/libm.a(ef_log10.o)
 does not have CPUX target data
 /usr/local/msp430/lib/gcc/msp430/4.7.0/../../../../msp430/bin/ld: Warning:

 /usr/local/msp430/lib/gcc/msp430/4.7.0/../../../../msp430/lib/libm.a(sf_modf.o)
 does not have CPUX target data
 /usr/local/msp430/lib/gcc/msp430/4.7.0/../../../../msp430/bin/ld: Warning:

 /usr/local/msp430/lib/gcc/msp430/4.7.0/../../../../msp430/lib/libm.a(ef_log.o)
 does not have CPUX target data
 /usr/local/msp430/lib/gcc/msp430/4.7.0/../../../../msp430/bin/ld: Warning:

 /usr/local/msp430/lib/gcc/msp430/4.7.0/../../../../msp430/lib/libc.a(errno.o)
 does not have CPUX target data
 /usr/local/msp430/lib/gcc/msp430/4.7.0/../../../../msp430/bin/ld: Warning:

 /usr/local/msp430/lib/gcc/msp430/4.7.0/../../../../msp430/lib/libc.a(atoi.o)
 does not have CPUX target data
 /usr/local/msp430/lib/gcc/msp430/4.7.0/../../../../msp430/bin/ld: Warning:

 /usr/local/msp430/lib/gcc/msp430/4.7.0/../../../../msp430/lib/libc.a(sprintf.o)
 does not have CPUX target data
 /usr/local/msp430/lib/gcc/msp430/4.7.0/../../../../msp430/bin/ld: Warning:

 /usr/local/msp430/lib/gcc/msp430/4.7.0/../../../../msp430/lib/libc.a(vuprintf.o)
 does not have CPUX target data
 /usr/local/msp430/lib/gcc/msp430/4.7.0/../../../../msp430/bin/ld: Warning:

 /usr/local/msp430/lib/gcc/msp430/4.7.0/../../../../msp430/lib/libc.a(itoa.o)
 does not have CPUX target data
 /usr/local/msp430/lib/gcc/msp430/4.7.0/../../../../msp430/bin/ld: Warning:

 /usr/local/msp430/lib/gcc/msp430/4.7.0/../../../../msp430/lib/libc.a(ltoa.o)
 does not have CPUX target data
 /usr/local/msp430/lib/gcc/msp430/4.7.0/../../../../msp430/bin/ld: Warning:

 /usr/local/msp430/lib/gcc/msp430/4.7.0/../../../../msp430/lib/libc.a(strchr.o)
 does not have CPUX target data
 /usr/local/msp430/lib/gcc/msp430/4.7.0/../../../../msp430/bin/ld: Warning:

 /usr/local/msp430/lib/gcc/msp430/4.7.0/../../../../msp430/lib/libc.a(strcmp.o)
 does not have CPUX target data
 /usr/local/msp430/lib/gcc/msp430/4.7.0/../../../../msp430/bin/ld: Warning:

 /usr/local/msp430/lib/gcc/msp430/4.7.0/../../../../msp430/lib/libc.a(memcmp.o)
 does not have CPUX target data
 /usr/local/msp430/lib/gcc/msp430/4.7.0/../../../../msp430/bin/ld: Warning:

 /usr/local/msp430/lib/gcc/msp430/4.7.0/../../../../msp430/lib/libc.a(strcpy.o)
 does not have CPUX target data
 /usr/local/msp430/lib/gcc/msp430/4.7.0/../../../../msp430/bin/ld: Warning:

 /usr/local/msp430/lib/gcc/msp430/4.7.0/../../../../msp430/lib/libc.a(memcpy.o)
 does not have CPUX target data
 /usr/local/msp430/lib/gcc/msp430/4.7.0/../../../../msp430/bin/ld: Warning:

 /usr/local/msp430/lib/gcc/msp430/4.7.0/../../../../msp430/lib/libc.a(memset.o)
 does not have CPUX target data
 /usr/local/msp430/lib/gcc/msp430/4.7.0/../../../../msp430/bin/ld: Warning:

 /usr/local/msp430/lib/gcc/msp430/4.7.0/../../../../msp430/lib/libc.a(strtok.o)
 does not have CPUX target data

 What is wrong? Can you help me? I saw that on
 /usr/local/msp430/lib/gcc/msp430/4.7.0/mcpu-430x/ don't have libc.a,
 libm.a...


 --
 Johnaltan Ivon Neves


 --
 Get 100% visibility into Java/.NET code with AppDynamics Lite!
 It's a free troubleshooting tool designed for production.
 Get down to code-level detail for bottlenecks, with 2% overhead.
 Download for free and get started troubleshooting in minutes.
 http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk
 ___
 Mspgcc-users mailing list
 Mspgcc-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mspgcc-users


--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with 2% overhead. 
Download 

Re: [Mspgcc-users] Size of global variable

[Peter Bigot]

The extra word is probably the watchdog timer clear value, which is
initialized on reset.  You can exclude it by using -mdisable-watchdog.
mspgcc uses different sections than AVR, and for mspgcc .noinit is not
merged with .bss.  With the default linker script .noinit is between the
bottom of the stack and the top of .bss.

You can use msp430-objdump -x app.elf to see the list of sections available
and what's in them (at what address).  That information can tell you what's
going to be below the stack, hence the first thing that would get
overwritten when it overruns.

#include sys/crtld.h provides declarations for common symbols related to
where things are in memory.  Most of those come from the generic linker
scripts, but a couple (e.g. info section addresses) from the MCU-specific
memory.x linker scripts; all linker scripts are in
installdir/msp430/lib/ldscripts/.

Peter


On Mon, Jul 29, 2013 at 5:28 PM, Wayne Uroda w.ur...@gmail.com wrote:

 Hi Daniel,

 Yesterday I was looking at just this and to my surprise there was one
 extra word allocated to .noinit. I had never seen this before in all my
 years, and I was almost filling over it with a pattern to measure my stack
 usage. My point is that one should add the size of bss and data and noinit
 to find the statically allocated area, or is this incorrect?

 At runtime you can find the address of the last of the static data by
 taking the address of _end, which is provided by the linker script,
 something like:

 void *_end;
 UInt16 endAddr = (UInt16)_end;

 (Please let me know if there is a better/preferred way to do this).

 You can also get the current stack pointer by doing something like this:
 UInt16 sp;

 __volatile__ __asm__ ( mov r1, %0 : =g (sp));

 This tells the compiler to move the stack pointer into the variable sp
 using any method it chooses (register or memory).

 Then you can simply loop from one address to the other and fill with a
 pattern like 0x55 or similar.

 I used this only in a debug environment and wouldn't trust to have it run
 in a production environment because it was something I threw together real
 quick.

 - Wayne

 On 30/07/2013, at 6:22, Daniel Beer dlb...@gmail.com wrote:

  On Mon, Jul 29, 2013 at 12:56:31PM -0700, ravim wrote:
  My apologies if I am asking something irrelevant to this forum. We are
 using
  mspgcc and mspdebug for our project. We are facing some issues with
 what we
  assume might be stack overflow. The timer interrupts stops working after
  around 2 hours, however device still receives packets. Also, when we
 reset
  the device after timer gets stuck, they never turn back on unless we
  re-install the code.  We are trying to debug.
 
  I wanted to know if there is any possible way we can know the size of
 global
  variables in the binary? This will help us narrow down a few specifics.
 We
  know there is something in TinyOs when we make, it let us know size of
  global variables, we are looking for something similar in mspdebug.
 
  We would really appreciate any help.
 
  Try size filename.elf. Add data and bss to get the total size of
  statically allocated data. You can also use size on the individual
  object files if you want to narrow down your search, but remember to use
  --common if you need global (non-static) variables to be counted.
 
  Cheers,
  Daniel
 
  --
  Daniel Beer dlb...@gmail.comwww.dlbeer.co.nz
  IRC: inittab (Freenode)PGP key: 2048D/160A553B
 
 
 --
  Get your SQL database under version control now!
  Version control is standard for application code, but databases havent
  caught up. So what steps can you take to put your SQL databases under
  version control? Why should you start doing it? Read more to find out.
 
 http://pubads.g.doubleclick.net/gampad/clk?id=49501711iu=/4140/ostg.clktrk
  ___
  Mspgcc-users mailing list
  Mspgcc-users@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/mspgcc-users


 --
 Get your SQL database under version control now!
 Version control is standard for application code, but databases havent
 caught up. So what steps can you take to put your SQL databases under
 version control? Why should you start doing it? Read more to find out.
 http://pubads.g.doubleclick.net/gampad/clk?id=49501711iu=/4140/ostg.clktrk
 ___
 Mspgcc-users mailing list
 Mspgcc-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mspgcc-users

--
Get your SQL database under version control now!
Version control is standard for application code, but databases havent 
caught up. So what steps can you take to put your SQL databases under 
version control? Why should you start doing it? Read more to find out.

Re: [Mspgcc-users] Size of global variable

[Peter Bigot]

On Mon, Jul 29, 2013 at 6:06 PM, Daniel Beer dlb...@gmail.com wrote:

 On Mon, Jul 29, 2013 at 05:50:39PM -0500, Peter Bigot wrote:
  The extra word is probably the watchdog timer clear value, which is
  initialized on reset.  You can exclude it by using -mdisable-watchdog.
  mspgcc uses different sections than AVR, and for mspgcc .noinit is not
  merged with .bss.  With the default linker script .noinit is between the
  bottom of the stack and the top of .bss.
 
  You can use msp430-objdump -x app.elf to see the list of sections
 available
  and what's in them (at what address).  That information can tell you
 what's
  going to be below the stack, hence the first thing that would get
  overwritten when it overruns.

 Hrmm, so it appears then that when size says bss it actually means
 the sum of sections which are marked ALLOC but not LOAD, rather than
 literally the .bss section. Is that correct?


Maybe.  I have one program where the length of the .bss section is 
bytes and the length of the .noinit section is 2 bytes, and msp430-size
says it has 2224 bytes in bss.  I couldn't say what else might go into
size's conception of bss length if some of the more esoteric features of
the linker script are exercised.

Peter
--
Get your SQL database under version control now!
Version control is standard for application code, but databases havent 
caught up. So what steps can you take to put your SQL databases under 
version control? Why should you start doing it? Read more to find out.
http://pubads.g.doubleclick.net/gampad/clk?id=49501711iu=/4140/ostg.clktrk___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] msp430-gcc 4.7 bug with shifts?

[Peter Bigot]

Once more: this is not an mspgcc problem (or a TinyProd problem), and
certainly has nothing to do with the shift bug in the subject.

Please don't post to mspgcc-users again about this.  (I don't have any Z1
hardware, and don't use ARM as a Contiki development platform, so I can't
help either.)

You need to get support from Contiki or Zolertia or give up on doing
Contiki development for Z1 hardware on an ARM platform.

Peter


On Wed, Jul 10, 2013 at 3:51 PM, Jhon James softtro...@gmail.com wrote:

 Hello Peter

 Thanks for the pointer. Actually I put the same question on the contiki
 and tinyOS forum but people suggested me to ask on msp430 mailing list on
 how to do the porting on the ARM. I followed this page  (
 http://wiki.contiki-os.org/doku.php?id=msp430x) installed msp430 4.7.0 on
 a PC. Now i am having a problem code gets compiled easily and gets uploaded
 as well but the problem is with the the make login command when i try to
 connect to the sensor mote it gets connected but i see garabage of the
 serial console.

 The Zolertia team has suggested using the TinyProd from the TinyOS writer
 but the this works fine but it is precompiled for PC only. you can see this
 link (
 http://zolertia.sourceforge.net/wiki/index.php/Mainpage:Contiki_installation_Ubuntu
 )

 I installed the version 4.6.3 msp430-gcc using this  command

 apt-get install binutils-msp430 gcc-msp430 msp430-libc msp430mcu mspdebug ant 
 openjdk-7-jdk


  but this version has the same behaviour of loading and compiling code
 sucessfully while make login command returns the garbage on the console. i
 think I am close now need some suggestion.

 I really appreciate your help

 Regard's





 On Wed, Jul 10, 2013 at 6:40 AM, Peter Bigot big...@acm.org wrote:

 mspgcc does not program images onto MSP430s, so updating to 4.7.0 would
 not fix the problem.

 mspdebug is the tool I use for installing images, but Contiki has
 traditionally used the BSL facility over a serial line.  If make TARGET=z1
 hello-world.upload does not result in the board being programmed you
 should contact Zolertia for support.  It may be as simple as updating the
 udev rules to recognize the board, and is in any case likely to be a Linux
 issue rather than an ARM issue.  You could first test basic serial
 functionality by taking a board programmed on the PC that does serial
 output and making sure you can plug it into the ARM board and receive that
 output.

 Questions of this nature really belong on a Zolertia or Contiki support
 forum, though.

 Peter



 On Tue, Jul 9, 2013 at 8:28 PM, Jhon James softtro...@gmail.com wrote:

 Hello Peter,

 I have previously used the Contiki with Z1 motes on a PC. I used
 msp430-gcc and everything worked quite well. I have now an embedded ARM
 board on which I am trying to install the msp430-gcc compiler. The board
 comes with Ubuntu installed it it. I tried installed msp430-gcc 4.63 on it
 but it did not worked for me since motes cannot be programmed using it. It
 is reommended to use msp430-gcc 4.7.0 I tried but did not suceeded can you
 share some to follow or packages to install. Since you are using contiki

 I appreciate your pointers

 Thanks


 On Thu, Jul 4, 2013 at 8:13 PM, Peter Bigot big...@acm.org wrote:

 I'm still analyzing Contiki's mac/rdc/radio layers, and won't be
 looking at
 CoAP for a while.  But I see generally what's going on there; it's
 probably
 a separate bug that only shows up now that the first one has been fixed.

 It'll take a couple days to get back to this.

 Peter


 On Thu, Jul 4, 2013 at 9:38 AM, Daniele Alessandrelli 
 daniele.alessandre...@gmail.com wrote:

  Thank you for the quick patch.
  However, there are still some problems. For example, when I compile
  the attached code (sorry, I can't replicate the problem with simple
  code), I get the following error:
  /tmp/ccNaHhxW.s: Assembler messages:
  /tmp/ccNaHhxW.s:1427: Error: Repeated instruction must have register
  mode operands
 
  The problematic code snippet is from line 699 to 706:
  ...
  case COAP_OPTION_BLOCK1:
coap_pkt-block1_num = coap_parse_int_option(current_option,
  option_len);
coap_pkt-block1_more = (coap_pkt-block1_num  0x08)3;
coap_pkt-block1_size = 16  (coap_pkt-block1_num  0x07);
coap_pkt-block1_offset = (coap_pkt-block1_num 
  ~0x000F)(coap_pkt-block1_num  0x07);
coap_pkt-block1_num = 4;
printf(Block1 [%lu%s (%u B/blk)]\n, coap_pkt-block1_num,
  coap_pkt-block1_more ? + : , coap_pkt-block1_size);
break;
  ...
 
  Part of the produced assembly code is the following:
  ...
  mov r12, r4
  and #7, r4
  mov.b   r4, r11
  mov #16, @r1
  cmp.b   #0, r11
  jeq .L158
  add.b   #-1, r11
  .rptr11
  rlax@r1
  .L158:
  mov @r1, 96(r9)
  ...
 
  The invalid instruction seems to be the following
  .rptr11
  rlax@r1

Re: [Mspgcc-users] mspgcc Red Hat release

[Peter Bigot]

Of course I haven't tried newlib for msp430 since I'm waiting until the
entire toolchain is available in released versions of the required packages
(which I expect won't be until late March 2014 when gcc 4.9.0 is
released).  However, I too have found newlib completely unsuitable for
embedded programming on MCUs with less than 128KB of flash.

To that end I split off the string formatting infrastructure from
msp430-libc into https://github.com/pabigot/embtextf about a year ago, and
have been using that effectively on small EFM32 Cortex-M3 devices with the
Mentor Graphics/CodeSourcery GNU toolchain builds.  It gets tricky
sometimes to keep all newlib's trendrils from sucking in the universe when
touching anything related to stdio, but if your main focus is printf-style
formatting embtextf will cut newlib's footprint by 20KB.  It doesn't
support floating point at the moment, but that's pretty irrelevant to
MSP430 and will probably be fixed if I ever do anything serious with an M4F
device.

I have also heard rumors that ARM folks are working on alternative to
newlib that is suited for true embedded development, but haven't taken the
time to track that down yet.

Peter

On Mon, Jul 8, 2013 at 9:43 AM, Grant Edwards grant.b.edwa...@gmail.comwrote:

 On 2013-07-08, Brendan Conoboy b...@redhat.com wrote:
  On 07/04/2013 07:10 PM, Peter Bigot wrote:
  I have no information about Red Hat's toolchain other than what's been
  announced here, but:
 
  Red Hat's MSP430 toolchain is entirely unrelated to mspgcc.  I am
 unaware
  of any information having been provided related to support for libc or
  specific MCUs in this new work.  While msp430mcu and msp430-libc might
 work
  with some fiddling, it's not clear they're needed, I very much doubt
  they're the intended solution, and they certainly don't incorporate any
  changes to accommodate Red Hat's implementation.
 
  There is now msp430 support in newlib:
 
  http://www.cygwin.com/ml/newlib/2013/msg00362.html
 
  Since we did a clean re-implementation of the MSP port we can't comment
  on the pre-existing mspgcc library solutions: We really don't know.  Our
  plan is to support and enhance standard upstream infrastructure.  For
  libc this means newlib.

 How does newlib compare with the old msp430 libc when it comes to
 size?  In the past, when I've tried newlib for embedded work it was
 _huge_.

 --
 Grant Edwards   grant.b.edwardsYow! Th' MIND is the
 Pizza
   at   Palace of th' SOUL
   gmail.com



 --
 This SF.net email is sponsored by Windows:

 Build for Windows Store.

 http://p.sf.net/sfu/windows-dev2dev
 ___
 Mspgcc-users mailing list
 Mspgcc-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mspgcc-users

--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] Latest LTS mps430-gdb could not bib uilt with clang host compiler due to obvious C errors

[Peter Bigot]

If you're using the msp430-gdb patches from mspgcc, add local patch.
msp430-gdb from mspgcc is not supported anymore; eventually RH will provide
a replacement but it'll probably only work with their version of the
compiler.


On Tue, Jun 11, 2013 at 3:28 AM, Lev Serebryakov l...@serebryakov.spb.ruwrote:

 Hello, Mspgcc-users.

   What  should  I  do with these errors? msp430-gdb is not usable with
 system compiler (which is clang 3.3/3.4) on FreeBSD CURRENT anymore
 :( Errors looks like easy to fix (as they are obvious
 almost-syntax-level errors -- especially, errors with
 get_stop_addr()), but I'm not sure what should I do with them/ Report
 to upstream? Add local patch? Pull fix for them from upstream gdb 7.4,
 if it has them fixed?

 mv version.c-tmp version.c
 cc -c -DHAVE_CONFIG_H -DPROFILE=1 -DWITH_PROFILE=-1
  -DDEFAULT_INLINE=0  -I. -I. -I../common -I./../common
 -I../../include -I./../../include -I../../bfd -I./../../bfd -I../../opcodes
 -I./../../opcodes  -O2 -pipe -fno-strict-aliasing version.c
 cc -c -DHAVE_CONFIG_H -DPROFILE=1 -DWITH_PROFILE=-1
  -DDEFAULT_INLINE=0  -I. -I. -I../common -I./../common
 -I../../include -I./../../include -I../../bfd -I./../../bfd -I../../opcodes
 -I./../../opcodes  -O2 -pipe -fno-strict-aliasing interp.c
 interp.c:1276:8: warning: format specifies type 'int' but the argument has
 type 'unsigned long' [-Wformat]
sizeof (unsigned long));
^~
 interp.c:1686:27: warning: passing 'char *' to parameter of type 'const
 unsigned char *' converts between pointers to integer types with different
 sign [-Wpointer-sign]
   sim_write (sd, lma, buffer, size);
   ^~
 interp.c:1827:38: warning: format specifies type 'int' but the argument
 has type 'unsigned long' [-Wformat]
   fprintf (stderr, Cycles:  %d\n, alu.cycles);
  ~~ ^~
  %lu
 interp.c:1828:43: warning: format specifies type 'int' but the argument
 has type 'unsigned long' [-Wformat]
   fprintf (stderr, Instructions: %d\n, alu.insns);
   ~~ ^
   %lu
 interp.c:1829:42: warning: format specifies type 'int' but the argument
 has type 'unsigned long' [-Wformat]
   fprintf (stderr, Interrupts:  %d\n, alu.interrupts);
  ~~ ^~
  %lu
 interp.c:1883:5: error: non-void function 'get_stop_addr' should return a
 value [-Wreturn-type]
 return;
 ^
 interp.c:1887:7: error: non-void function 'get_stop_addr' should return a
 value [-Wreturn-type]
   return;
   ^
 interp.c:1894:5: error: non-void function 'get_stop_addr' should return a
 value [-Wreturn-type]
 return;
 ^
 5 warnings and 3 errors generated.
 gmake[3]: *** [interp.o] Error 1
 gmake[3]: Leaving directory
 `/work/a/ports/devel/msp430-gdb/work/gdb-7.2/sim/msp430'
 gmake[2]: *** [all] Error 1

 --
 // Black Lion AKA Lev Serebryakov l...@serebryakov.spb.ru



 --
 This SF.net email is sponsored by Windows:

 Build for Windows Store.

 http://p.sf.net/sfu/windows-dev2dev
 ___
 Mspgcc-users mailing list
 Mspgcc-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mspgcc-users

--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] mspg++ and c++ includes

[Peter Bigot]

I believe (without checking) that since mspgcc doesn't support C++
exceptions the default is -fno-exceptions.  I suspect rtti is also off by
default, but I don't have the vague reminiscence of having made sure of
that.


On Tue, Jun 11, 2013 at 4:39 AM, Paul Sokolovsky pmis...@gmail.com wrote:

 Hello,

 On Mon, 10 Jun 2013 17:23:00 -0700
 Thomas Taranowski t...@baringforge.com wrote:

  Thanks for the comment Paul.  What are you using for your compiler
  flags?  I'm having a couple issues with mine.
 
  I'm currently using the following:
  -ffunction-sections -fdata-sections -DGCC_MSP430 -Wall -fno-exceptions
  -fno-rtti -fno-enforce-eh-specs -nodefaultlibs

 Well, I'm using:

 msp430-g++ -I../include/   -mmcu=msp430g2553 -O1 -g -Wreturn-type
 -ffunction-sections -fdata-sections -DHW_CONFIG=\hw_config_msp430.hpp\
 -fno-exceptions -c blink.cpp -o bin-msp430/blink.o
 msp430-gcc -mmcu=msp430g2553 -Wl,--gc-sections
 -Wl,-Map=bin-msp430/blink.map,--cref  bin-msp430/blink.o   -o
 bin-msp430/blink

 (I was shocked to see that Energia doesn't pass -fno-exceptions, but I
 myself don't pass -fno-rtti, that needs to be fixed).

 
  This works well in with -O2 specified (release build), but fails with
  memset undefined when running my -O0 debug build.  Presumably the
  optimized version is using the built-in library.  Also, I can't seem
  to get printf back in by adding -lgcc -lc.to the linker flags, as I
  think these get ignored after specifying the -nodefaultlibs argument.
  I really want something to just disable the libstdc++ include.
  Thomas Taranowski | 425-442-9209 | skype: thomas.taranowski |
  baringforge.com
 

 --
 Best regards,
  Paul  mailto:pmis...@gmail.com


 --
 This SF.net email is sponsored by Windows:

 Build for Windows Store.

 http://p.sf.net/sfu/windows-dev2dev
 ___
 Mspgcc-users mailing list
 Mspgcc-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mspgcc-users

--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] 64-bit double

[Peter Bigot]

No plans in mspgcc.  https://sourceforge.net/p/mspgcc/bugs/171/

Red Hat version might have different plans.

Peter


On Mon, Jun 10, 2013 at 5:29 PM, Thomas Taranowski t...@baringforge.comwrote:

 Does anyone know of plans to support the standard 64-bit double type
 for mspgcc?  I have a small source application which uses the 8-byte
 double that I’m trying to make cross platform.



 -Tom


 --
 This SF.net email is sponsored by Windows:

 Build for Windows Store.

 http://p.sf.net/sfu/windows-dev2dev
 ___
 Mspgcc-users mailing list
 Mspgcc-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mspgcc-users

--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] mspg++ and c++ includes

[Peter Bigot]

C++ is not supported by mspgcc.   Some people are using it to some degree
with some success, and may be able to provide hints about improved
compatibility, but no effort has been made to ensure it functions.

It is to be hoped this will be addressed by Red Hat's version.


On Mon, Jun 10, 2013 at 5:34 PM, Thomas Taranowski t...@baringforge.comwrote:

 mspg++ seems to be functioning, but all the standard c++ includes seen
 to be missing.  For example, cstdio, cstdlib, etc.  Am I missing some
 part of the install, or is this work yet to be done?

 -Tom


 --
 This SF.net email is sponsored by Windows:

 Build for Windows Store.

 http://p.sf.net/sfu/windows-dev2dev
 ___
 Mspgcc-users mailing list
 Mspgcc-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mspgcc-users

--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] A question about SD-Card write on MSP-EXP430F5529

[Peter Bigot]

Curious about your motivation for (4) multiple copies.  If you don't
succeed with (3) data integrity, you won't be able to tell that you need a
different copy.  If you do, you'll know on the first read whether that copy
is valid: if it is you don't need the others, and if it isn't then the
others probably got corrupted by the removal of the SD card during or
before the first write so you can't use them either.  Seems (4) doesn't add
value.

Peter


On Fri, Jun 7, 2013 at 11:32 AM, ravim ravi.mandl...@gmail.com wrote:

 Thank you gentlemen for the responses.

 I figured out following things I will do since I have a deadline..

 1. Choose more reliable SD card (I am still looking for options)
 2. Introducing button interrupt to stop writing process and then blinking
 LEDs for to make aware of safe ejection. I will make sure that every
 stakeholder follow the process.
 3. Data integrity - using checksum on sectors and CRC on data packets ( CRC
 I have already done, checksum I am in process of implementing)
 4. Multiple copies of data packets will be sent to make system more
 reliable.

 I really appreciate your responses and time.
 Thanks and regards
 Ravi



 --
 View this message in context:
 http://msp430-gcc-users.1086195.n5.nabble.com/A-question-about-SD-Card-write-on-MSP-EXP430F5529-tp6710p6715.html
 Sent from the MSP430 gcc - Users mailing list archive at Nabble.com.


 --
 How ServiceNow helps IT people transform IT departments:
 1. A cloud service to automate IT design, transition and operations
 2. Dashboards that offer high-level views of enterprise services
 3. A single system of record for all IT processes
 http://p.sf.net/sfu/servicenow-d2d-j
 ___
 Mspgcc-users mailing list
 Mspgcc-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mspgcc-users

--
How ServiceNow helps IT people transform IT departments:
1. A cloud service to automate IT design, transition and operations
2. Dashboards that offer high-level views of enterprise services
3. A single system of record for all IT processes
http://p.sf.net/sfu/servicenow-d2d-j___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] MSP430 GCC goes Red Hat

[Peter Bigot]

Would TI and/or Red Hat please update us on the status of this replacement
for mspgcc?  It's four months past the date we were told to expect a beta,
but I see no discussion of patches for MSP430 support on either the
binutils or gcc mailing lists, and no material in  the public repositories
from the GNU project.

Thanks.

Peter

On Mon, Feb 25, 2013 at 10:23 AM, Brendan Conoboy b...@redhat.com wrote:

 On 02/21/2013 07:12 AM, Luca BRUNO wrote:
  I haven't seen any status update, initial beta or public code branch
  since the original announce (if patches have been scattered across
  several trackers, I may simply have missed them).
  As such I'd like to ask if the project is still on track and if there
  is something that external contributors can help in.

 Hi Luca,

 We'll have an update out shortly, hopefully this week.  Thanks!

 --
 Brendan Conoboy / Red Hat, Inc. / b...@redhat.com


 --
 Everyone hates slow websites. So do we.
 Make your web apps faster with AppDynamics
 Download AppDynamics Lite for free today:
 http://p.sf.net/sfu/appdyn_d2d_feb
 ___
 Mspgcc-users mailing list
 Mspgcc-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mspgcc-users

--
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with 2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] mspgcc undefines too-many-bits shifts in weird way

[Peter Bigot]

Changes to mspgcc are/were driven by tickets filed on the SF bug tracker.
If you'd like this change made after reading the material below, please
file a ticket there.  mspgcc evolution/maintenance is not funded at this
time and the issue is below the threshold that I consider critical enough
to donate time, so the ticket will remain open until somebody takes over
such maintenance.

For the record, I've reconstructed my reasoning from two years ago, which
makes explicit the point Przemek made.  It's not worth the research to
prove it, but again this was justified by similar practices in other gcc
back-ends, even if not x86.

First, the value of a shift expression should be the same whether it is
computed at compile time or at runtime.  I.e., 1  16 should produce the
same value as 1  v when v has the value 16.

Second, the base MSP430 ISA does not have a multi-position shift operation
like x86 does.  It can shift only one bit position at a time.  Variable
shifts must be translated into loops with the iteration count provided at
runtime.  (Second-prime: use of MSP430X which has a limited version of such
instructions should also not result in a change of the value of the shift
expression.)

Third, it is unreasonable when v has the value 63532 to stall the processor
for 65532 iterations of a loop calculating 1  v.  Instead the runtime
code should limit the iteration count.  Since the maximum number of
iterations before the expression value becomes a constant (i.e., the number
of bits in the expression value) will always be a known power of two,
masking the iteration count to preserve only the low bits from 0 to that
number is the simplest solution.

This is the behavior mspgcc currently uses.  To accommodate your request a
test would have to be added at runtime to see whether the iteration count
is equal to or greater than the number of bits in the expression value, and
if so to substitute the constant (0 or ~0) that would have resulted from
the shift operation.  This introduces code bloat, as in the vast majority
of cases people will not be using a shift count that is large enough to
trigger the conditional.

In my opinion increasing generated code size just to accommodate a practice
that is explicitly undefined behavior is a poor use of resources and
improperly encourages a misunderstanding of how C treats this situation.
Having considered the arguments, no, the behavior will not be changed.

Please note that the new back end under development by Red Hat may have
different behavior.

Peter


On Sun, Apr 21, 2013 at 6:10 PM, Paul Sokolovsky pmis...@gmail.com wrote:

 Hello,

 On Sun, 21 Apr 2013 17:06:51 -0500
 Peter Bigot big...@acm.org wrote:

  This decision was intentional, as documented in
  https://sourceforge.net/p/mspgcc/bugs/118/.  My recollection is that
  the choice of how to make things consistent was informed by similar
  behavior in the contemporaneous gcc for x86 or at least one other
  target architecture.

 Thanks for the reference. So, I tested it with x86 gcc 4.4, 4.5, 4.6,
 4.7 (packages as shipped by Ubuntu), all of them produce mathematically
 expected result. msp430-gcc 4.5.3, 4.7.0 both produce unexpected result.

  As you say, the behavior is undefined.  Anybody who expects any
  particular behavior for this situation is confused about how C works
  and should take the issue up with JTC1/SC22/WG14.

 That's why I wrote so many words in the original mail. Yes, in small
 world of JTC1/SC22/WG14 C standard the behavior is undefined. But in
 much bigger world of: mathematics, well-known gcc targets, user
 expectations, principle of least surprise, etc. - it's all pretty well
 defined. So, when something is undefined in small area, it's still
 a good idea to have affinity towards how it's done/expected in wider
 areas. So, the request is just that - please kindly consider changing
 that behavior ;-).

 
  Peter
 

 --
 Best regards,
  Paul  mailto:pmis...@gmail.com

--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis  visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] mspgcc undefines too-many-bits shifts in weird way

[Peter Bigot]

This decision was intentional, as documented in
https://sourceforge.net/p/mspgcc/bugs/118/.  My recollection is that the
choice of how to make things consistent was informed by similar behavior in
the contemporaneous gcc for x86 or at least one other target architecture.

As you say, the behavior is undefined.  Anybody who expects any particular
behavior for this situation is confused about how C works and should take
the issue up with JTC1/SC22/WG14.

Peter


On Sun, Apr 21, 2013 at 2:35 PM, Paul Sokolovsky pmis...@gmail.com wrote:

 Hello,

 It's a known fact that shifting by more or equal bits as an integer
 type contains is undefined behavior per C standard,

 http://stackoverflow.com/questions/7214263/unexpected-behavior-of-bitwise-shifting-using-gcc
 has relevant quotes and references.

 It's less known the rules of dealing with undefined values for
 compiler writers, in this respect I find LLVM's description insightful:
 http://llvm.org/docs/LangRef.html#undefined-values . Summing up, it
 says that result of most of the expressions involving undefined value
 is also undefined.

 Finally, it's known why C standard has it like that: because rules
 various CPUs use for such shifts at *runtime* vary, so *runtime* code
 should not rely on them. C also doesn't define separation between
 compile-time and run-time evaluation strictly, so for it any shift by
 too many bits is undefined.

 It's all nice and good. But there's difference between undefined,
 any value and weird. Because too many bits shifts may be
 undefined in C standard, but shifts by arbitrary number of bits are
 very well defined in arithmetic - and by very definition of (unsigned)
 shift, any value shifted by more bits than available in its
 representation is 0. That's logical, that's what users know, that's
 what they expect from compiler, and well, that's how x86-gcc behaves.

 Now mspgcc:

 int v = 5;
 int main()
 {
 printf(%d\n, v + (1  16));
 }

 main:
 mov r1, r4
 add #2, r4
 mov v, r15
 add #1, r15
 pushr15
 push#.LC0
 call#printf
 add #4, r1


 So, msp430-gcc just masks out higher bits of shift count, and in this
 case leaves original value intact. Which turns term ((1  BITS) - 1),
 which is common to do BITS-modular arithmetic, and would be expected to
 just optimize out in case of a full type, into an expression killer with
 infinite loops, etc. ensuing.


 --
 Best regards,
  Paul  mailto:pmis...@gmail.com


 --
 Precog is a next-generation analytics platform capable of advanced
 analytics on semi-structured data. The platform includes APIs for building
 apps and a phenomenal toolset for data science. Developers can use
 our toolset for easy data analysis  visualization. Get a free account!
 http://www2.precog.com/precogplatform/slashdotnewsletter
 ___
 Mspgcc-users mailing list
 Mspgcc-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mspgcc-users

--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis  visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] Whole program optimization / Link time optimization

[Peter Bigot]

I've never tested mspgcc for any whole-program optimizations.  A common and
supported way to reduce space by eliminating unused material is
-ffunction-sections -fdata-sections during compilation and -Wl,-gc-sections
during linking.

Peter


On Sun, Apr 21, 2013 at 8:13 PM, Wayne Uroda w.ur...@gmail.com wrote:

 Hi,

 Can anybody comment on LTO or WPO’s effect on optimizing for space  - I
 have run out of flash memory and would rather not refactor my code at the
 moment. I only need 10 more bytes or so, for today at least... Yes it’s not
 ideal, such is life.

 I am using mspgcc 20120406-p20120911 and when I pass `–flto` in both the
 compilation and link stages it compiles fine but the linker complains
 “unrecognized option '-plugin'”. I assume LTO isn’t supported at this time?

 So then I skipped intermediate .o files altogether and used the following
 command:
 msp430-gcc -mmcu=msp430f233 -Os -Wall -Werror -o Coyote.elf all c files

 I get the expected message that my code does not fit.

 Using –fwhole-program:
 msp430-gcc -mmcu=msp430f233 -Os -Wall -Werror -fwhole-program -o
 Coyote.elf all c files

 I get the following output:
 C:\Users\WAYNEU~1\AppData\Local\Temp\cclYmoCC.o: In function `main':
 main.c:(.init9+0x2): undefined reference to `systemDisableInterrupts'
 main.c:(.init9+0x6): undefined reference to `PlatformInit'
 main.c:(.init9+0xc): undefined reference to `systemEnableCrystalClock'
 main.c:(.init9+0x2a): undefined reference to `delay'
 main.c:(.init9+0x44): undefined reference to `delay'
 main.c:(.init9+0x5e): undefined reference to `delay'
 main.c:(.init9+0x78): undefined reference to `delay'
 main.c:(.init9+0x80): undefined reference to `delay'
 C:\Users\WAYNEU~1\AppData\Local\Temp\cclYmoCC.o:main.c:(.init9+0xa4): more
 undefined references to `delay' follow
 C:\Users\WAYNEU~1\AppData\Local\Temp\cclYmoCC.o: In function `main':
 main.c:(.init9+0xf8): undefined reference to `batteryGetStateOfCharge'
 main.c:(.init9+0x104): undefined reference to `chargeIsPresent'
 main.c:(.init9+0x118): undefined reference to `delay'
 main.c:(.init9+0x134): undefined reference to `delay'
 main.c:(.init9+0x138): undefined reference to `infomemValidate'
 main.c:(.init9+0x13c): undefined reference to `logicMainLoop'
 collect2: ld returned 1 exit status


 I then created two files, test1.c and test2.c

 test1.c:
 ---
 void test2(void);

 void test1(void)
 {
 test2();
 }

 int main()
 {
 test2();
 return 0;
 }

 ---

 test2.c:
 ---
 void test1(void);

 void test2(void)
 {
 test1();
 }

 ---

 Compiling them:
 msp430-gcc -mmcu=msp430f233 -Os -Wall -Werror -fwhole-program -o test.elf
 test1.c test2.c

 C:\Users\WAYNEU~1\AppData\Local\Temp\ccs3TYlw.o: In function `main':
 test1.c:(.init9+0x2): undefined reference to `test2'
 collect2: ld returned 1 exit status

 Have I done something wrong?

 In the meantime, I will refactor. I don’t even expect WPO/LTO to give me
 much of a space saving anyway.

 - Wayne


 --
 Precog is a next-generation analytics platform capable of advanced
 analytics on semi-structured data. The platform includes APIs for building
 apps and a phenomenal toolset for data science. Developers can use
 our toolset for easy data analysis  visualization. Get a free account!
 http://www2.precog.com/precogplatform/slashdotnewsletter
 ___
 Mspgcc-users mailing list
 Mspgcc-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mspgcc-users


--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis  visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] TinyOS timer issue when building with mspgcc4.7 with large memory model

[Peter Bigot]

For TinyOS specific issues it'd be best to start by going through TinyOS
support.  If  you can reduce the problem to a standalone C program and
report it at the SF mspgcc tracker, it'll be looked at during the normal
course of mspgcc maintenance.

Peter


On Fri, Apr 19, 2013 at 7:44 AM, Wim De Clercq w...@track4c.com wrote:

 Hello,

 I am building a TinyOS application using mspgcc 4.7.0 (20120911), with
 large memory model / 20bit support.
 I have experienced severe timer issues (wrong timers being set, causing
 crashes in the end),  which I could trace back to TinyOS library file
 VirtualizeTimerC.nc. It looks to me like a mspgcc compiler bug.
 I have no issues with my application when I build  run it with small
 memory model options, with the same tool chain.
 Here is the original piece of code in VirtualizeTimerC.nc that causes the
 failure:

   task void updateFromTimer()
   {
 /* This code supports a maximum dt of MAXINT. If min_remaining and
remaining were switched to uint32_t, and the logic changed a
little, dt's up to 2^32-1 should work (but at a slightly higher
runtime cost). */
 uint32_t now = call TimerFrom.getNow();
 int32_t min_remaining = (1UL  31) - 1; /* max int32_t */
 bool min_remaining_isset = FALSE;
 uint16_t num;

 call TimerFrom.stop();

 for (num=0; numNUM_TIMERS; num++)
   {
Timer_t* timer = m_timers[num];

if (timer-isrunning)
  {
uint32_t elapsed = now - timer-t0;
int32_t remaining = timer-dt - elapsed;

if (remaining  min_remaining)
  {
   min_remaining = remaining;
   min_remaining_isset = TRUE;
  }
  }
   }

 if (min_remaining_isset)
   {
if (min_remaining = 0)
  fireTimers(now);
else
  call TimerFrom.startOneShotAt(now, min_remaining);
   }
   }

 The failure I saw is that the variable now got corrupted inside this
 function.
 The produced assembler code of this function is as follows:

 .L893:
calla  #TransformCounterC__0__Counter__get
mov   r14, r8
mov   r15, r9
and#-17, 898
mov   #13, r14
mov.b   #0, r6
mov   #llo(2147483647), r10
mov   #lhi(2147483647), r11
mov   #0, r15
 .L959:
mov   r15, r7
rlam   #1, r7
mov   r15, r13
rlam   #3, r13
addr13, r7
adda  #VirtualizeTimerC__0__m_timers, r7
bit.b   #2, 8(r7)
jeq .L957
mov   r8, r12
mov   r9, r13
sub @r7, r12
subc   2(r7), r13
mov   4+2(r7), r8
mov   4(r7), r7
sub r12, r7
subc   r13, r8
mov   r7, r12
mov   r8, r13
cmp   r11, r13
jl .L1173
jne .L957
cmp   r10, r7
jhs  .L957
 .L1173:
mov   r12, r10
mov   r13, r11
mov.b   #1, r6
 .L957:
add#1, r15
add#-1, r14
jne .L959
cmp.b#0, r6
jne 1f
bra #.L884
 1:

cmp   #0, r11
jl .L1208
cmp   #1, r11
jge .L960
cmp   #1, r10
jhs  .L960
 .L1208:
mov   r8, r14
mov   r9, r15
calla  #VirtualizeTimerC__0__fireTimers
bra #.L884
 .L960:
 ...more code...

 At label L893, the value of variable now is stored in registers r8 and
 r9.
 Later on, now is used as a parameter to call function fireTimers (label
 L1208), by moving r8 and r9 to r14 and r15 respectively.
 However, from the code in between, you can see that register r8 is
 overwritten (and not restored afterwards), while now is nowhere changed
 in the C-code.

 I managed to avoid the problem by changing statement:

 int32_t min_remaining = (1UL  31) - 1; /* max int32_t */

 to:

 volatile int32_t min_remaining = (1UL  31) - 1; /* max int32_t */

 so, just adding the volatile keyword.
 Doing so, resulted in following assembler code:

 .L893:
calla  #TransformCounterC__0__Counter__get
mov   r14, r10
mov   r15, r11
mov   #llo(2147483647), 

Re: [Mspgcc-users] error: __delay_cycles argument too large

[Peter Bigot]

Somebody else will have to help with that; I don't know how each
distribution manages updates.


On Thu, Apr 11, 2013 at 5:51 AM, Dean Chester dean.g.ches...@gmail.comwrote:

 How would I go about updating? I use OS X Lion, and can't remember how I
 actually installed it whether I built it from source or installed via
 macports.

 Would it be wise just to remove the msp430 stuff completely and then
 reinstall? If so build from scratch or install via macports?


 On Thu, Apr 11, 2013 at 11:39 AM, Peter Bigot big...@acm.org wrote:

 Update your mspgcc to the current stable release.  Outdated versions
 couldn't handle delays larger than 65535; current ones accept a 32-bit
 cycle count.

 If you can't update, the workaround is to wrap the intrinsic in a loop so
 the duration does not exceed 65535.


 On Thu, Apr 11, 2013 at 5:33 AM, Dean Chester 
 dean.g.ches...@gmail.comwrote:

 Hi,

 I keep getting this error when I compile some code. The line looks like:

 __delay_cycles(80);

 If I was to compile with code composer studio it wouldn't raise an error
 so
 why does MSP430-GCC raise an issue? What work arounds can I use to get
 around this problem?

 TIA,

 Dean


 --
 Precog is a next-generation analytics platform capable of advanced
 analytics on semi-structured data. The platform includes APIs for
 building
 apps and a phenomenal toolset for data science. Developers can use
 our toolset for easy data analysis  visualization. Get a free account!
 http://www2.precog.com/precogplatform/slashdotnewsletter
 ___
 Mspgcc-users mailing list
 Mspgcc-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mspgcc-users




--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis  visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] MPS430-gcc on Mac...

[Peter Bigot]

On Thu, Mar 28, 2013 at 2:51 AM, William Chops Westfield
wes...@mac.comwrote:

 On Mar 27, 2013, at 6:21 PM, Peter Bigot wrote:

  For a while there I thought it might be finding the minimum pwm value
 and eliminating the iterations up to that value from the loop--which it's
 entitled to do given what was coded.

 That's a discouraging thought.  How would I prevent this from happening?


It doesn't happen, so it's not an issue.  The way to stop it from happening
is the same way that's always used: don't use number of loop iterations as
a timing control mechanism.

Making the pwm_delay loop counter volatile resulted in the avr compiler
 (which is actually based on 4.6.2) generating the more obvious code, but
 the msp430 code stayed obscure.


 Binary searching through the optimization options…
   -fno-ivopts turns this off for the avr compiler, but not for msp430.
   -fno-tree-loop-optimize turns this off for both avr and msp430.

 the only somewhat readable description I found of just what
 -ftree-loop-optimize is likely to do is here:
 http://gcc.gnu.org/onlinedocs/gccint/Tree-SSA-passes.html , and it
 implies that it does rather a lot of things that are generally a good idea.
  Although in this case it definitely ends up producing slower and bigger
 code.

 Ah, well.  Thanks for your help; I mostly wanted confirmation that I
 wasn't using some known buggy version of the compiler before trying to
 delve too deeply into what was going on.

 Does this warrant a bug for the resulting poorer-than-possible
 optimization?


No.  Failure to be optimal is not wrong.



 Thanks
 Bill W


--
Own the Future-Intelreg; Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest.
Compete for recognition, cash, and the chance to get your game 
on Steam. $5K grand prize plus 10 genre and skill prizes. 
Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] MPS430-gcc on Mac...

[Peter Bigot]

William: Attachments don't work so well on mailing lists; I can't find it
anywhere, and your excerpt is far too opaque to see what's going on
(led1_off; apparently hides either a function call or an assignment
statement of some form, but I have no clue what it does or how the data
objects it accesses are declared).  Please do open a ticket at
https://sourceforge.net/p/mspgcc/bugs/ explaining what you did (compile
command), what you saw, and what you expected to see.  Attach the complete
standalone example  there.  Thanks.

Eric: -mcpu, -mmpy, and -mivcnt are the primitive options that control all
MCU-specific aspects of code generation.  -mmcu is simply a key that is
used by an msp430mcu specs script to select the correct set of those
options for a specific MCU.

-mmemory-model is a similar helper interface that identifies a specific
combinations of -msr20, -mc20, -md20, -ma20 which are the primitive options
controlling all memory-model aspects of code generation.

So yes, -mcpu=430 should work, and it is the appropriate technique when
building code that is not specific to a particular processor (it's also
unnecessary, since it's the default; you may want to use -mcpu=430x,
though).  You can see the standard set of primitive combinations by using:

msp430-gcc -print-multi-lib

A standard msp430-libc installation will include archive files optimized
for each of those cases.  There are other combinations but experimentation
showed it was not worth applying them to msp430-libc.

Peter

On Wed, Mar 27, 2013 at 1:48 AM, Eric Decker cire...@gmail.com wrote:

 yeah that looks weird.

 I don't know how much testing -mcpu=430 has had done on it.

 All of the testing I've seen and have used myself uses -mmcu=mcu spec
  ie.

 ie

 -mmcu=msp430f1611

 or

 -mmcu=msp430f2618

 or

 -mmcu=msp430f5438a



 If that help, submit a bug report and see what Peter says about it.


 On Tue, Mar 26, 2013 at 11:36 PM, William Chops Westfield
 wes...@mac.comwrote:

   If you give me more information about what you are seeing (perhaps send
  me the code and how you are invoking the toolchain) I'll see what I can
  figure out.
 
  Sure.  I got sucked into a conversation on comparative microcontroller
  architectures, and have been providing sample code produced by various
 PIC
  compilers, avr-gcc, and I wanted to add msp430 to the conversation.  I
  happen to have a simple program that works pretty well as an example,
  except I don't understand the code produced when I add optimization.
 
  I'm using msp430-gcc -mcpu=430 -Os -c flames.c  (various substitutes
 for
  -Os; all but -O0 seem to have the same weird code.)  I've attached the
 full
  program, but the part in question is:
 
  led_all_on();
  for (pwm_delay = 128; pwm_delay !=0; pwm_delay--) {
   /*
* We have a random number in each PWM between 1 and 128
* and we're going to have 128 cycles of delay.  So each
* decremented output can only cross zero once, at which
* time we toggle the output state.
*/
   if (--pwm1 == 0) {
   led1_off;
   }
   if (--pwm2 == 0) {
   led2_off;
   }
   if (--pwm3 == 0) {
   led3_off;
   }
 
  Which produces:
 
38:   b0 12 00 00 call#0x ;; call to all_led_on()
3c:   45 4b   mov.b   r11,r5
3e:   75 50 80 ff add.b   #-128,  r5  ;;  WTF? 1
42:   46 8b   sub.b   r11,r6  ;;...
44:   47 8b   sub.b   r11,r7  ;;  ...
46:   48 8b   sub.b   r11,r8  ;;...
48:   49 8b   sub.b   r11,r9  ;; ...
4a:   7b 53   add.b   #-1,r11 ;r3 As==11   ;; makes
  sense if pwm1 is in r11.
4c:   02 20   jnz $+6
4e:   b0 12 00 00 call#0x ;; call to led1_off
52:   4f 46   mov.b   r6, r15
54:   4f 5b   add.b   r11,r15 ;;  WTF? 2?  It thinks
 r11
  has -1?  How?  Why?
56:   02 20   jnz $+6
58:   b0 12 00 00 call#0x ;; call to led2_off
5c:   4f 47   mov.b   r7, r15
5e:   4f 5b   add.b   r11,r15
60:   02 20   jnz $+6
62:   b0 12 00 00 call#0x ;; call to led3_off
 
  The unoptimized code looks fine, if … unoptimized (size/speed wise,
  anyway):
 
5a:   b0 12 00 00 call#0x ;; call to all_led_on()
5e:   f4 40 80 ff mov.b   #-128,  -4(r4)
62:   fc ff
64:   25 3c   jmp $+76
66:   f4 53 f6 ff add.b   #-1,-10(r4)   ;; add to stack
 variable
6a:   c4 93 f6 ff tst.b   -10(r4) ;0xfff6(r4)  ;; check for zero
  (unneeded.)
6e:   02 20   jnz $+6
70:   b0 12 00 00 call#0x
74:   f4 53 f7 ff add.b   

Re: [Mspgcc-users] MPS430-gcc on Mac...

[Peter Bigot]

Eric forwarded the example to me and I was able to build it, so:

First, WTF1 is apparently gcc attempting to redefine zero for the body of
the loop to be relative to the induction variable.  You'd have to do the
algebra to figure out if it's equivalent to the expressions in the code,
but it's outside the loop, so doesn't appear to be a primary issue in
optimization.

For WTF2, is the issue simply that it doesn't make sense on examination, or
is the code actually wrong?  If it's wrong, please do reduce it so that
fact is clear and file a bug report.  If it functions as specified but just
looks weird, well, I note that the optimized code appears smaller by two
words than the unoptimized code for each PWM test so on the surface mspgcc
is doing what you asked.  Best to figure out why gcc might have chosen to
do WTF1, if that's actually relevant.

You'd probably also get a more valid comparison across architectures if you
used something like what's below instead of a call to an external function
which GCC may assume has a pretty high cost, thus changing the parameters
it uses during optimization.  Also make sure you're using the same version
of gcc, since the bulk of that optimization is being done by the middle-end
and is mostly independent of target-specific parameters.

Peter

extern volatile unsigned  int P4OUT;
#define led_all_on(a) P4OUT |= 0x1F;
#define led1_on  P4OUT |= 0x01;
#define led1_off  P4OUT = ~0x01;
#define led2_on  P4OUT |= 0x02;
#define led2_off  P4OUT = ~0x02;
#define led3_on  P4OUT |= 0x04;
#define led3_off  P4OUT = ~0x04;
#define led4_on  P4OUT |= 0x08;
#define led4_off  P4OUT = ~0x08;
#define led5_on  P4OUT |= 0x10;
#define led5_off  P4OUT = ~0x10;


On Wed, Mar 27, 2013 at 6:17 AM, Peter Bigot big...@acm.org wrote:

 William: Attachments don't work so well on mailing lists; I can't find it
 anywhere, and your excerpt is far too opaque to see what's going on
 (led1_off; apparently hides either a function call or an assignment
 statement of some form, but I have no clue what it does or how the data
 objects it accesses are declared).  Please do open a ticket at
 https://sourceforge.net/p/mspgcc/bugs/ explaining what you did (compile
 command), what you saw, and what you expected to see.  Attach the complete
 standalone example  there.  Thanks.

 Eric: -mcpu, -mmpy, and -mivcnt are the primitive options that control all
 MCU-specific aspects of code generation.  -mmcu is simply a key that is
 used by an msp430mcu specs script to select the correct set of those
 options for a specific MCU.

 -mmemory-model is a similar helper interface that identifies a specific
 combinations of -msr20, -mc20, -md20, -ma20 which are the primitive options
 controlling all memory-model aspects of code generation.

 So yes, -mcpu=430 should work, and it is the appropriate technique when
 building code that is not specific to a particular processor (it's also
 unnecessary, since it's the default; you may want to use -mcpu=430x,
 though).  You can see the standard set of primitive combinations by using:

 msp430-gcc -print-multi-lib

 A standard msp430-libc installation will include archive files optimized
 for each of those cases.  There are other combinations but experimentation
 showed it was not worth applying them to msp430-libc.

 Peter

 On Wed, Mar 27, 2013 at 1:48 AM, Eric Decker cire...@gmail.com wrote:

 yeah that looks weird.

 I don't know how much testing -mcpu=430 has had done on it.

 All of the testing I've seen and have used myself uses -mmcu=mcu spec
  ie.

 ie

 -mmcu=msp430f1611

 or

 -mmcu=msp430f2618

 or

 -mmcu=msp430f5438a



 If that help, submit a bug report and see what Peter says about it.


 On Tue, Mar 26, 2013 at 11:36 PM, William Chops Westfield
 wes...@mac.comwrote:

   If you give me more information about what you are seeing (perhaps
 send
  me the code and how you are invoking the toolchain) I'll see what I can
  figure out.
 
  Sure.  I got sucked into a conversation on comparative microcontroller
  architectures, and have been providing sample code produced by various
 PIC
  compilers, avr-gcc, and I wanted to add msp430 to the conversation.  I
  happen to have a simple program that works pretty well as an example,
  except I don't understand the code produced when I add optimization.
 
  I'm using msp430-gcc -mcpu=430 -Os -c flames.c  (various substitutes
 for
  -Os; all but -O0 seem to have the same weird code.)  I've attached the
 full
  program, but the part in question is:
 
  led_all_on();
  for (pwm_delay = 128; pwm_delay !=0; pwm_delay--) {
   /*
* We have a random number in each PWM between 1 and 128
* and we're going to have 128 cycles of delay.  So each
* decremented output can only cross zero once, at which
* time we toggle the output state.
*/
   if (--pwm1 == 0) {
   led1_off;
   }
   if (--pwm2

Re: [Mspgcc-users] MPS430-gcc on Mac...

[Peter Bigot]

I did stare at it a little longer this morning and decided it probably did
make sense, though I didn't spend enough time to try to prove it.  For a
while there I thought it might be finding the minimum pwm value and
eliminating the iterations up to that value from the loop--which it's
entitled to do given what was coded.  But at the end I think the primary
effect is it reduces the loop to a single changing variable, which on some
architectures might enable vectorized operations in a subsequent phase of
optimization, or as you suggest simply work better on more common targets.

Or maybe that's not what it's doing.  As a philosophico-technical viewpoint
I don't find it useful to speculate about why or how modern compilers
generate the code that they do, and especially not why they don't generate
something else, unless there's clear evidence what they're doing is wrong
(as opposed to just not what I'd have expected).  Optimization techniques
these days use advanced number theory that I have never studied and don't
need to know.  See, for example, http://www.cloog.org/, which is used in
gcc to do loop optimization through something called scanning
Z-polyhedra.  These techniques do pretty amazing things with pretty
horrible inputs, making my life as a developer much nicer: I can code what
I mean, and let the tools figure out the best way to make it happen.  If a
consequence is that they make simple loops look bizarre but still correct
and at a cost no more than the obvious alternative without making me fine
tune back-end--specific cost vectors--hey, I can live with that.

Peter

On Wed, Mar 27, 2013 at 7:48 PM, William Chops Westfield
wes...@mac.comwrote:

 On Mar 27, 2013, at 4:47 AM, Peter Bigot wrote:

   is the code actually wrong?

 Good question.  I can't tell just by looking at it, you can't tell either.
 I don't think that is a good thing, especially since there is an obvious
 translation that looks just as efficient.   I'll have to analyze more…

 It does look like a newer avr-gcc creates very similar code, so it is
 probably some gcc-level optimization rather than something msp430 specific.
   (Terrific; I'll try to see which incomprehensibly-defined -f option
 controls this optimization.  Sigh.)

 It looks like it's doing
  // mysteriously initialize temp
  for() {
if (pwmx + temp  0)
  led_xxx_off;
:
temp = temp + -1;
  }

 which will be correct, and probably even better on a truly RISCy CPU (no
 immediate math, no decrement instruction), but it sure looks weird with a
 typical microcontroller instruction set.

 BillW


--
Own the Future-Intelreg; Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest.
Compete for recognition, cash, and the chance to get your game 
on Steam. $5K grand prize plus 10 genre and skill prizes. 
Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

[Mspgcc-users] new MSP430 MCU support available; FRAM support broken

[Peter Bigot]

Release 20130321 of msp430mcu has been made available in the git repository
and in the files area.  This adds about a dozen new chips including some
nice enhancements to the G2xx series.

However, TI changed where the vector table is placed on FRAM chips, and I
only noticed half of what was done.  As a consequence, msp430mcu 20130321
will mis-place interrupt vectors on FRAM chips.

I've opened https://sourceforge.net/p/mspgcc/bugs/349/ to record this
issue.  The fix will require changes to both msp430mcu and gcc.  I don't
currently have plans to work this.

At this time I'm not going to pull the msp430mcu release, but packagers
should absolutely NOT update to msp430mcu 20130321.  Adventurous users may
wish to do so, but recognize that FRAM chips will not work properly and, in
fact, the old bug overwriting BSL and JTAG passwords would come back,
possibly bricking your devices, if you do.

Peter
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users