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 ;-). 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
