Too bad; I'd hoped it was the watchdog. Some thoughts:
Use msp430-objdump (or readelf) to compare the working and non-working
versions. "readelf -e" will tell you the addresses for each section. I
can't tell you what they should look like, but where they're different, dig
into it and figure out why.
Use msp430-objdump -d to disassemble the two programs, and make sure the
startup code looks right.
If C++ works with mspgcc, it's purely by chance. I don't use it, I don't
test it. Exceptions and virtual functions are likely to fail in odd ways.
C++ support will happen eventually, but for now you're better off sticking
with C.
You're using a lot more flags than I do, and some choices look odd (e.g.,
-Wa without a following option that's passed to the assembler). There are
anomalies in what you've chosen; read the gcc man page and review whether
you really need them. Get rid of as many -f* ones as you can, at least
while isolating the problem. Eliminate all linker flags except -mmcu. The
-D flags to the assembler look bizarre too. If you're really redefining
__reset_vector (which would replace the entire C runtime startup
infrastructure), you're on your own.
In short, look closely at everything you're doing, and read the
documentation and the source (at least the headers and linker scripts) to
make sure you understand what effect each flag and code construct has.
This is about all the help I can provide at this time. Good luck.
Peter
On Sun, Aug 21, 2011 at 6:34 AM, aliko <ali.tli...@gmail.com> wrote:
> Thank you very much Peter for your promptest response!
> Target is our custom board and chip msp430f1611 as mentioned in subject.
> When I build with latest tool mspgcc-20110716 Olimex says that data
> addresses unavalable in the device and if I write it to device
> nevertheless it's works fine for the first time. By the way, I removed
> all routines that could write to flash, but after several power reset
> cycles program stops working right and seems became broken because it
> outputs on the LCD screen of device garbage. Unfortunateley Olimex does
> not says which exactly addresses it thinks unavailable in the device.
> Though when I load .elf through gdb, it (gdb) not tells me anything
> about address problems but the story repeats.
> I've tryed to read programm and data memory by Olimex and saved it to
> file immediatley after reprogramming device while it works good and
> compare it with data in device when it became broken and Olimex says
> that the data in flash the same.
>
> Now I'll copy flags from my makefile:
> the g++ flags are
> -mmcu=msp430x1611 -MD -Wa -fomit-frame-pointer -fno-exceptions
> -fno-rtti -ffunction-sections -fdata-sections -funsigned-bitfields
> -fshort-enums -fno-threadsafe-statics -std=c++0x -Wall -Wimplicit
> -Wcast-align -Wpointer-arith -Wshadow -Wcast-qual -Wcast-align
> -Wredundant-decls -pedantic -save-temps
> assembler flags:
> -D_GNU_ASSEMBLER_ -DL_reset_vector__ -DL_ctors
> ld flags:
> -mmcu=msp430x1611,--sort-common,--cref,--gc-sections
>
> I've tryed to remove --gc-sections and -fdata-sections and it makes no
> sense...
>
> PS I'm using -mdisable-watchdog and have not implemented
> __low_level_init to disable watchdog.
>
> 21.08.2011 14:58, Peter Bigot пишет:
> > Based on "the firmware became broken after power-cycling" I have no idea
> > what the problem is. In the past, another poster here has suggested
> > http://www.chiark.greenend.org.uk/~sgtatham/bugs.html.
> >
> > Relevant information would include what hardware you're targeting
> > (launchpad? ez430-rf5200? other? which MSP430 chip?), how you're
> building
> > the application (complete compiler and linker commands), what the program
> > does when it works (does it write flash memory?), what it does when it
> > doesn't work, what addresses Olimex says are there that you don't think
> > should be, and whether the data it shows looks meaningful. Use
> > msp430-objdump to examine the differences between mspgcc4 and
> > mspgcc-20110716 built executables.
> >
> > Peter
>
>
>
>
> ------------------------------------------------------------------------------
> Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
> user administration capabilities and model configuration. Take
> the hassle out of deploying and managing Subversion and the
> tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
> _______________________________________________
> Mspgcc-users mailing list
> Mspgcc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
>
------------------------------------------------------------------------------
Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
user administration capabilities and model configuration. Take
the hassle out of deploying and managing Subversion and the
tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
