Hi Nate, no need to blush longer than for a second or so :) We've all done this or that which turned out to be self-made problems at the end. I learned about the misalignment behaviour of the MSP the hard way, when porting software from Atmel/PIC to the MSP. First, the structures changed size due to padding (and were incompatible between the different products), then I packed them and I got nonsense as result. Since then, the compiler has evolved to cope with packed structs better (at the expense of performance), but I'm happy I discovered it early enough to avoid more subtle problems later. TI should write the 'the LSB is silently ignored with word access' info in extra large letters in their datasheets, as this is something you cannot detect even with a debugger.
Anyway, there is no need to set the stack pointert on MSPGCC. The linker scripts already know the RAM limits of each device and therefore place the stack pointer properly at the end of the available ram. And if you want to reserve some bytes above the stack for some reason, you can do so with the RESERVE_RAM attribute for main(). This way, the project file is independent of the processor used. (e.g. will compile for 149,169,1611 etc. unless you use incompatible hardware modules) JMGross ----- Ursprüngliche Nachricht ----- Von: Bragg Nate An: [email protected] Gesendet am: 30 Mrz 2010 22:17:18 Betreff: Re: [Mspgcc-users] Stack WORD alignment problem Tyler and JMGross, I appreciate both of your help in this. At the risk of making myself out t= o be a total idiot, I realized that like so much else in my life, this mise= ry was self-inflicted. Hopefully humility counts for something. Also, hop= efully you will find this as hilarious as I did. Since taking on this codebase, I have learned a world about how the msp430 = works, and how gcc works. When I started, I attempted to port this codebas= e from the Quadravox compiler. Many of the build automation done for that = compiler was autogenerated, but I regardless attempted to dutifully transcr= ibe from one set of options to the other. Most of these were easy to find,= but some were more difficult. One of the more difficult ones happened to be specifying the stack pointer,= which I eventually found to be "-Wl,--defsym=3D__stack=3D[...]". But, jus= t to make double sure that this one really stuck, I set it to a rather... u= nique address - one that, you guessed it, happened to be odd. Sure enough,= the compiler generated code to match, as expected. Pleased that I figured= out how to set the stack pointer, I moved on... without fixing my Makefile= . TL;DR: If you want to learn a TON about how compilers work and how your tar= get architecture works, set the stack pointer to an odd address, and then f= orget about it. Also, I might humbly suggest that the compiler flags the __stack value bein= g set to an odd address with a warning, that some other poor soul somewhere= wouldn't be faced with the same experience. Sheepishly, Nate Bragg
