Hmmm, as I already stated, the source code of the library functions hasn't changed for 6 years. And the calling code created by the 12/09 build seems to be correct too. I'm not 100% sure about what the compiler generates from the source code (snprintf is forwarded to vnprintf which is forwarded to vuprintf or so, fiddling with the stack).
As for your code, it seems to be okay. Personally, I prefer putting comparisons into their own brackets to make it better readable (the while loop in writedebug). Also, I'm not sure why you put the UCA0TXBUF=c into an atomic section. Since UCA0TXBUF should be declared volatile, there's nothing that requires an atomic operation here. And teh '1<<1' in UARTPutChar looks strange. There should be a define for that bit already in the header files. But that's all just cosmetics and depends on taste and style. Frankly, I have no idea what's wrong. For our current products, I use an older build of the mspgcc toolchain (5/06), and at least sprintf works as expected there (never change a running system). With the new compiler (and processor), I'm working mostly blind, with an LED as the only debug output. The PCBs with serial interface aren't designed yet :) Did you use the same processor when it worked? Or is a new processor type the reason why you switched to a newer build? E.g. on the errata sheet of the 54xx processor I found several CPU related bugs for certain addressing modes of the PC or SP register. This COULD be a problem with the VA_ARGS macros. As this is something the compiler doesn't do normally. You could try directly using vnprintf (with a pointer to the pointer of your format string as argument) or, even more directly, vuprintf, with your UARTPutChar as output function parameter. This eliminates the need of a buffer and makes sure that there is no problem with passing the parameters from one function to the next. But at least in theory there shouldn't be a problem at all. So the question remains: why there is one? :( Well, there's one more idea I have: did you initialize the UART properly? If not, your debug output never leaves the TX buffer, no matter what is written there. Sometimes an LED really has its advantages ;) But I'm sure you already checked it. JMGross ----- Ursprüngliche Nachricht ----- Von: Jordi Soucheiron An: [email protected] Gesendet am: 30 Nov 2009 13:27:12 Betreff: Re: [Mspgcc-users] Problem with sprintf and snprintf in a msp430x2617 Thanks for your reply. I posted this line as an example, but there could be cases where I actually use variables and therefore need s(n)printf instead of strcpy(). For example: snprintf(debugbuf, 256, " Z (%d) \n", data); I haven't placed any 0xa0 character on purpose, but if there was a problem of the code handling the output of the s(n)printf function my code would fail independently of the compiler version used (or at least it should). But the handler is the following: static void writedebug() { uint16_t i = 0; while (debugbuf[i] != '\0' && i < 256) UARTPutChar(debugbuf[i++]); } #line 150 static void UARTPutChar(char c) { if (c == '\n') { UARTPutChar('\r'); } while (!(IFG2 & (1 << 1))) ; { __nesc_atomic_t __nesc_atomic = __nesc_atomic_start(); #line 157 UCA0TXBUF = c; #line 157 __nesc_atomic_end(__nesc_atomic); } } 2009/11/30 JMGross <[email protected]>: > > > After reading your message once again, I stumbled over the words "debugbuf > keeps the same information as if '...' was a null string" > IMHO if the format string is a null string, the destination buffer should > contain a null string too and not 'keep the same' (except if it was a null > string before already). > > Anyway, if you just want to compy your constant text into debugbuf (this is > what your code actually does), you can simply use strcpy() instead. Faster, > smaller and much less stack usage. :) > > JMGross > > ----- Ursprüngliche Nachricht ----- > Von: Jordi Soucheiron > An: [email protected] > Gesendet am: 24 Nov 2009 13:54:25 > Betreff: [Mspgcc-users] Problem with sprintf and snprintf in a msp430x2617 > > Hi, > I've been trying to fix a problem with my build of mspgcc but I got > out of ideas to fix it. Some time ago I used a build from july 2008 > and everithing worked just fine, now I've switched to the last cvs > version and I've found out that sprintf for some reason doesn't write > to the destiny. I've tryed to exec this (this line is from the output > of a nesc precompiler): > snprintf(debugbuf, 256, " + Accelerometer Started\n"); > But instead of moving the string to the debugbuf keeps the same > information just as if " + Accelerometer Started\n" was a null > string. > > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Mspgcc-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/mspgcc-users > -- Jordi Soucheiron Software Engineer DEXMA Parc Tecnològic la Salle Sant Joan de la Salle, 42 08022 Barcelona t/f: [+34] 93 181 01 95 www.dexmatech.com [email protected] ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Mspgcc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mspgcc-users
