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
