Ah! you switched from the main MSPGCC branch to the 430X branch. This is the missing link. When you mentioned older versions of the compiler where it worked, I assumed that you 'just' used a newer build, not a new architecture.
An assembly code snippet of the compiled function call would have made this obvious (push.a instead of push.w instructions etc.). So when the compiler puts a 32bit pointer to the destination buffer on stack and the function assumes 16 bit, then the second 16 bit would be interpreted as length and the length as pointer to the data. Which leads to address 0x0100 where chances are that it is a zero value (="empty string"). So much for the 'save' sprintf version :) Luckily, in C the caller cleans up the stack after the call, not the callee. Looks like we need a lib with separate (sn)printf and far_(sn)printf functions for the 430X branch. And we need to differentiate between far and near pointers as two (incompatible?) separate types, not just a different segment info. Calling a function expecting a far pointer parameter with a near pointer just does a 16-bit extension, the opposite gives a 'conversion loses significant digits' warning. And the printf control string specification requires a 'far' qualifyer for pointers and strings too. Reminds me of the ATMega128 with its 64k data and 128K program space. And separate '_P' functions if the passed 16 bit pointers point into (word oriented) program space and not (byte oriented) data space. JMGross "there's nothing as complicated as a simple pointer - except my wife" (myself) ----- Ursprüngliche Nachricht ----- Von: Jordi Soucheiron An: GCC for MSP430 - http://mspgcc.sf.net Gesendet am: 01 Dez 2009 10:03:02 Betreff: Re: [Mspgcc-users] Problem with sprintf and snprintf in amsp430x2617 Michiel, -mdata-64k worked :D. Thanks a lot 2009/12/1 Michiel Konstapel <[email protected]>: > I noticed a similar problem with printf (outputting to the UART) with the > MSP430X branch. Adding -mdata-64k to CFLAGS fixed it for me, maybe it'll work > for you as well. I'm guessing it doesn't know how to handle the new 20 bit pointers?
