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 sufficient information to reproduce the
issue; you offered me an eclipse project and the opportunity to extract the
relevant pieces myself because you did not have time to reduce the problem;
and I declined to donate several hours of professional support to you.
It was in no way silently ignored, and I take offense at that accusation.
Since you've suggested this is the same problem, in an attempt to help Nils
I took 15 minutes to incorporate the excerpt from the ticket that is now
#342 into a simple harness, and running it with mspgcc 20120406 and
20120911 produces the same result as running the program under gcc on a
Fedora 17 host. So whatever the problem in #342 may be, it's either not
with mspgcc or it's too subtle to reproduce with the information provided.
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, but first keep in mind
the following two pieces of information, mentioned several times in the
archives of this list (which should always be reviewed before asking for
help: see http://www.catb.org/esr/faqs/smart-questions.html):
* large memory model is not robust, and caused a lot of difficulty due to
problems described at
https://sourceforge.net/apps/mediawiki/mspgcc/index.php?title=Gcc47:20-Bit_Design#Warning_about_Mixing_Memory_Models.
I'm not sure whether there are any known problems with it beyond
https://sourceforge.net/p/mspgcc/bugs/345/. I don't personally large
memory mode. I am unaware of any issues with medium memory mode.
* msp430-gdb is out of date and unmaintained. If it tells you anything
helpful, that's great. If it lies to you, don't be surprised. If it tells
you:
(gdb) x/bx 0x1c00
0x1c00: 0x00
0x1c01: 0x04
0x1c02: 0x00
well, maybe it's so, maybe it isn't. Use mspdebug to dump the memory as
bytes; mspdebug normally tells the truth. If the data is not what you
expected, look at the generated assembly to see how it got that way. If
you still think there's a problem, file a ticket, but provide enough
information that I can help you.
Peter
> Adding static qualifier fixes the issue,
> although I am convinced there is a bug in mcpgcc compiler.
> I experienced the same problem on msp430-gcc (GCC) 4.7.0 20120322
>
> WRT 20-bit support in msp430-gcc (GCC) 4.7.0 20120322 my code seems to work
> OK for me so far.
> I am targeting MSP430F2417 and MSP430F2618 with -mmemory-model=large.
>
> Good luck
> Dan
> >-----Original Message-----
> >From: Nils Faerber [mailto:nils.faer...@kernelconcepts.de]
> >Sent: 15 March 2013 01:13
> >To: mspgcc-users@lists.sourceforge.net
> >Subject: [Mspgcc-users] Weird behavior - 'const' changes byte order!?
> >
> >Hello!
> >I am just starting my travel through MSP and GCC wonderland, so excuse me
> if
> >this is a really dumb question...
> >
> >I have just compiled my own toolchain (running Debian Linux "unstable"
> >on amd64) and am now using
> > msp430-gcc (GCC) 4.7.0 20120322 (mspgcc dev 20120911) on a
> >msp430f5438a (-mmcu=msp430f5438a).
> >
> >I have a small program which I translate using "-mmemory-model=medium".
> >Inside the program I have the following (global) declaration:
> >
> >#define LCD_CLEAR_CMD 0x04
> >static unsigned char LCD_CLEAR_COMMAND[] = {LCD_CLEAR_CMD, 0x00, 0x00};
> >
> >When I compile it this way, attach GDB to mspdebug then I can see that
> >LCD_CLEAR_COMMAND ends up at address 0x1c00 - fine. BUT at 0x1c00 I find
> >the following content:
> >
> >(gdb) x/bx 0x1c00
> >0x1c00: 0x00
> >0x1c01: 0x04
> >0x1c02: 0x00
> >
> >which is wrong, it should be 0x04 0x00 0x00 !?
> >
> >If I declare it as const:
> >
> >static const unsigned char LCD_CLEAR_COMMAND[] = {LCD_CLEAR_CMD, 0x00,
> >0x00};
> >
> >it ends up in another segment at 0x62f6 and the content is correct:
> >
> >(gdb) x/bx 0x62f6
> >0x62f6 <LCD_CLEAR_COMMAND>: 0x04
> >0x62f7 <LCD_CLEAR_COMMAND+1>: 0x00
> >0x62f8 <LCD_CLEAR_COMMAND+2>: 0x00
> >
> >What is going on here? Or am I doing something wrong or unexpected here?
> >Well, defining it const might make sense anyway, but I would expect the
> other
> >way at least to work too, even if suboptimal.
> >
> >
> >Another severe issue is that as soon as I compile the application to use
> >20 bit data (-msd20) or use -mmemory-model=large the controller enters an
> >uncontrollable state after reset, i.e. mspdebug wrongly reports a blown
> fuse and
> >it can be recovered pressing and holding the reset button on the msp board
> and
> >releasing the button as soon as mspdebug tries to open the device.
> >
> >Sooner or later I will have to use the 20 bit data area - as you can guess
> from the
> >above command I am using a LCD and need to store fonts and some bitmaps...
> >
> >Did anyone else already successfully use 20 bit data with mspgcc?
> >
> >I should probably also mention that "large" did work in the beginning as
> long as
> >the application was *really* small. When it grew a little (I am now at #
> msp430-
> >size gccfwtest.elf
> > text data bss dec hex filename
> > 1845 0 1348 3193 c79 gccfwtest.elf
> >) it started to go haywire.
> >
> >
> >Strange strange...
> >
> >Cheers
> > nils
> >
> >--
> >kernel concepts GmbH Tel: +49-271-771091-12
> >Sieghuetter Hauptweg 48
> >D-57072 Siegen Mob: +49-176-21024535
> >http://www.kernelconcepts.de
> >
>
> >---------------------------------------------------------------------------
> ---
> >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
>
>
>
> ------------------------------------------------------------------------------
> 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
>
------------------------------------------------------------------------------
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
