I recently upgraded to CCS 5.1.0.09000, which uses compiler TI v4.0.0, from CCS 4.2.4.00033 which uses compiler TI v3.3.2. The update appears to have broken some previously working printf code, and I'm wondering if anyone else has seen this problem.
I've added the following test code fragment to my main():
snprintf (achBuff, sizeof(achBuff), "+9 converts to %d = 0x%x\n", (int16_t)9, (int16_t)9);snprintf (achBuff, sizeof(achBuff), "+10 converts to %d = 0x%x\n", (int16_t)10, (int16_t)10);snprintf (achBuff, sizeof(achBuff), "+11 converts to %d = 0x%x\n", (int16_t)11, (int16_t)11);snprintf (achBuff, sizeof(achBuff), "+12 converts to %d = 0x%x\n", (int16_t)12, (int16_t)12);snprintf (achBuff, sizeof(achBuff), "+13 converts to %d = 0x%x\n", (int16_t)13, (int16_t)13);snprintf (achBuff, sizeof(achBuff), "+14 converts to %d = 0x%x\n", (int16_t)14, (int16_t)14);snprintf (achBuff, sizeof(achBuff), "+15 converts to %d = 0x%x\n", (int16_t)15, (int16_t)15);snprintf (achBuff, sizeof(achBuff), "+16 converts to %d = 0x%x\n", (int16_t)16, (int16_t)16);snprintf (achBuff, sizeof(achBuff), "+17 converts to %d = 0x%x\n", (int16_t)17, (int16_t)17);snprintf (achBuff, sizeof(achBuff), "+18 converts to %d = 0x%x\n", (int16_t)18, (int16_t)18);snprintf (achBuff, sizeof(achBuff), "+19 converts to %d = 0x%x\n", (int16_t)19, (int16_t)19);snprintf (achBuff, sizeof(achBuff), "+20 converts to %d = 0x%x\n", (int16_t)20, (int16_t)20);snprintf (achBuff, sizeof(achBuff), "+21 converts to %d = 0x%x\n", (int16_t)21, (int16_t)21);snprintf (achBuff, sizeof(achBuff), "+22 converts to %d = 0x%x\n", (int16_t)22, (int16_t)22);snprintf (achBuff, sizeof(achBuff), "+23 converts to %d = 0x%x\n", (int16_t)23, (int16_t)23);snprintf (achBuff, sizeof(achBuff), "-9931 = %d and 9931 = %d\n", (int16_t)(-9931), (int16_t)9931);
which produces the following output
+9 converts to 9 = 0x9+10 converts to 1a = 0xa+11 converts to 1b = 0xb+12 converts to 1c = 0xc+13 converts to 1d = 0xd+14 converts to 1e = 0xe+15 converts to 1f = 0xf+16 converts to 10 = 0x10+17 converts to 11 = 0x11+18 converts to 12 = 0x12+19 converts to 13 = 0x13+20 converts to 24 = 0x14+21 converts to 25 = 0x15+22 converts to 26 = 0x16+23 converts to 27 = 0x17-9931 = -9wÿÿ and 9931 = 9wÿÿ
It appears as if the printf conversion routines are now failing in an odd but somewhat systematic way, at least if I ignore the conversion of +-9931. The two odd characters at the end of the conversion are the printed representation of 0xFF. This code was compiled with "full" printf support. When I compile with "minimal" printf support, the output is
+9 converts to 9 = 0x9+10 converts to 10 = 0xa+11 converts to 11 = 0xb+12 converts to 12 = 0xc+13 converts to 13 = 0xd+14 converts to 14 = 0xe+15 converts to 15 = 0xf+16 converts to 16 = 0x10+17 converts to 17 = 0x11+18 converts to 18 = 0x12+19 converts to 19 = 0x13+20 converts to 20 = 0x14+21 converts to 21 = 0x15+22 converts to 22 = 0x16+23 converts to 23 = 0x17-9931 = 55605 and 9931 = 9931
Positive numbers seem to work OK, but negative numbers are treated as unsigned when converted with %d.
In both cases I have a heap and stack size of 4096 each. I don't think it matters, but I'm running on a MSP430F5437A. I'm somewhat reluctantly thinking that TI might have broken the printf routines in the new release, but perhaps I'm doing something wrong that causes this. Does anyone have any suggestions? Has anyone else seen problems with the new compiler's printf routines?
Steve
Dan,
I sent you a friend request. When you accept it, I can send you the MSP430 v4.0.1 installer via private message.
If a post answers your question please mark it with the "Verify Answer" button
Search the wikis for common questions: CGT, BIOS, CCSv3, CCSv4Track a known bug with SDOWP. Enter the bug id in the "Find Record ID" box
I have problem with printf too. Could you please send me a link to the MSP430 code generation tool v4.0.1? Thanks.
Chun
Chun Fan I have problem with printf too. Could you please send me a link to the MSP430 code generation tool v4.0.1? Thanks.
I am experiencing the same problem with printf() as others. Is the updated Code Generation Tools package already available for public download, or could I have a link for the download?
Thanks.
Pertti,
I will send you a friend request. When you accept it I can start a private conversation with you and send you the codegen tools.
I also am having issues with printf. Can I please have the link for the updated tools?
Thanks,
Will
Will,
I just sent you a friend request. When you accept it, I can send you the compiler tools via private conversation.
I'm also having issues with printf. Can you send me the updated compiler tools as well?
William
Aarti,
Is there a reason why the upgrade for the compiler tools cannot be uploaded into a .zip file to this thread?
Or can the upgrade be available through the update manager in CCS?
Best regards,
Austin Miller
Digital Field Applications
If my reply answers your question please click on the green button "Verify Answer".
Austin,
The compiler tools for MSP430 (and ARM) are not available for public download due to business reasons - which is why they are not posted on the compiler download wiki site. The recommended method of update is via update CCS update manager, however the compiler updates have had some delay in getting posted to the CCS v5 update site. The updates are working with CCSv4. We hope to have this resolved soon but in the meantime we can send the tools to users offline.
William Shoesmith I'm also having issues with printf. Can you send me the updated compiler tools as well?
Just sent you the compiler tools via private message.
Is printf with minimal support suppose to handle negative numbers as in
signed int x=-10;
printf("my negative number is %d",x);
Should I get
my negative number is -10
or
my negative number is 65526
I am getting the latter.
Kent
You are probably suffering from SDSCM00042811, as mentioned earlier in this thread. What version of the compiler are you using (not the CCS version)?
I'm using code composer studio version 5.1.0.09000 Just like Stephen Manion, who started this thread. You may be right.
What little description of the minimal fprint I've found it is not clear that it is intended to handle negative numbers. If not, that it is not a bug, but a feature. I can't tell.
Yes it is supposed to handle negative numbers. That it doesn't is a bug that they will eventually fix. In the interim I use "nofloat" instead of "minimal", which costs roughly 3000 bytes of code space