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
Stephen,
Good to hear from you again.
This might be a question to move to the CCS forum but let me contact the CCS and MSP430 applications team about this issue before I move the post.
Enjoy the weekend.
Best regards,
Austin Miller
Digital Field Applications
If my reply answers your question please click on the green button "Verify Answer".
Here is a post similar to what you are experiencing.
E2E: http://e2e.ti.com/support/development_tools/compiler/f/343/t/146417.aspx
I'll follow-up with you no later than Tuesday of next week.
Austin,
Thanks for the reply. I think my printf problem is different from the one referred to in the other post. I’ve looked at this more and simplified the program to provide a clearer failure case and come up with the following:
#include <msp430f5438a.h>
#include <stdint.h>
#include <stdio.h>
int main(void) {
char achBuff[128];
// Stop watchdog timer
WDTCTL = WDTPW + WDTHOLD;
snprintf (achBuff, sizeof(achBuff), "+18 converts to %d = 0x%x\n", (int16_t)18, (int16_t)18);
return 0;
}
Insert a "break" on the return statement and examine the buffer. This example fails the “%d” conversion for any value larger than 9 when compiled with “full” printf support and with a heap and stack size of 4096. I didn’t try it, but I assume negative numbers still fail when compiled with “minimal” printf support. I am running the program on the TI 100 pin 5438A demo board. Hope that helps.
The outputs you're getting look like there's some smart usage of BCD conversion is used - and fails, maybe due to large memory or large data model or whatever. Same may cause the to the weird chars when getting a 4-digit value.In the minimal printf version, it looks like D is treated like U. This may be within the definition of 'minimal' support (e.g. " 'minimal' does not support negative numbers").
_____________________________________Before posting bug reports or ask for help, do at least quick scan over this article. It applies to any kind of problem reporting. On any forum. And/or look here.If you cannot discuss your problem in the public, feel free to start a private conversation: click on my name and then 'start conversation'. But please do so only if you really cannot do it in a public thread, as I usually read all threads. And I prefer to answer where others can profit from it (or contribute to it) too.
The CCS Applications team recommended that your post be moved to the C/C++ compilers forum.
I will continue to monitor this post to make sure that this is resolved.
Let me know if you need anything else.
Now that I'm in the correct forum I see that other people have had this problem, and that I can probably fix it if I upgrade my MSP430 code generation tools from version 4.0.0 to 4.0.1. However, when I start CCS, then go to "Help->Check for Updates" it searches, then tells me "no updates were found" despite the fact that I'm still at level 4.0.0. Does anyone know what I need to do to get the update?
I think the info in this wiki article will help.
Thanks and regards,
-George
TI C/C++ Compiler Forum ModeratorPlease click Verify Answer on the best reply to your question.The Compiler Wiki answers most common questions.Track an issue with SDOWP. Enter your bug id in the "Find Record ID" box.
Unfortunately, that does not help. Specifically:
The Wiki, under the "Compiler updates" headline, says that "Starting with version 4.1.2, CCS checks for compiler updates automatically". As I noted above, this does not appear to work. When I force it to search for updates using the "Help -> Check for updates" it incorrectly tells me there are none. Nothing else in that Wiki appears relevant to a compiler update.
When I select "help -> install new software", then select "all available sites" under the "work with" box at the top, then I get a list that includes "MSP430 Code Generation Tools". If I then check that box and click "next", two things happen. First, I get a dialog box titled "unsupported install" that tells me that I have selected a feature that uses install procedures that are not compatible with the current install support and asking if I want to use the older update manager. At the same time the underlying box is populated with a list of MSP430 code generation tools that includes 4.0.1, which is what I want. However, if I agree to use the older update manager as suggested by the dialog box, I then get even more error messages, not all of which are reproducible, but nothing that ever leads to a successful download.
Does anyone else have advice on how to upgrade?
Steve,
We are still in the process of creating and posting compiler updates for CCS 5.1, so unfortunately, you will not find them when checking for updates from CCSv5. There are a couple of options for you to get the MSP430 codegen tools v4.0.1.
If you still have CCS 4.2.x installed on your machine, you should be able to install it using its Update Manager. If you do not have CCSv4 installed let us know and we can send you the codegen tools 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
AartiG,
I do have 4.2.4.00033 installed, but I can't make it work either. When I try to upgrade I eventually get to the point where it says "MSP430 Code Generation Tools (4.0.1) requires feature "com.ti.ccstudio.utils (1.0.0)", or later version." and it won't let me proceed. If I backtrack and try to update to the latest (4.2.5) version of CCS (which might or might not solve that warning message), I then get ominous warning messages that I am trying to install things that will break a long list of installed components of CCS., which I decline to do.
If you can send me the update by private message, I would appreciate it.
Also, I have to ask, are there other known problems with the v4 compiler? I regard a failed printf library as fairly significant, and I'm disappointed that TI didn't fix that sooner or warn people that CCSv5 wasn't ready for prime time. I wasted an enormous amount of time tracking this down, and now that I'm on the correct bulletin board I can see that other people have done so as well. And also that this has been a known problem for three or more months. Why isn't this information made available to people downloading the install? It seems like a "known problems" list should be a prominent part of the download, which would have saved me (and you for that matter) a lot of time.
I just sent you a friend request. When you accept that I can start a private conversation with you and send you the update. Once you install the codegen tools, please follow the procedure described here to have CCS detect and use this new version: http://processors.wiki.ti.com/index.php/Compiler_Installation_and_Selection#CCStudio_5.1
I'm not sure why the update from CCS 4.2.4 does not work for you. If the newer build utils are required, they should also be selected and installed along with the CGT update. Updating to CCS 4.2.5 is not required. I've had no problems installing this update from CCS 4.2.4 and I know we've had several users do it as well. For the ominous warning messages, if you're referring to the message that warns about duplicate conflicts of BIOS components, that message can be safely ignored.
All codegen tools releases include a file that lists the defect history - known and fixed bugs. Unfortunately, in this case, this bug was found just after MSP430 CGT 4.0.0 was released. Hence it is not listed in the known bugs in the release notes for CGT 4.0.0. Also the timing for release of CCS 5.0 happened to be such that it shipped with CGT 4.0.0, and then the updated CGT 4.0.1 was released shortly after. This, compounded with the fact that the update is not yet "visible" in CCS 5.1, makes it difficult to track down, and I apologize for the inconvenience caused.
This is an update so that the thread will make sense to anyone who finds it later.
Aarti provided me with the 4.0.1 compiler installer, I installed it, set the options to use the new compiler, and was able to compile everything. Thanks for your help, Aarti.
The new compiler eliminates most of the problems I was having. The one remaining unexpected result is that when I use "minimal" printf support the "%d" format specifier treats the input number as unsigned. For example, -9 prints as 65527. The TI compiler documents, slau132f, "MSP430 Optimizing C/C++ Compiler v 4.0", page 31, specifies minimal support as:
minimal: Supports the printing of integer, char, or string values withoutwidth or precision flags. Specifically, only the %%, %d, %o, %c, %s,and %x format specifiers are supported
which led me to expect signed numbers to work. I'm not sure if this is a remaining bug in the intended operation of minimal printf support or a failure of the documentation to clearly specify what minimal means. Switching to "no float" fixes the problem so that negative numbers print as expected, at a cost of ~3000 bytes of code space. Aarti - if you can pass that on to either the documentation writers or the compiler maintainers I'm sure you will eliminate future questions.
Stephen ManionI'm not sure if this is a remaining bug in the intended operation of minimal printf support or a failure of the documentation to clearly specify what minimal means.
The bug tracking # for this issue is SDSCM00042811. You may track the status of the bug using the SDOWP link in my signature.
AaritG,
I am having the exact same issues as Steve was but based on this post you had private conversations with him that helped solve the printf issues with Code Composer 5.1 and MSP430. In particular I need help on installing the latest MSP430 Code Generation tools (4.0.1), that will fix this issue. I am in the same boat as Steve in that I do not have previous versions of the CC compiler that would give the the older update tools.
Can you explain to me how to get this upgrade?
thanks
Dan