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 saw, and what you expected to see, I'll take a look.
Don't send any questions or code to me personally unless I've invited you
to do so, or you've contracted with me for support (which would be a
different email address).
Read ESR's "smart questions" document, and please be very accurate and
concise with what you provide. In the first email you say it failed with
medium model; in this new one you say it works with medium model and fails
with large model. If, like #342, what you provide does not allow me to
reproduce the problem in a few minutes effort I'm going to consider it a
problem with your code or environment, and I don't provide support for that
for free.
Note that I probably don't have whatever LCD hardware you're targeting, so
you'll have to make it reproducible with something that produces serial
output (via printf).
Peter
On Fri, Mar 15, 2013 at 7:42 AM, Nils Faerber <
nils.faer...@kernelconcepts.de> wrote:
> Hello Peter!
> Thanks for taking care of the problem!
>
> See more comments below...
>
> Am 15.03.2013 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, but first keep in mind
>
> Hmm... this is strange since I can reproduce this reliably - compile
> with "medium" and it works, compile using "large" and it fails.
>
> I will have a look at the map file tonight, maybe I can spot a
> difference in the output addresses.
>
> If you allow I could also tar my current code together and send it to
> you? It is a pretty simple test program... I do not expect you to fix it
> of course ;) I just thought it might be easier so that we have the same
> code base and maybe you can more easily spot the difference (and donÄt
> have to write test code youself).
>
> > 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.
>
> Well, medium works for me, at least concerning the application running
> or not issue. But I will need large soon I guess, once I include static
> font bitmaps etc.
>
> > * 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.
>
> Well, while this might also be true, i.e. mspgdb lying, my second proof
> for the wring data is that as soon as I see the wrong data the attached
> LCD also does not perform the expected function, as soon as the data is
> reported correctly the LCD does what it should.
> So in this case I assume GDB is telling the truth here.
>
> > 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
> > <mailto:nils.faer...@kernelconcepts.de>]
> > >Sent: 15 March 2013 01:13
> > >To: mspgcc-users@lists.sourceforge.net
> > <mailto: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
> > <mailto: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
> > <mailto:Mspgcc-users@lists.sourceforge.net>
> > https://lists.sourceforge.net/lists/listinfo/mspgcc-users
> >
> >
>
>
> Viele Grüße
> nils faerber
>
> --
> 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
