Could you post your interrupt code (C) and the resulting assembler?
It's hard to debug problems without seeing those...
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org!
Bob von Knobloch writes:
> Now the linker doesn't want to play with me - it cannot find the
> "msp430g2231.ld" link file. Curious because the compiler fids "msp430.h"
> in the same directory.
Add "-v" to your gcc line, it will show you more info on where it's
searching for things. Note that t
This has come up before, and here's what's going on... the new
msp430-elf-gcc includes all the code required by the standard, partly
because... well, standards... and partly so that the testsuite can test
everything. The old msp-gcc made lots of assumptions about how the
compiler would actually b
Lev Serebryakov writes:
> Was support for Insight TK frontend dropped? I could not find
> "gdbtk" in sources.
Yes, gdbtk was dropped from upstream in 2013. It's a separate repo if
you want to try to use it; we did the work to integrate it for our 2014
release but it was a lot of work, so we d
> Agenda VR3 (did you remember this very first Linuix-based PDA with
> MIPS-based CPU?)
Yup, I was involved with the project way back then.
> Could you please clear situation with debugging (in separate thread in
> mailing list)?
Sorry, that's a TI question, they provide the DLLs and SOs for t
> To be honest, your (RedHat + TI) way is worst possible one :-(
Worst for your purposes, perhaps. We just have a different goal - a
turnkey custom collection that "just works" for our customers. That
means we normally include things that wouldn't be included in a system
package.
What you wa
> Yep, it works, modulo DESTDIR problems, which could be easily patched.
We've always used a separate --prefix for each release (typically
/opt/redhat/msp430-YYMMDD/) so we wouldn't notice.
> I'm not sure, that toolchain need all these separate tcl and tk
> stuff (system already has them!), b
Two questions:
1. Are you cross-building a compiler? I.e. is the host you're
building *on* different than the host (not target, which is msp430)
you're building *for*? (This is called a "canadian cross" and is
much more complicated than a regular cross compiler).
(one typically cro
That should be built as part of building gcc/
so you probably have a problem earlier on that you didn't see in your logs...
--
___
Mspgcc-users mailing list
Mspgcc-users@lists.
> It is clang 3.4.1, and I don't want to install gcc, if it is possible to
> avoid with some "simple" patch :)
IIRC there's an option in clang to use the old semantics (-std=gnu89).
--
__
You're probably running into a common problem with "static inline" vs
"extern inline" - the semantics of those changed with the recent C
standards, so not all compilers do the same thing. I assume you're
not using GCC?
-
> (1) Sources could not be downloaded automatically. You need browser.
> What should distributive build cluster do?
There's nothing magic about downloading the sources, just use any
command-line URL tool (wget, curl, etc):
wget
http://software-dl.ti.com/msp430/msp430_public_sw/mcu/msp430/MSPGCC
Just a request, when reporting errors against the assembler, please
give the assembler's version number, not the compiler's version
number:
$ msp430-elf-as --version
GNU assembler (GNU Binutils) 2.25.51.20150212
FWIW I've reproduced this with the FSF assembler reporte above, which
is the binutil
> Is there an option that I missed to force it to build for the non
> MSP430X memory-model?
If you specify -mmcu= when compiling, specify the same -mmcu= when
linking, else the tools don't know which libraries to use.
If that fails, add -mcpu=msp430x or -mcpu=msp430 to force the issue.
> The map file is telling me a few small functions are being linked in
> (memset, memcpy) and I assume that since the standard library wasn't built
> with -ffunction-sections or -fdata-sections that it then links the entire
> library.
-ffunction-sections affects multiple functions in the same obj
main() is not a root with gcc, start() is (defined by your linker
script), and is usually provided by crt0.o - except you told it not to
with -nodefaultlibs.
The flag you really want is -minrt, which tells gcc to encode extra
information in each object that helps the linker reduce the amount of
r
> 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 informa
> -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.
The GCC manual, chapter "Extensions to the C Language Family" section
"Function Attributes" documents the interrupt attribute:
void f () __attribute__ ((interrupt (15)));
or
void __attribute__ ((interrupt (15))) f ()
{
}
Note that the attribute tells gcc
> Thanks. I see that arm-elf-gcc includes newlib in the compiler
> package. I’m able to build binutils just fine, unfortunately gcc has
> some errors with clang (stray ‘-static-libgcc’ options that are not
> supported by clang).
While a native GCC build is likely to be built with alternate
compil
> 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?
http://processors.wiki.ti.com/index.php/CIO_System_Call_Protocol
--
> Ah, yes, sorry. What I meant was can msp430-elf-gcc be built without
> newlib? I wanted to create a separate package for newlib.
Typically, the gcc runtime (libgcc) needs to know what the "usual"
runtime will be, as some routines in libgcc may need to call C library
functions. The usual way to
> 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?
--
Open source business process management suite built on
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...
> 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 "
> Can you elaborate on "branch-to-self" opcode?
Any branch opcode that branches to itself, i.e. a one-opcode infinite
loop.
1: BR #1b
This also works with any indirect or conditional branch, as long as
the target of the branch is the address of the branch opcode. Here's
the code in t
> 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())
newlib uses either write() or _write() depending on whic
> That doesn't really help the rest of us, though.
Yup, I've complained to TI about that. I'll bring it up again.
> 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.
Could you elabora
> Is this documented? How can I write drivers to this standard?
That's the catch. It's not documented. I have a sample
implementation from TI that I used (with permission) to write the
simulator/libgloss code.
In general, though, the target side works like this: fill up a
"command buffer" at
> 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. CIO doesn't have exit()
> You need to be using msp430-elf-gcc for that feature, not mspgcc as
Right, as previously agreed on, we're using "msp430-foo" for the
non-RH tools, and "msp430-elf-foo" for the RH tools.
--
Learn Graph Databases - Downl
> 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 simul
> 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 h
Could you try the gdb from the FSF's source tree? It's version 7.7
and has the RH simulator in it. However, I don't think the profiling
results from the RH simulator will be useful to you if you want
cycle-accurate counts, but it will show you every single instruction
being executed.
Also, ther
Sorry, I don't know anything about CCS, just about the gnu tools
themselves. You'll have to wait for someone from TI to reply.
--
Time is money. Stop wasting it! Get your web API in 5 minutes.
www.restlet.com/download
ht
The right way to enable large model is to use -mlarge
If that causes problems, we'd need to know more about the problem to
try to diagnose it.
Note that adding -mlarge means that *all* objects and libraries must
be recompiled with -mlarge, you can't mix and match large and small
model.
> (1) Is newlib-nano supported?
> (2) Is C++ supported?
Tricky questions. Technically, if you don't have a support contract
with someone, the answer is "no" because, well, because ;-)
But the answers you probably want are...
I haven't tried newlib-nano but there's no reason why it wouldn't w
> DD> so yeah, it's probably what people want. The only exception would be,
> DD> for example, if you were packaging for a distro and you want to
> DD> support upgrading. In those cases, it's better for the packaging if
> DD> the package version numbers match the upstream version numbers, which
There's nothing special about the msp430-elf tools; you cross-build
them just like any other embedded toolchain. If you can, use the
latest versions of gcc, binutils, gdb, and newlib (which is typically
the development head if there hasn't been a recent release). If you
download the TI build of
> I see. I guess to me a "syscall interface" implies something other
> than a normal C function call to a function that's linked with the
> caller.
It does to me too. The *implementation* of those standard C functions
may involve some sort of interface that's known to the
debugger/simulator as
> 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?
It *is* called like a normal C function. You really do just link
libgloss.a (or your equivalent) in with your app like you would any
o
> So I'm guessing DJ implemented a default hardware I/O implementation in
> libgloss
> that uses the CIO infrastructure (no idea what that is, but I'm guessing it
> uses
> the JTAG Mailbox system somehow to talk with the debugger host? in which case
> I'd love to play with it that... assuming
> 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
> > It uses the TI CIO interface.
>
> Interesting; is there any public documentation on how to use that?
Not that I know of.
> An option to build MSP430 newlib with the standard system interface
> would be even better.
I don't know of a "standard" interface. Each chip I've done has done
somet
> * 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
Hmmm... I was under the impression that there were toplevel
chip-specific scripts that included the sub-scri
> On a different note, i was wondering if anybody on the list have the same
> problem as me, using the TI pre-compiled binaries for the MSP430 (the RH
> port, downloaded from TI web site), the msp430-elf-gdb.exe , works Ok with
> 430 and 430X but using only small memory model for a 430X. If you s
> OK, if it is /that/ much space then it's a completely different
> matter. I thought we were just talking about clearing the bss and
> setting the initialised data, which should just be a couple of
> short simple loops.
Worst case startup is around 400 bytes, but once you start optimizing,
y
> Great news and thank you for the update, is it possible to throw
> somewhere the Windows binaries? I think it is time for fresh windows
> binaries, the last one was back in December.
Sorry, I don't work for TI, so I can't make them do a release or say
anything about their schedule or intent
> Is it the intent to fully support C++ in this port, inclusive of
> static initializers and exceptions?
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.
> (Exclusive of features that require host sup
> 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
> Even if you have the smallest mps430 with 512 bytes flash, it does
> not matter if your program is 24 bytes or 511 bytes - all that
> matters is that it fits in the chip you have.
If the startup is more than 512 bytes, it matters a lot. If you only
have 512 bytees of code space and you discove
I'm writing this document to collect some of the current/new knowledge
on how to minimize the flash/rom size needed for MSP430 applications,
using the new msp430-elf (FSF/Red Hat) tools. I'll keep a copy at
http://people.redhat.com/~dj/msp430/size-optimizations.html
This document has two purposes
In general (i.e. untested ;) you'd add a linker script snippet like
this:
section_TAO 0xC400 : {
*(.myfuncsec_TAO)
}
Then tag your function with a section attribute:
static void __interrupt __attribute__((section(".myfuncsec_TAO")))
Timer0_A0_alter(void)
{
}
The key here is that you can cha
> 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.
Also, it's useful to have parallel
The typical case for tiny programs is that the startup/shutdown code,
which normally has to be robust enough to handle all language
extensions, is vastly bigger than the program itself. There are a
couple of things you can manually do to trim out bits you know you
don't need, like custom crt0.S (
Some quick answers where available...
> and probably not MSP430 specific, with -Os "static inline
> functions()" are not inlined, i also tried adding
> __attribute__((always_inline)) but it did not seem to have an effect
> in a quick test.
Please try "extern inline functions()" instead. There w
I ran the Makefile in your zip using the latest FSF builds and
it... just worked :-P
Which version of gcc are you using? I.e. "msp430-elf-gcc -v" ?
--
Sponsored by Intel(R) XDK
Develop, test and display web and hybrid
The _47 implies it's trying to shift by 47 bits (not registers).
However, the "slll" variant is for longs (32-bit) and the helpers only
go up to 15 bits (after that, it's supposed to use the variable-count
helper instead).
Maybe that will help you get a sharable test case, because that's what
I n
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 us
> 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 inli
> For small targets like this, it is common to compile C++ with "-fno-rtti
True, but even the "static objects must be initialized" code adds some
runtime space/time cost. It's not much, but the smallest MSP430's
don't have much rom/ram to spare.
-
> Okay I'll ask... Is there FORTRAN support?
No! :-)
(but it might work anyway, I haven't tested)
> Now on to my real question...
>
> how much real world testing has been done? Has the output been put
> onto real msp430 chips?
I'm testing against our simulator (it's in the gdb repo). I'v
Just FYI, the port is now "official" as it's been approved and checked
in to the FSF repository!
http://gcc.gnu.org/ml/gcc/2013-09/msg00107.html
I have some follow-up patches that will get commited "shortly" too,
though.
--
> Is c++ an officially supported aspect of the port?
I'm going to conditionally say "yes" because, while I build and test
C++, I know there are some language features of C I took advantage of
to get far (20-bit) addressing, that C++ simply doesn't support. So
I'm not sure how well C++ will work
Typically, you have "extern ..." in all but one source file, and just
"..." in one source file where that symbol is defined.
Saying "extern int foo;" means "I expect some other module to have foo."
Saying "int foo;" means "I have foo."
So exactly one module needs to have foo, to avoid linker er
>And now, look at official ARM arm-gcc building script: it builds
> gcc twice, it copy first copy of gcc somewhere, to remove later, it
> wants to find some linux-specific headers in process, etc, etc,
> etc. Also, it uses
There are two parts to gcc: the compiler binaries, and the support
Speaking as an FSF maintainer (sorry, can't divulge Red Hat secrets ;),
to answer some of the technical questions...
It's our intention that the GCC ABI be compatible with the TI ABI, at
least, as best we can (If you discover an incompatibility, report it).
We've been testing for cross-linking co
67 matches
Mail list logo