Looks like changes in gcc 4.7 result in that declaration being added as a
common block declaration in the assembly, and it's not syntactically valid
since the asm statement substitutes the address whereever the name would
normally be given. Making the declaration static inhibits this invalid
It's probably been forgotten, but there is an issue with large memory model
because in this model the following is true:
sizeof(void*) != sizeof(ptrdiff_t)
See
https://sourceforge.net/apps/mediawiki/mspgcc/index.php?title=Gcc47:20-Bit_Design#mixedmode
GCC internally has a hard-coded
It's not clearly wrong if the type of
gSlaTxFrame.payloadPtr[gSlaTxFrame.pos] is char (and r14 holds the current
value of word). Unlike IAR, unqualified char in mspgcc is signed.
This is consistent with how GCC treats unqualified char on most targets.
If that's not the problem, you'll need to
I traced this down to the value range propagation phase in gcc, which is a
tree optimization that occurs long before anything that's MSP430-specific.
This phase replaces the value of i8 with a constant 127 after the first
output.
So I'm gonna have to agree with Michiel that the code relies on
Or just:
memset(USBIEP0BUF, 0, EP0_MAX_PACKET_SIZE);
since the buffer is declared in the header (though as a byte, not an
array). The name with the underscore suffix is technically internal to the
mspgcc implementation; the syntax above should work with any MSP430
compiler that uses the TI
*)USBIEP0BUF)
Regards,
Mathias
On 16.02.2013 13:39, Peter Bigot wrote:
Or just:
memset(USBIEP0BUF, 0, EP0_MAX_PACKET_SIZE);
since the buffer is declared in the header (though as a byte, not an
array). The name with the
underscore suffix is technically internal to the mspgcc
In the standard linker script __bss_start gets the value of . at the start
of .bss, which immediately follows .data. .data ends with a 2-byte
alignment instruction. I don't see how __bss_start would end up at an odd
address in that situation.
Peter
On Thu, Feb 21, 2013 at 1:56 PM, Robert Henig
Because of the split memory regions in the MSP430, you need to use
-ffunction-sections and -fdata-sections along with -Wl,-gc-sections so that
each component is placed in a separate section. The linker then assigns
each component to either near or far memory.
If you don't use those options,
, EmptyF,
TBOverFlow
};
* *
*interrupt (TIMERB1_VECTOR) __TimerBCC_ISR (**void**)*
*{*
* f[TBIV 1] ();*
*}*
** **
Thnx
Dan
** **
*From:* pabi...@gmail.com [mailto:pabi...@gmail.com] *On Behalf Of *Peter
Bigot
*Sent:* 27
Apparently there is material that must go into .rodata and .data (low
memory) that exceeds the available space, causing it to overflow into
.vectors. See other message earlier this week for suggestions of how to
diagnose where things might be going wrong and how to rearrange things to
fit.
Peter
for existing
tracker items.
If you encounter problems report them here or as tracker tickets.
Peter
On Mon, Mar 4, 2013 at 6:40 AM, Peter Bigot big...@acm.org wrote:
SourceForge keeps badgering me to move the mspgcc project to their new
Allura platform, and if I don't do it manually some day it'll
On Fri, Mar 15, 2013 at 3:07 AM, Daniel Sulik d...@meta-designs.com wrote:
Hi Nils,
I think you got trapped in the same issue I found some time ago on gcc
4.6.3..
See http://sourceforge.net/p/mspgcc/bugs/342/
It got silently ignored ;-).
No, it did not.
I replied asking you to provide
12:48, schrieb Peter Bigot:
On Fri, Mar 15, 2013 at 3:07 AM, Daniel Sulik d...@meta-designs.com
With respect to Nils' problem: I also tried creating a file with the
declaration in this thread under different memory models and can see no
obvious issue. More information would be needed
On Fri, Mar 15, 2013 at 9:09 AM, Nils Faerber
nils.faer...@kernelconcepts.de wrote:
Am 15.03.2013 14:10, schrieb Peter Bigot:
If you file a tracker ticket on the SF project and attach a
self-contained and reduced reproducing example along with what you did
(exact build commands), what you
To make things consistent across the whole MSP430 product line the symbols
used to define the interrupt entrypoints no longer encode the address of
the pointer within the vector table, but rather its offset in words from
the start of the vector table. Unfortunately the preprocessor capabilities
is .LFB37?
Does the
main.c in the .file statement represent the file that the preceding
compiled/assembled code will be placed in (i.e., in main.o, in this case)?
Do interrupt functions written entirely in C require any changes?
- Original Message - From: Peter Bigot big...@acm.org
That page suggests including signal.h and using the interrupt macro.
On Tue, Mar 19, 2013 at 7:56 AM, Wayne Uroda w.ur...@gmail.com wrote:
Hi,
I just want to double check, is the interrupt syntax described here:
http://mspgcc.sourceforge.net/manual/x918.html
still modern and current? I
Ahem. Let's try that again without pressing send prematurely:
That page suggests including signal.h and using the interrupt macro.
signal.h is deprecated; its content is in legacymsp430.h and you need
to include that file to use it without getting a warning at compile time.
If you tried it, you
-4.5.3/configure --target=msp430
--enable-languages=c,c++ --prefix=/usr/local/msp430-uniarch-20110716
Thread model: single
gcc version 4.5.3 (GCC)
And I got a compiler error.
D.
On Tue, Mar 19, 2013 at 1:18 PM, Peter Bigot big...@acm.org wrote:
Ahem. Let's try that again without pressing
Generally you should use msp430-gcc as the driver since it will add
necessary additional linker flags. In this case, the simpler solution
might be to use msp430-ld directly since what it adds doesn't work.
I don't plan to investigate this but if anybody does: the issue is probably
because
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.
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
= ~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
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
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
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
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
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
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
, 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
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
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
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
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
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
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:
, 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
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
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
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
-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
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
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
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
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
: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
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
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
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.
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
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
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
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
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
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
__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
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
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
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
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
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
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
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
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
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
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
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
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
.
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
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
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
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
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
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
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
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
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
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
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
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
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
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,
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
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
; 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
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
(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
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
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.
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
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
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, 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
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
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
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
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
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 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
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,
501 - 600 of 620 matches
Mail list logo
