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