C2000 C/C++ CODE GENERATION TOOLS 6.4.10 March 2016 Defect History ------------------------------------------------------------------------------- Table of Contents ------------------------------------------------------------------------------- 1. Defects fixed in C2000 Code Generation Tools release 6.4.10 2. Defects fixed in C2000 Code Generation Tools release 6.4.9 3. Defects fixed in C2000 Code Generation Tools release 6.4.7 4. Defects fixed in C2000 Code Generation Tools release 6.4.6 5. Defects fixed in C2000 Code Generation Tools release 6.4.4 6. Defects fixed in C2000 Code Generation Tools release 6.4.3 7. Defects fixed in C2000 Code Generation Tools release 6.4.2 8. Defects fixed in C2000 Code Generation Tools release 6.4.1 9. Defects fixed in C2000 Code Generation Tools release 6.4.0 10. Defects fixed in C2000 Code Generation Tools release 6.4.0B1 11. Current Known Issues =============================================================================== 1. Defects fixed in C2000 Code Generation Tools release 6.4.10 =============================================================================== The following 6 defects were fixed in C2000 Code Generation Tools release 6.4.10, released March 2016. ------------------------------------------------------------------------------- FIXED SDSCM00052529 ------------------------------------------------------------------------------- Summary : Optimizer assumes enum variable can only have value of enumeration constants Fixed in : 6.4.10 Severity : S2 - Major Affected Component : Optimizer Duplicate Defects : SDSCM00048886 Release Notes: If an enumerated type is defined to have only two constants that evaluate to 0 and 1, then the compiler will assume that only those two values are possible. However, the C++ and C standards allow variables of enumerated types to hold other values as well; if other values are used, the compiler may produce incorrect code. Workaround: Don't make enumerated types with constants only for 0 and 1 if other values may be used. Either add a third value, or use values different than 0 and 1, or avoid using values that aren't the enumeration constants. ------------------------------------------------------------------------------- FIXED SDSCM00052652 ------------------------------------------------------------------------------- Summary : Compiler fails with >> INTERNAL ERROR: Instruction scheduling may be incorrect Fixed in : 6.4.10 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: The C2000 code generator may in rare cases issue the error "Instruction scheduling may be incorrect" near calls. Workaround: None. ------------------------------------------------------------------------------- FIXED SDSCM00052699 ------------------------------------------------------------------------------- Summary : Compiler discards write to a volatile local struct member Fixed in : 6.4.10 Severity : S2 - Major Affected Component : Optimizer Release Notes: When volatile appears in a struct definition ... struct device { volatile unsigned tcc; } dev; The compiler doesn't honor it. References to dev.tcc still get optimized away. Workaround: No workaround. ------------------------------------------------------------------------------- FIXED SDSCM00052723 ------------------------------------------------------------------------------- Summary : Compiler seg faults with use of --opt_level=4 Fixed in : 6.4.10 Severity : S2 - Major Affected Component : ILinker (File Merge) Release Notes: The compiler may segmentation fault during link time optimization if a structure is encountered that contains an unnamed struct member. Workaround: Use optimization level 3 or below. ------------------------------------------------------------------------------- FIXED SDSCM00052737 ------------------------------------------------------------------------------- Summary : Compiler reorders MOVDL or MOVD32 instruction with an instruction which reads the delayed memory Fixed in : 6.4.10 Severity : S2 - Major Affected Component : Code Generator Release Notes: For this code ... static inline FLOAT32 filter3rdOrder(FilterStruct* FilterToCalc) //FLOAT32 filter3rdOrder(FilterStruct* FilterToCalc) { FilterToCalc->fl32out = FilterToCalc->fl32b0 * FilterToCalc->fl32in + FilterToCalc->fl32b1 * FilterToCalc->fl32in_k1 + FilterToCalc->fl32b2 * FilterToCalc->fl32in_k2 + FilterToCalc->fl32b3 * FilterToCalc->fl32in_k3 - FilterToCalc->fl32a1 * FilterToCalc->fl32out_k1 - FilterToCalc->fl32a2 * FilterToCalc->fl32out_k2 - FilterToCalc->fl32a3 * FilterToCalc->fl32out_k3; //Save outputs FilterToCalc->fl32in_k3 = FilterToCalc->fl32in_k2; FilterToCalc->fl32in_k2 = FilterToCalc->fl32in_k1; FilterToCalc->fl32in_k1 = FilterToCalc->fl32in; FilterToCalc->fl32out_k3 = FilterToCalc->fl32out_k2; FilterToCalc->fl32out_k2 = FilterToCalc->fl32out_k1; FilterToCalc->fl32out_k1 = FilterToCalc->fl32out; return FilterToCalc->fl32out; } The compiler, when using --opt_level=2 or higher, does not write any value to the field fl32in_k2. Workaround: None. ------------------------------------------------------------------------------- FIXED SDSCM00052774 ------------------------------------------------------------------------------- Summary : Using __IQsat with destination same as one input leads to bad code Fixed in : 6.4.10 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: if ( nWords2Send < 0 ) { nWords2Send += 160 ; // Cyclic buffer roll } The operation inside the if statement has no code generated for it. Workaround: No practical workaround =============================================================================== 2. Defects fixed in C2000 Code Generation Tools release 6.4.9 =============================================================================== The following 3 defects were fixed in C2000 Code Generation Tools release 6.4.9, released November 2015. ------------------------------------------------------------------------------- FIXED SDSCM00052393 ------------------------------------------------------------------------------- Summary : Legal use of __byte intrinsic with --opt_level=2 leads to error message: Illegal use of intrinsic: __byte Fixed in : 6.4.9 Severity : S2 - Major Affected Component : Optimizer Release Notes: Certain uses of __byte in non-trivial expressions will cause the compilation to fail with an error message like "error: "try1.c", line 2041: Illegal use of intrinsic: __byte". Workaround: Compile with -o1 or -o0. ------------------------------------------------------------------------------- FIXED SDSCM00052397 ------------------------------------------------------------------------------- Summary : Optimizer crashes on unreachable integer divide-by-zero Fixed in : 6.4.9 Severity : S2 - Major Affected Component : Optimizer Release Notes: The optimizer crashes on an unreachable integer divide-by-zero. INTERNAL ERROR: c:\drives\i\C2000\V64~1.6\compiler\cgtools\bin\opt2000.exe experienced a segmentation fault Workaround: None. ------------------------------------------------------------------------------- FIXED SDSCM00052414 ------------------------------------------------------------------------------- Summary : C2000 compiler 6.4.7 components are incorrectly labeled as 6.4.8. Fixed in : 6.4.9 Severity : S3 - Minor Affected Component : Shell Release Notes: All the versions of the C2000 compiler release 6.4.7 are labeled as 6.4.8. C:\CCSv6_1_1\ccsv6\tools\compiler\ti-cgt-c2000_6.4.7\bin>cl2000.exe -version TMS320C2000 C/C++ Compiler v6.4.8 Build Number 1PKKL-I3E%IMB0-RTARQ-RAQ-C08D TMS320C2000 C/C++ Parser v6.4.8 Build Number 1PKKL-I3E%IMB0-RTARQ-RAQ-C08D TMS320C2000 C/C++ File Merge v6.4.8 Build Number 1PKKN-I3E%IMB0-RTARQ-RAQ-C08D TMS320C2000 C/C++ Optimizer v6.4.8 Build Number 1PKKN-I3E%IMB0-RTARQ-RAQ-C08D TMS320C2000 C/C++ Codegen v6.4.8 Build Number 1PKKM-I3E%IMB0-RTARQ-RAQ-C08D TMS320C2000 Assembler v6.4.8 Build Number 1PKKL-I3E%IMB0-RTARQ-RAQ-C08D TMS320C2000 Embed Utility v6.4.8 Build Number 1PKKM-I3E%IMB0-RTARQ-RAQ-C08D TMS320C2000 C Source Interlister v6.4.8 Build Number 1PKKM-I3E%IMB0-RTARQ-RAQ-C08D TMS320C2000 Linker v6.4.8 Build Number 1PKKM-I3E%IMB0-RTARQ-RAQ-C08D TMS320C2000 Absolute Lister v6.4.8 Build Number 1PKKL-I3E%IMB0-RTARQ-RAQ-C08D TMS320C2000 Strip Utility v6.4.8 Build Number 1PKKN-I3E%IMB0-RTARQ-RAQ-C08D TMS320C2000 XREF Utility v6.4.8 Build Number 1PKKN-I3E%IMB0-RTARQ-RAQ-C08D TMS320C2000 C++ Demangler v6.4.8 Build Number 1PKKM-I3E%IMB0-RTARQ-RAQ-C08D TMS320C2000 Hex Converter v6.4.8 Build Number 1PKKN-I3E%IMB0-RTARQ-RAQ-C08D TMS320C2000 Library Builder v6.4.8 Build Number 1PKKN-I3E%IMB0-RTARQ-RAQ-C08D TMS320C2000 Name Utility v6.4.8 Build Number 1PKKN-I3E%IMB0-RTARQ-RAQ-C08D TMS320C2000 Object File Display v6.4.8 Build Number 1PKKN-I3E%IMB0-RTARQ-RAQ-C08D TMS320C2000 Archiver v6.4.8 Build Number 1PKKL-I3E%IMB0-RTARQ-RAQ-C08D Workaround: N/A. =============================================================================== 3. Defects fixed in C2000 Code Generation Tools release 6.4.7 =============================================================================== The following 9 defects were fixed in C2000 Code Generation Tools release 6.4.7, released October 2015. ------------------------------------------------------------------------------- FIXED SDSCM00052144 ------------------------------------------------------------------------------- Summary : RTS libraries do not get automatically built if the library is missing (Mac OS X) Fixed in : 6.4.7 Severity : S2 - Major Affected Component : Runtime Support Libraries (RTS) Release Notes: On Mac OS X, the RTS lib does not get auto generated if it is missing like it does on Windows/Linux. mklib, which is responsible for building the libraries, is not currently supported on Mac OS X. Workaround: Copy the libraries from a Windows/Linux machine. ------------------------------------------------------------------------------- FIXED SDSCM00052255 ------------------------------------------------------------------------------- Summary : Compiler mistakenly emits PREAD instruction when copying volatile structure Fixed in : 6.4.7 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: The compiler documentation states that it will not use the PREAD instruction when accessing volatile variables. The PREAD instruction is being used in a case where there is a structure assignment where one of the structures is declared volatile. Workaround: None. ------------------------------------------------------------------------------- FIXED SDSCM00052257 ------------------------------------------------------------------------------- Summary : Use of --opt_level=4 causes link to fail with message symbol "name" redeclared with incompatible type Fixed in : 6.4.7 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Duplicate Defects : SDSCM00050982 Release Notes: When using -O4 optimization, the linker would sometimes incorrectly emit a "redeclared with incompatible type" error for global symbols declared with types that are at some depth defined with structs (or classes, or unions) with anonymous members. Workaround: Change all anonymous members of the types involved to have an explicit name. ------------------------------------------------------------------------------- FIXED SDSCM00052265 ------------------------------------------------------------------------------- Summary : Flexible array with initializer not handle correctly Fixed in : 6.4.7 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: Zero-length arrays is a GCC extension supported by TI compilers. The zero- length array extension also defines static initialization of C99 flex arrays. Static initialization of flex arrays should work in C99 mode when GCC extensions are enabled. Although the parser accepted these initializations, they were not output in assembly. Workaround: None. ------------------------------------------------------------------------------- FIXED SDSCM00052281 ------------------------------------------------------------------------------- Summary : ARM Parser Segfaults on OSX at Template Class Fixed in : 6.4.7 Severity : S2 - Major Affected Component : Parser Duplicate Defects : SDSCM00052282 Release Notes: Parsers built for OSX may segmentation fault upon encountering a template. Workaround: None. ------------------------------------------------------------------------------- FIXED SDSCM00052301 ------------------------------------------------------------------------------- Summary : Linker crashes when --ecc:ecc_error is used Fixed in : 6.4.7 Severity : S2 - Major Affected Component : Linker Release Notes: The --ecc:ecc_error option is used to inject errors into ecc information. The option takes the location of memory with ecc coverage and translates that location to the location of the corresponding ecc information. However, the translation from the program address to the ecc address was incorrect which could lead to unexpected errors, changing unexpected information, or even a segmentation fault in the linker. Workaround: None. ------------------------------------------------------------------------------- FIXED SDSCM00052310 ------------------------------------------------------------------------------- Summary : Mac OS release is missing files in the /include and /lib directories Fixed in : 6.4.7 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: After installation the /include and /lib directories are empty. Workaround: Use the 6.4.4 Mac OS tools release. ------------------------------------------------------------------------------- FIXED SDSCM00052323 ------------------------------------------------------------------------------- Summary : CLA parser accepts almost any invalid argument to the interrupt pragma Fixed in : 6.4.7 Severity : S2 - Major Affected Component : Parser Release Notes: The CLA parser will silently accept almost any invalid argument to the interrupt pragma. Workaround: None. ------------------------------------------------------------------------------- FIXED SDSCM00052339 ------------------------------------------------------------------------------- Summary : demangler --output option does not work at all Fixed in : 6.4.7 Severity : S2 - Major Affected Component : Demangler (dem) Release Notes: The --output option of armdem does not work at all. You will always get the error message ">> Cannot open output file '(null)'" Workaround: armdem file.asm > file.dis =============================================================================== 4. Defects fixed in C2000 Code Generation Tools release 6.4.6 =============================================================================== The following 8 defects were fixed in C2000 Code Generation Tools release 6.4.6, released June 2015. ------------------------------------------------------------------------------- FIXED SDSCM00051756 ------------------------------------------------------------------------------- Summary : C2000 v.6.4 Direct Address Plus Offset Performance Bug Fixed in : 6.4.6 Severity : S2 - Major Affected Component : Code Generator Release Notes: Starting with v.6.4, there is a performance bug in generation of direct address plus offset (for example, MOVL XARn, #_Address+10). In some cases, the compiler may generate a longer sequence of instructions to compute the address, resulting in code growth. Results are still correct. Workaround: There is no workaround. ------------------------------------------------------------------------------- FIXED SDSCM00051762 ------------------------------------------------------------------------------- Summary : Dot expression adding align(64) computes hugely incorrect size Fixed in : 6.4.6 Severity : S2 - Major Affected Component : ELF Linker Release Notes: When computing the size to be added for a dot expression (e.g. ". += align(64)"), the linker may mistakenly compute a large value and fail to place the section: "lnk.cmd", line 56: error: program will not fit into available memory. placement with alignment fails for section ".foo" size 0x0 . Available memory ranges: BMEM size: 0x2000000 unused: 0x1ff8ff0 max hole: 0x1ff8ff0 Defect occurs in C2000 Compiler versions: 6.1.0B1 - 6.1.10, 6.2.0B1 - 6.2.11, 6.4.0B1 - 6.4.4, 15.3.0 Workaround: None. ------------------------------------------------------------------------------- FIXED SDSCM00051809 ------------------------------------------------------------------------------- Summary : "if (P) X=A; else X=B;" may compile incorrectly when A and B are 0/1 and P is 0/1 with a side effect Fixed in : 6.4.6 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: "if (P) X=A; else X=B;" may compile incorrectly when A and B are either 0 or 1, P is known to return only 0 and 1, and P has side effect (eg, it is a function that modifies a global variable and then returns 0 or 1). The compiler tries to reduce the IF to a simpler form like "X=P", but it does so via an intermediate form that uses P twice, which is incorrect when P has side effects. Defect occurs in C2000 Compiler versions: 6.2.0B1 - 6.2.11, 6.4.0B1 - 6.4.4, 15.3.0 Workaround: Typically such an IF is equivalent to "X=P" or "X=!P"; write it that way to avoid the problem. Adding statements to either arm of the IF can also help. ------------------------------------------------------------------------------- FIXED SDSCM00051814 ------------------------------------------------------------------------------- Summary : Compiler issues internal error when linking on build that uses --opt_level=4 Fixed in : 6.4.6 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: C2000 releases 6.2.x and before used 22-bit pointers. C2000 releases 6.4.x and newer use 32-bit pointers. The compiler is able to use old files in a 6.4.x compilation, except for one spot we missed. Compiling with -o4, using 6.4.x tools, when an object file or library was compiled with 6.2.x, will experience a compiler assertion failure. Defect occurs in C2000 Compiler versions: 6.4.0B1 - 6.4.4, 15.3.0 Workaround: The problem exists only when mixing 6.2.x and 6.4.x object files when compiling with -o4. Thus the workaround is either to compile all files with the same release, or to use -o3. ------------------------------------------------------------------------------- FIXED SDSCM00051822 ------------------------------------------------------------------------------- Summary : When using --opt_level=2 compiler fails with INTERNAL ERROR Register allocation failed Fixed in : 6.4.6 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Duplicate Defects : SDSCM00051985, SDSCM00051975 Release Notes: Register allocation may fail due to function calls where the arguments contain arithmetic operations. This behavior has only been observed with optimization enabled. Defect occurs in C2000 Compiler versions: 6.4.0 - 6.4.4, 15.3.0 Workaround: Lower the level of optimization. ------------------------------------------------------------------------------- FIXED SDSCM00051923 ------------------------------------------------------------------------------- Summary : The prototype for memcpy is not present in string.h Fixed in : 6.4.6 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: The declaration of memcpy() was missing from the C2000 string.h C standard header. Defect occurs in C2000 Compiler versions: 6.1.0B1 - 6.1.10, 6.2.0B1 - 6.2.11, 6.4.0 - 6.4.4, 15.3.0 Workaround: None. ------------------------------------------------------------------------------- FIXED SDSCM00051974 ------------------------------------------------------------------------------- Summary : Compiler mishandles setting condition for branch at end of loop. Causes loop to never end. Fixed in : 6.4.6 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: The attached test case includes a typical loop. The code that ends the loop should decrement the loop control variable, then branch back to the top if the variable is not equal to 0. The code emitted by the compiler inserts unrelated instructions between the decrement and the branch. Those instructions change the condition codes established by the decrement. Thus the branch back to the top of the loop is unreliable. In this particular case, the loop never ends. Workaround: No workaround. ------------------------------------------------------------------------------- FIXED SDSCM00052015 ------------------------------------------------------------------------------- Summary : Compiler fails with diagnostic INTERNAL ERROR: opt2000 experienced a segmentation fault Fixed in : 6.4.6 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: The problem is a divide-by-zero crash while simplifying expressions. Given something like "x*k1 == k2", the compiler will attempt to reduce that to "x == k3" where k3 is k2/k1. In our case, a series of simplifications has reduced k1 to 0, but not yet simplified the multiplication to zero. Thus k2/k1 divides by zero and dies. To get to this point requires a series of simplifications of mask and shift operations, plus computing expressions as 32-bit values but finally storing into a 16-bit variable. The sequence is too complicated to offer an easy way to recognise it or avoid it in the source. Workaround: None yet known. =============================================================================== 5. Defects fixed in C2000 Code Generation Tools release 6.4.4 =============================================================================== The following 7 defects were fixed in C2000 Code Generation Tools release 6.4.4, released April 2015. ------------------------------------------------------------------------------- FIXED SDSCM00050103 ------------------------------------------------------------------------------- Summary : Buffer the output of warning and error messages to facilitate better error reporting during parallel compilation Fixed in : 6.4.4 Severity : S2 - Major Classification : Enhancement Affected Component : C/C++ Compiler (cl) Release Notes: The added --buffer_diagnostics option may be used to force compiler diagnostics to be printed by line instead of by character. This will reduce mangling of diagnostics when multiple instances of the compiler are ran in parallel. Defect occurs in C2000 Compiler versions: 6.2.0B1 - 6.2.11, 6.4.0B1 - 6.4.3 Workaround: Workaround is to manually buffer the compiler output using a script or with the --write_diagnostics_file option. ------------------------------------------------------------------------------- FIXED SDSCM00051601 ------------------------------------------------------------------------------- Summary : The C28x compiler uses a RPT PREAD loop when copying volatile structs Fixed in : 6.4.4 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: PREAD instructions should not be emitted when accessing volatile data. Workaround: Do not use the --unified_memory option. ------------------------------------------------------------------------------- FIXED SDSCM00051602 ------------------------------------------------------------------------------- Summary : Parser may seg fault on template arguments with ! operator Fixed in : 6.4.4 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: If the parser encounters a template argument of the form !foo, it may segmentation fault. This behavior is related to GNU mode and may be avoided with the --strict_ansi option. Defect occurs in C2000 Compiler versions: 6.4.0B1 - 6.4.3, 15.3.0 Workaround: Using the --strict_ansi option will avoid this behavior. If this is not possible, changing template arguments of the form !foo to 0==foo will also avoid this behavior. ------------------------------------------------------------------------------- FIXED SDSCM00051621 ------------------------------------------------------------------------------- Summary : Redeclaring extern "C" function as static causes parser to hang Fixed in : 6.4.4 Severity : S2 - Major Affected Component : Parser Release Notes: Redeclaring an extern "C" function function as static may cause the parser to hang. For example: extern "C" namespace N { extern void foo(); void bar(); static inline void foo() {} } will result in the parser hanging due to the redeclaration of foo(). Defect occurs in C2000 Compiler versions: 6.2.0B1 - 6.2.11, 6.4.0B1 - 6.4.3, 15.3.0 Workaround: Use consistent function declarations. ------------------------------------------------------------------------------- FIXED SDSCM00051625 ------------------------------------------------------------------------------- Summary : Compiler issues TEST instruction which assembler rejects Fixed in : 6.4.4 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: The compiler is producing an invalid assembly instruction. Workaround: No workaround. ------------------------------------------------------------------------------- FIXED SDSCM00051629 ------------------------------------------------------------------------------- Summary : Compiler seg faults in C++ copy constructor call Fixed in : 6.4.4 Severity : S2 - Major Affected Component : Parser Release Notes: This segmentation fault may occur in calls to copy constructors. For example: new CLASS( myCLASS ); Defect occurs in C2000 Compiler versions: 6.2.0B1 - 6.2.11, 6.4.0B1 - 6.4.3, 15.3.0 Workaround: In some cases, using a different ABI option may avoid this error. However, the most safe option is to avoid the use of a copy constructor. ------------------------------------------------------------------------------- FIXED SDSCM00051708 ------------------------------------------------------------------------------- Summary : Loop downcounter may be mistakenly typed too small Fixed in : 6.4.4 Severity : S2 - Major Affected Component : Optimizer Release Notes: When optimized, a loop may be restructured to use a downcounter, essentially of the form "while (--i)". However, in some cases, the downcounter may receive a type that is too small. In particular, if the loop may run for more iterations than MAX_INT, all iterations may not execute. Defect occurs in C2000 Compiler versions: 6.1.0B1 - 6.1.10, 6.2.0B1 - 6.2.11, 6.4.3, 15.3.0 Workaround: Lower the level of optimization. =============================================================================== 6. Defects fixed in C2000 Code Generation Tools release 6.4.3 =============================================================================== The following 9 defects were fixed in C2000 Code Generation Tools release 6.4.3, released March 2015. ------------------------------------------------------------------------------- FIXED SDSCM00044254 ------------------------------------------------------------------------------- Summary : c2000 hextool maximum block size limitation Fixed in : 6.4.3 Severity : S2 - Major Affected Component : Hex Converter (hex) Release Notes: On some devices, Hextool may cause the bootloader to hang due to the creation of a maximum length boot block (0xFFFF). The maximum length will be lowered to 0xFFFE. Defect occurs in C2000 Compiler versions: 5.2.0B1 - 5.2.15, 6.0.0B1 - 6.0.6, 6.1.0B1 - 6.1.10, 6.2.9 - 6.2.10, 6.4.0B1 - 6.4.2 Workaround: None. ------------------------------------------------------------------------------- FIXED SDSCM00050959 ------------------------------------------------------------------------------- Summary : SIGSSEGV when using % in an option argument Fixed in : 6.4.3 Severity : S2 - Major Affected Component : Shell Release Notes: In some cases, the compiler passes user-created identifiers directly to a function which behaves like printf without using a format string. If the user's identifier contains any printf-special characters, the compiler may crash. Defect occurs in C2000 Compiler versions: 6.4.0B1 - 6.4.2 Workaround: Don't use any printf-special characters like % in a compiler argument ------------------------------------------------------------------------------- FIXED SDSCM00051388 ------------------------------------------------------------------------------- Summary : Compiler emits illegal instruction for SP save Fixed in : 6.4.3 Severity : S2 - Major Affected Component : Code Generator Release Notes: On C2000, an illegal store of the stack pointer to memory may be generated. This bug has only been seen at optimization level 2 and above but could occur at a lower level. If affected assembly is generated, the assembler will error with "Illegal operand combination." Defect occurs in C2000 Compiler versions: 5.2.0B1 - 5.2.15, 6.0.0B1 - 6.0.6, 6.1.0B1 - 6.1.10, 6.2.4 - 6.2.10, 6.4.0B1 - 6.4.2 Workaround: Changing the optimization level for an affected file will most likely avoid the error. ------------------------------------------------------------------------------- FIXED SDSCM00051389 ------------------------------------------------------------------------------- Summary : Compiler emits RPTB that is too large Fixed in : 6.4.3 Severity : S2 - Major Affected Component : Code Generator Release Notes: The compiler treated the instruction ADDUL P, loc32 as if it were 16 bits. However, it is actually 32 bits. If the compiler used this instruction in an RPTB, it would underestimate the size of the RPTB, and could potentially create an RPTB that was too large to be legal. Defect occurs in C2000 Compiler versions: 5.2.0B1 - 5.2.15, 6.0.0B1 - 6.0.6, 6.1.0B1 - 6.1.10, 6.2.0B1 - 6.2.10, 6.4.0B1 - 6.4.2 Workaround: No practical workaround ------------------------------------------------------------------------------- FIXED SDSCM00051394 ------------------------------------------------------------------------------- Summary : Loop containing floating-point min or max reduction may cause compiler crash Fixed in : 6.4.3 Severity : S2 - Major Affected Component : Optimizer Release Notes: A loop containing a min or max reduction -- ie for ... a = (a > b) ? a : b; when all the expressions are floating-point and the code is compiled with --float_support=fpu32 or fpu64, may cause the compiler to crash. Defect occurs in C2000 Compiler versions: 6.4.0B1 - 6.4.2 Workaround: Compile with -o0 or -o1, or use -mf0, -mf1, or -mf2, or add "#pragma UNROLL(1)" to the offending loop. ------------------------------------------------------------------------------- FIXED SDSCM00051472 ------------------------------------------------------------------------------- Summary : Conditionals that use shift operator may be optimized out Fixed in : 6.4.3 Severity : S2 - Major Affected Component : Optimizer Release Notes: Shift operations in conditional statements may be optimized out, treating the result as 0. This will result in the entire conditional block being removed. NOTE: Intrinsics that perform shifts may be affected. In the observed test case, a shift was not explicitly used -- the C6x intrinsic _extu, which performs two shifts, was affected. Defect occurs in C2000 Compiler versions: 5.2.0B1 - 5.2.15, 6.0.0B1 - 6.0.6, 6.1.0B1 - 6.1.10, 6.2.0B1 - 6.2.11, 6.4.0B1 - 6.4.2 Workaround: This behavior may be avoided by lowering the optimization level to -o1 or -o0. Moving the conditional check result to a variable so that the shift is not in the conditional may in some cases also avoid this behavior. ------------------------------------------------------------------------------- FIXED SDSCM00051506 ------------------------------------------------------------------------------- Summary : x -= y * z replaced with __parallel_mpy_add_f32 Fixed in : 6.4.3 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Duplicate Defects : SDSCM00051514 Release Notes: Floating point operations of the form x -= y * z may be computed as x += y * z on C2000. The issue is identifiable by the use of the MACF32 (floating point multiply accumulate) instruction in affected loops. Defect occurs in C2000 Compiler versions: 6.2.0B1 - 6.2.11, 6.4.2 Workaround: Lower the optimization level to -o0 or -o1. Alternatively, changing the statement "x -= y * z" to "volatile float t = y * z; x -= t" should also avoid this behavior. ------------------------------------------------------------------------------- FIXED SDSCM00051517 ------------------------------------------------------------------------------- Summary : Stack is corrupted when --opt_for_space is used Fixed in : 6.4.3 Severity : S2 - Major Affected Component : Code Generator Release Notes: When optimize for size is used on C2000 (-ms, --opt_for_space, -mf0), the prolog and/or epilog for a function may be replaced with library routines such as _prolog_c28x_2. If a prolog from the library is used, but an epilog from the library is not, this may result in not properly restoring all saved registers from the stack. Defect occurs in C2000 Compiler versions: 5.2.0B1 - 5.2.15, 6.0.0B1 - 6.0.6, 6.1.0B1 - 6.1.10, 6.2.0B1 - 6.2.11, 6.4.2 Workaround: Disable/lower optimization for size. Note: Normal optimization levels (-o[0-4]) do not affect this bug. Lowering or removing the use of -ms (--opt_for_space) and -mf to favor performance over size will alleviate this behavior. ------------------------------------------------------------------------------- FIXED SDSCM00051562 ------------------------------------------------------------------------------- Summary : The C2000 compiler produces the following instruction: MOV *+FP[AR0],SP Fixed in : 6.4.3 Severity : S2 - Major Affected Component : Code Generator Release Notes: The compiler will no longer generate this sequence. Defect occurs in C2000 Compiler versions: 6.4.0 - 6.4.2 Workaround: There is no obvious workaround, but most like reducing the optimization level or adjusting the size/speed trade off (--opt_for_speed) will perturb the code enough to avoid the issue. =============================================================================== 7. Defects fixed in C2000 Code Generation Tools release 6.4.2 =============================================================================== The following 4 defects were fixed in C2000 Code Generation Tools release 6.4.2, released January 2015. ------------------------------------------------------------------------------- FIXED SDSCM00050992 ------------------------------------------------------------------------------- Summary : The optimizer should not make a symbol an alias if it has either the location or code_section pragmas applied. Fixed in : 6.4.2 Severity : S2 - Major Affected Component : Compiler Consultant (ci) Release Notes: For a reason external to the expression of the program, the user relies on function X being at a particular address A. The only method the user has to do this is to put the function in its own special subsection and place it at A in the linker command file. Workaround: Available workarounds are to: 1. Reduce the optimization level to -o2. 2. If using a COFF abi, you can move the functions into separate files. 3. Add an __asm("NOP") to the function which will prevent an alias from being created. ------------------------------------------------------------------------------- FIXED SDSCM00051144 ------------------------------------------------------------------------------- Summary : CLA compiler issues warning about size_t when compiling stddef.h Fixed in : 6.4.2 Severity : S3 - Minor Affected Component : C/C++ Compiler (cl) Release Notes: When compiling for CLA, if stddef.h is included, the parser will warn: declaration of "size_t" does not match the expected type "unsigned int". Both types are 32 bits wide and compatible, so the warning may be safely ignored. Defect occurs in C2000 Compiler versions: 6.1.0B1 - 6.1.10, 6.2.9 - 6.2.10, 6.4.0B1 - 6.4.1 Workaround: To silence the warning, either 1) Disable the warning on the command line: cl2000 --cla_support -pds=921 2) Disable the warning in source before the inclusion: #pragma diag_suppress 921 ------------------------------------------------------------------------------- FIXED SDSCM00051261 ------------------------------------------------------------------------------- Summary : The exception handling (_eh) version of runtime library is not automatically built when --exceptions option is enabled Fixed in : 6.4.2 Severity : S2 - Major Affected Component : Runtime Support Libraries (RTS) Release Notes: The exception handling (_eh) version of runtime library is not automatically built for projects that have --exceptions option enabled. This results in "undefined symbol" linker errors due to the incorrect rts library being linked in. This is caused by a missing build attribute in assembly files. This may be confirmed by examining the assembly for "Tag_Exceptions". Defect occurs in C2000 Compiler versions: 5.2.0B1 - 5.2.15, 6.0.0B1 - 6.0.6, 6.1.0B1 - 6.1.10, 6.2.0B1 - 6.2.10, 6.4.0B1 - 6.4.1 Workaround: You can build the library manually. In a command terminal, browse to the lib dir of the code gen folder (ex. C:\ti\ccsv6\tools\compiler\c2000_6.2.7\lib) and run the following command: > set PATH=%PATH%;C:\ti\ccsv6\tools\compiler\c2000_6.2.7\bin > mklib --pattern=rts2800_eh.lib --index=libc.a -- > install_to=C:/ti/ccsv6/tools/compiler/c2000_6.2.7/lib Update the paths to the CGT folder to match your install. Change the library name that is passed to the --patter option to build the other libraries for floating point (rts2800_fpu32_eh.lib) or large memory model (rts2800_ml_eh.lib). ------------------------------------------------------------------------------- FIXED SDSCM00051267 ------------------------------------------------------------------------------- Summary : Corrupted .cinit records for large data structures Fixed in : 6.4.2 Severity : S2 - Major Affected Component : Code Generator Release Notes: A large statically initialized data structure may corrupt the initialization table. This may occur when: 1. The size of the structure is greater than the largest possible initialization record on the target. 2. The COFF ABI is being used. This will result in the creation of a zero length initialization record immediately following the record for the large structure which will end the initialization process. Defect occurs in C2000 Compiler versions: 5.2.0B1 - 5.2.15, 6.0.0B1 - 6.0.6, 6.1.0B1 - 6.1.10, 6.2.0B1 - 6.2.10, 6.4.0 - 6.4.1 Workaround: Data structures will need to be manually initialized. =============================================================================== 8. Defects fixed in C2000 Code Generation Tools release 6.4.1 =============================================================================== The following 4 defects were fixed in C2000 Code Generation Tools release 6.4.1, released December 2014. ------------------------------------------------------------------------------- FIXED SDSCM00051126 ------------------------------------------------------------------------------- Summary : Compiler mistakenly duplicates side-effect in function call argument Fixed in : 6.4.1 Severity : S2 - Major Affected Component : Code Generator Release Notes: If there is a side effect in a function call with an expression with the result of a 32-bit multiply feeding into a 32-bit add, the compiler could mistakenly duplicate the side effect, which could create incorrect behavior. The optimizer can create this scenario from user code that doesn't appear to have a side effect, such as an array index inside a loop. Defect occurs in C2000 Compiler versions: 5.2.0B1 - 5.2.15, 6.0.0B1 - 6.0.6, 6.1.0B1 - 6.1.10, 6.2.0 - 6.2.10, 6.4.0B1 - 6.4.0 Workaround: Put the value of the function call argument in a volatile local register before passing it to the function. ------------------------------------------------------------------------------- FIXED SDSCM00051212 ------------------------------------------------------------------------------- Summary : MSP 4.4.0 changes to _lock.h declaration of _nop(void) instead of _nop() breaking driverlib Fixed in : 6.4.1 Severity : S2 - Major Affected Component : Runtime Intrinsics Release Notes: MSP 4.4.0 RTS file _lock.h changed prototype for _nop() to _nop(void) which errors in parser for driverlib projects. Workaround: Update _lock.h in the rts source folder, rename the library you are using, and it will automatically be rebuilt during next compile. To find compiler install location, click on project properties and click on: Resource->Linked Resources The "Path Variable" will have an entry for: CG_TOOL_ROOT c:\install_location\ccsv6\tools\compiler\msp430_4.3.4 Within above folder look for: .\lib\src\_lock.h .\include\_lock.h Edit both of above files and change below line 47: _CODE_ACCESS void _nop(void); to remove void argument and instead be: _CODE_ACCESS void _nop(); Rename the library you are using with suffix .old: .\lib\rtsx_lc_sd_eabi.lib change to a temp name .\lib\rtsx_lc_sd_eabi.lib.old Rebuild your project and the rts should automatically rebuild. ------------------------------------------------------------------------------- FIXED SDSCM00051235 ------------------------------------------------------------------------------- Summary : C2000 CGT v6.4 CLA linker errors Fixed in : 6.4.1 Severity : S1 - Critical / PS Affected Component : Linker Release Notes: When compiling for CLA with the new C2000 CGT v6.4 compiler, the linker will generate errors if old linker command files are used. A patch will be released within the next couple of weeks to avoid this problem. Workaround: Make the following changes to the linker command file: 1) Remove the following: --undef_sym=__cla_scratchpad_end --undef_sym=__cla_scratchpad_start 2) Add the following: .scratchpad : > CLARAM1, PAGE = 1 ------------------------------------------------------------------------------- FIXED SDSCM00051241 ------------------------------------------------------------------------------- Summary : Output section splitting creates a zero-length section Fixed in : 6.4.1 Severity : S2 - Major Affected Component : ELF Linker Release Notes: In certain rare cases, the linker might split an output section into several output sections such that one of them had zero length. The linker really ought not to create split zero-length sections, as it doesn't improve the linkability of the program. This can only happen if one of the input sections is of zero length. Defect occurs in C2000 Compiler versions: 5.2.0B1 - 5.2.15, 6.0.0B1 - 6.0.6, 6.1.0B1 - 6.1.10, 6.2.0B1 - 6.2.10, 6.4.0B1 - 6.4.0 Workaround: 1) Do not split the section in question. 2) Change the zero-length section so that it has at least one more byte. =============================================================================== 9. Defects fixed in C2000 Code Generation Tools release 6.4.0 =============================================================================== The following 12 defects were fixed in C2000 Code Generation Tools release 6.4.0, released November 2014. ------------------------------------------------------------------------------- FIXED SDSCM00049638 ------------------------------------------------------------------------------- Summary : C code that reuses the same pointer a lot sees code size that is almost 3X bigger than before Fixed in : 6.4.0 Severity : S2 - Major Classification : Performance Affected Component : C/C++ Compiler (cl) Release Notes: The attached test case has lots of lines that look like ... ptr->array1[index] = ... ptr->array2[index] = ... ptr->array3[index] = ... The ptr never changes, but many other things do. I'm not sure this is central to the problem, but it certainly seems that way. The code generated by version 6.2.5 is nearly 3X larger than code generated with version 6.1.5. Defect occurs in C2000 Compiler versions: 6.2.0B1 - 6.2.9 Workaround: Make these changes to the build options. - Change --opt_level=2 to --opt_level=1 - Add the option --opt_for_speed=0 These changes avoid most of the code size increase, but not all of it. To see how you could apply these build option changes to only one file in a CCS project, please see http://processors.wiki.ti.com/index.php/Projects_an- d_Build_Handbook_for_CCS#File_specific_options ------------------------------------------------------------------------------- FIXED SDSCM00049909 ------------------------------------------------------------------------------- Summary : CLA compiler generates an internal error when indexing into an array without optimization enabled Fixed in : 6.4.0 Severity : S2 - Major Affected Component : Code Generator Release Notes: This bug is much more likely to occur if optimization is turned off. In many cases, setting the optimization level to 0 will resolve the issue. Defect occurs in C2000 Compiler versions: 6.1.7 - 6.1.8, 6.2.6 Workaround: Try turning optimization on. ------------------------------------------------------------------------------- FIXED SDSCM00049997 ------------------------------------------------------------------------------- Summary : Loop with volatile loop control expression removed Fixed in : 6.4.0 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: In some cases, the optimizer can remove apparently-empty loops that have a loop test which compares the loop control variable with a volatile value. This is not legal; the volatile value could change, so the loop must be left in the code. Defect occurs in C2000 Compiler versions: 5.2.0B1 - 5.2.15, 6.0.0B1 - 6.0.6, 6.1.0B1 - 6.1.7, 6.2.0B1 - 6.2.6, 6.3.0B1 Workaround: Declare the loop counter variable as volatile ------------------------------------------------------------------------------- FIXED SDSCM00050023 ------------------------------------------------------------------------------- Summary : SIGSEGV when using pragma on a template function Fixed in : 6.4.0 Severity : S2 - Major Affected Component : Parser Release Notes: The compiler may emit an internal error (SIGSEGV) when the user attempts to apply a pragma to a template class function. Defect occurs in C2000 Compiler versions: 5.2.0B1 - 5.2.15, 6.0.0B1 - 6.0.6, 6.1.0B1 - 6.1.7, 6.2.0B1 - 6.2.6, 6.3.0B1 Workaround: Do not apply any pragma to a template function. Move the function outside the template class. ------------------------------------------------------------------------------- FIXED SDSCM00050202 ------------------------------------------------------------------------------- Summary : MISRA-C rule 19.11 false positive Fixed in : 6.4.0 Severity : S3 - Minor Affected Component : Parser Release Notes: A violation of MISRA-C rule 19.11 may be falsely detected when a use of an undefined macro is guarded by a check to make sure that the macro is defined before use: #undef X #if defined(X) && X ... #endif Workaround: Disable MISRA-C rule checking for 19.11 around the affected lines: #pragma CHECK_MISRA("-19.11") ... #pragma RESET_MISRA("19.11") ------------------------------------------------------------------------------- FIXED SDSCM00050227 ------------------------------------------------------------------------------- Summary : Illegal use of control register when setting all bits in IFR Fixed in : 6.4.0 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: Sometimes the compiler will turn IFR |= 0xffff into IFR = 0xffff and then declares that this is an illegal use of IFR. The compiler should match IFR = 0xffff with an OR, as it matches IFR = 0 with IFR &= 0. Defect occurs in C2000 Compiler versions: 5.2.0B1 - 5.2.15, 6.0.0B1 - 6.0.6, 6.1.0B1 - 6.1.8, 6.2.0B1 - 6.2.6, 6.3.0B1 Workaround: Split the write to IFR into two parts that together contain all of the bits: IFR |= 0xff00; IFR |= 0x00ff; ------------------------------------------------------------------------------- FIXED SDSCM00050243 ------------------------------------------------------------------------------- Summary : Scary but harmless warning: FAILURE in mark_use_of_function_local_static() Fixed in : 6.4.0 Severity : S2 - Major Affected Component : Optimizer Release Notes: Compiling for C++ and using -pm or -o4 may produce a warning like FAILURE in mark_use_of_function_local_static() fname1: __sti fname2: __sti_ symbol: _$P$T62$2$1 This warning, despite its dramatic wording, is harmless. The compiler will build the program just as it should, and the warning does not indicate any change in behavior. It's a debugging message that should not have been visible outside the development team. Defect occurs in C2000 Compiler versions: 5.2.0B1 - 5.2.15, 6.0.0B1 - 6.0.6, 6.1.0B1 - 6.1.8, 6.2.0B1 - 6.2.7 Workaround: Avoid -pm or -o4. But the warning doesn't indicate any change of the compiler's behavior, so you might as well ignore it. ------------------------------------------------------------------------------- FIXED SDSCM00050302 ------------------------------------------------------------------------------- Summary : Assembler emits spurious ECN error Fixed in : 6.4.0 Severity : S2 - Major Affected Component : Assembler Release Notes: The compiler can emit code that triggers a spurious error for FPU MMWRITE ECN2 (see SDSCM0045587). In this case, the assembly code has a MOV32, followed by an unconditional branch to another location, followed by a F32TOUI32. The assembler incorrectly emits the ECN error because it does not realize that control flow cannot reach the F32TOUI32 from the MOV32. Defect occurs in C2000 Compiler versions: 6.0.5 - 6.0.6, 6.1.2 - 6.1.8, 6.2.0B1 - 6.2.7 Workaround: Adjust the optimization level, or place part of the expression in a volatile variable. ------------------------------------------------------------------------------- FIXED SDSCM00050763 ------------------------------------------------------------------------------- Summary : Only the C6000 compiler accepts the GCC builtin function __builtin_constant_p Fixed in : 6.4.0 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: Error emitted that GNU __builtin_constant_p function not supported. Workaround: None. ------------------------------------------------------------------------------- FIXED SDSCM00050967 ------------------------------------------------------------------------------- Summary : Compiler generates incorrect code for a sequence that swaps two values Fixed in : 6.4.0 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: Attempting to find min/max sequences to be replaced with intrinsics Workaround: Either: 1) Insert an assembly statement between the first two assignments of the swap, such as asm(" NOP"); 2) Don't run the optimizer for the affected file ------------------------------------------------------------------------------- FIXED SDSCM00051097 ------------------------------------------------------------------------------- Summary : Output section splitting creates a zero-length section Fixed in : 6.4.0 Severity : S2 - Major Affected Component : ELF Linker Release Notes: In certain rare cases, the linker might split an output section into several output sections such that one of them had zero length. The linker really ought not to create split zero-length sections, as it doesn't improve the linkability of the program. This can only happen if one of the input sections is of zero length. Defect occurs in C2000 Compiler versions: 5.2.0B1 - 5.2.15, 6.0.0B1 - 6.0.6, 6.1.0B1 - 6.1.10, 6.2.0B1 - 6.2.9, 6.4.0B1 Workaround: 1) Do not split the section in question. 2) Change the zero-length section so that it has at least one more byte. ------------------------------------------------------------------------------- FIXED SDSCM00051128 ------------------------------------------------------------------------------- Summary : Alias missed on address of local passed as function argument Fixed in : 6.4.0 Severity : S2 - Major Affected Component : Optimizer Duplicate Defects : SDSCM00047553 Release Notes: In certain cases, the compiler may produce incorrect code when a local variable whose address is passed to a function is then modified by the function, such as in the following example (where y is the affected local written by modf()): double f(double x) { double y = 0.; if(modf(x, &y) < 0.) return y - 1; else return y; } Workaround: Use the -ma (--aliased_variables) option. =============================================================================== 10. Defects fixed in C2000 Code Generation Tools release 6.4.0B1 =============================================================================== The following 11 defects were fixed in C2000 Code Generation Tools release 6.4.0B1, released October 2014. ------------------------------------------------------------------------------- FIXED SDSCM00049638 ------------------------------------------------------------------------------- Summary : C code that reuses the same pointer a lot sees code size that is almost 3X bigger than before Fixed in : 6.4.0B1 Severity : S2 - Major Classification : Performance Affected Component : C/C++ Compiler (cl) Release Notes: The attached test case has lots of lines that look like ... ptr->array1[index] = ... ptr->array2[index] = ... ptr->array3[index] = ... The ptr never changes, but many other things do. I'm not sure this is central to the problem, but it certainly seems that way. The code generated by version 6.2.5 is nearly 3X larger than code generated with version 6.1.5. Defect occurs in C2000 Compiler versions: 6.2.0B1 - 6.2.9 Workaround: Make these changes to the build options. - Change --opt_level=2 to --opt_level=1 - Add the option --opt_for_speed=0 These changes avoid most of the code size increase, but not all of it. To see how you could apply these build option changes to only one file in a CCS project, please see http://processors.wiki.ti.com/index.php/Projects_an- d_Build_Handbook_for_CCS#File_specific_options ------------------------------------------------------------------------------- FIXED SDSCM00049909 ------------------------------------------------------------------------------- Summary : CLA compiler generates an internal error when indexing into an array without optimization enabled Fixed in : 6.4.0B1 Severity : S2 - Major Affected Component : Code Generator Release Notes: This bug is much more likely to occur if optimization is turned off. In many cases, setting the optimization level to 0 will resolve the issue. Defect occurs in C2000 Compiler versions: 6.1.7 - 6.1.8, 6.2.6 Workaround: Try turning optimization on. ------------------------------------------------------------------------------- FIXED SDSCM00049997 ------------------------------------------------------------------------------- Summary : Loop with volatile loop control expression removed Fixed in : 6.4.0B1 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: In some cases, the optimizer can remove apparently-empty loops that have a loop test which compares the loop control variable with a volatile value. This is not legal; the volatile value could change, so the loop must be left in the code. Defect occurs in C2000 Compiler versions: 5.2.0B1 - 5.2.15, 6.0.0B1 - 6.0.6, 6.1.0B1 - 6.1.7, 6.2.0B1 - 6.2.6, 6.3.0B1 Workaround: Declare the loop counter variable as volatile ------------------------------------------------------------------------------- FIXED SDSCM00050023 ------------------------------------------------------------------------------- Summary : SIGSEGV when using pragma on a template function Fixed in : 6.4.0B1 Severity : S2 - Major Affected Component : Parser Release Notes: The compiler may emit an internal error (SIGSEGV) when the user attempts to apply a pragma to a template class function. Defect occurs in C2000 Compiler versions: 5.2.0B1 - 5.2.15, 6.0.0B1 - 6.0.6, 6.1.0B1 - 6.1.7, 6.2.0B1 - 6.2.6, 6.3.0B1 Workaround: Do not apply any pragma to a template function. Move the function outside the template class. ------------------------------------------------------------------------------- FIXED SDSCM00050202 ------------------------------------------------------------------------------- Summary : MISRA-C rule 19.11 false positive Fixed in : 6.4.0B1 Severity : S3 - Minor Affected Component : Parser Release Notes: A violation of MISRA-C rule 19.11 may be falsely detected when a use of an undefined macro is guarded by a check to make sure that the macro is defined before use: #undef X #if defined(X) && X ... #endif Workaround: Disable MISRA-C rule checking for 19.11 around the affected lines: #pragma CHECK_MISRA("-19.11") ... #pragma RESET_MISRA("19.11") ------------------------------------------------------------------------------- FIXED SDSCM00050227 ------------------------------------------------------------------------------- Summary : Illegal use of control register when setting all bits in IFR Fixed in : 6.4.0B1 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: Sometimes the compiler will turn IFR |= 0xffff into IFR = 0xffff and then declares that this is an illegal use of IFR. The compiler should match IFR = 0xffff with an OR, as it matches IFR = 0 with IFR &= 0. Defect occurs in C2000 Compiler versions: 5.2.0B1 - 5.2.15, 6.0.0B1 - 6.0.6, 6.1.0B1 - 6.1.8, 6.2.0B1 - 6.2.6, 6.3.0B1 Workaround: Split the write to IFR into two parts that together contain all of the bits: IFR |= 0xff00; IFR |= 0x00ff; ------------------------------------------------------------------------------- FIXED SDSCM00050243 ------------------------------------------------------------------------------- Summary : Scary but harmless warning: FAILURE in mark_use_of_function_local_static() Fixed in : 6.4.0B1 Severity : S2 - Major Affected Component : Optimizer Release Notes: Compiling for C++ and using -pm or -o4 may produce a warning like FAILURE in mark_use_of_function_local_static() fname1: __sti fname2: __sti_ symbol: _$P$T62$2$1 This warning, despite its dramatic wording, is harmless. The compiler will build the program just as it should, and the warning does not indicate any change in behavior. It's a debugging message that should not have been visible outside the development team. Defect occurs in C2000 Compiler versions: 5.2.0B1 - 5.2.15, 6.0.0B1 - 6.0.6, 6.1.0B1 - 6.1.8, 6.2.0B1 - 6.2.7 Workaround: Avoid -pm or -o4. But the warning doesn't indicate any change of the compiler's behavior, so you might as well ignore it. ------------------------------------------------------------------------------- FIXED SDSCM00050302 ------------------------------------------------------------------------------- Summary : Assembler emits spurious ECN error Fixed in : 6.4.0B1 Severity : S2 - Major Affected Component : Assembler Release Notes: The compiler can emit code that triggers a spurious error for FPU MMWRITE ECN2 (see SDSCM0045587). In this case, the assembly code has a MOV32, followed by an unconditional branch to another location, followed by a F32TOUI32. The assembler incorrectly emits the ECN error because it does not realize that control flow cannot reach the F32TOUI32 from the MOV32. Defect occurs in C2000 Compiler versions: 6.0.5 - 6.0.6, 6.1.2 - 6.1.8, 6.2.0B1 - 6.2.7 Workaround: Adjust the optimization level, or place part of the expression in a volatile variable. ------------------------------------------------------------------------------- FIXED SDSCM00050763 ------------------------------------------------------------------------------- Summary : Only the C6000 compiler accepts the GCC builtin function __builtin_constant_p Fixed in : 6.4.0B1 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: Error emitted that GNU __builtin_constant_p function not supported. Workaround: None. ------------------------------------------------------------------------------- FIXED SDSCM00050967 ------------------------------------------------------------------------------- Summary : Compiler generates incorrect code for a sequence that swaps two values Fixed in : 6.4.0B1 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: Attempting to find min/max sequences to be replaced with intrinsics Workaround: Either: 1) Insert an assembly statement between the first two assignments of the swap, such as asm(" NOP"); 2) Don't run the optimizer for the affected file ------------------------------------------------------------------------------- FIXED SDSCM00051050 ------------------------------------------------------------------------------- Summary : Optimization produces incorrect floating point result Fixed in : 6.4.0B1 Severity : S2 - Major Affected Component : C/C++ Compiler (cl) Release Notes: When compiling code involving floating-point multiplication and addition with hardware floating-support enabled, the compiler could turn an instruction sequence "ADDF32 MPYF32" into "MACF32" when it is not legal to do so. This bug will only occur if it just so happens that the compiler used R7 as one of the operands of the ADDF32 instruction, which is not predictable by the user. The level of optimization as well as many other factors will affect whether or not the bug occurs, but it can't be predicted whether higher or lower levels will trigger the bug. Defect occurs in C2000 Compiler versions: 6.2.0B1 - 6.2.9, 6.4.0B1 Workaround: Add option --disable:ank_peep =============================================================================== 11. Current Known Issues =============================================================================== The following 31 known issues exist for C2000 Code Generation Tools release 6.4.10 as of February 2016. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00008248 ------------------------------------------------------------------------------- Summary : Compilers on PC will not work without TMP set Affected Component : C/C++ Compiler (cl) Duplicate Defects : SDSCM00034609 Description: When compiling on the PC, the code generator cannot find the icode file produced by the parser if the environment variable TMP is no set. If TMP is set, then all appears well. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00008465 ------------------------------------------------------------------------------- Summary : Language Conformance: crash because of void pointer dereference Affected Component : Parser Description: Compiler generates multiple INTERNAL ERRORs when code like the following is compiled: void dr106_1(void *pv, int i) { *pv; i ? *pv : *pv; *pv, *pv; } ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00008534 ------------------------------------------------------------------------------- Summary : Linker -xml_link_info option doesn't work when in a command file Affected Component : Linker Description: The option --xml_link_info=file.xml does not work when it is placed inside a linker command file. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00008537 ------------------------------------------------------------------------------- Summary : assembler expression ~(0x80000000) evaulates as 0x80000000 Affected Component : Assembler Description: The following expression is evaluating incorrectly in the assembler: .eval ~(0x80000000), mask mask ends up getting assigned 0x80000000, whereas I expect it to be 0x7FFFFFFF. It seems that any constant with bit 31 set will incorrectly return 0x80000000 ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00008543 ------------------------------------------------------------------------------- Summary : Forward reference in .space generates an internal error Affected Component : Assembler Description: If you attempt to assemble: .space 0+a b a .set 1 the assembler will generate an internal error. This happens with v3.83 and v4.1.0B1 on Solaris. If you change the code to: .space a b b .set 1 the correct error message is generated, 'Absolute, well-defined integer value expected'. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00008652 ------------------------------------------------------------------------------- Summary : pow(2,x) has fairly significant rounding error Affected Component : Runtime Support Libraries (RTS) Description: The algorithm used for pow [exp(log(x),y)] is correct but sometimes leads to a precision error for some inputs, due to rounding bugs in floating- point handling. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00008685 ------------------------------------------------------------------------------- Summary : DWARF does not correctly represent variables stored in register pairs Affected Component : Code Generator Description: In the attached example, variables 'var1' and 'var2' are both long long types, and are stored in A7:A6 and B5:B4. However, the DWARF information shows var1 only to be in A6, and var2 only to be in B4: [000000e8] DW_TAG_variable DW_AT_name var1 DW_AT_symbol_name _var1 DW_AT_type [00000113] DW_AT_location { DW_OP_reg6 } [000000fa] DW_TAG_variable DW_AT_name var2 DW_AT_symbol_name _var2 DW_AT_type [00000113] DW_AT_location { DW_OP_reg20 } ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00008928 ------------------------------------------------------------------------------- Summary : Extern inline functions are not supported in the C/C++ Compiler Affected Component : Parser Duplicate Defects : SDSCM00018364 Description: Users cannot create global accessible code with INLINE functions. The V3.00 compiler/code generator does not create globally accessible code for functions which are declared inline. A simple example is: inline int x() { return 1; } int y() {return 2;} When compiled with 'cl6x -k -c test.c', a warning is produced: 'test.c', line 1: warning: function 'x' was declared but never referenced and the resulting assembler file (test.asm) does not contain any code for x(). The documentation states that code declared inline will be inlined in that module but global code will also be generated (section 2.10.3.2 in v3.00 C Compiler manual). The new compiler is overly aggressive in its optimizations. If y() is modified to call x() then code is generated for x() unless the optimizer is also invoked (by using -x2). ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00014430 ------------------------------------------------------------------------------- Summary : calloc doesn't check arguments to make sure the requested size is reasonable Affected Component : Runtime Support Libraries (RTS) Description: The function calloc() is required to return a pointer to memory representing "nelem" copies of "size" bytes, or NULL if the request cannot be satisfied. However, for some values of "nelem" and "size" (specifically when the result of nelem*size wraps around), calloc can return a pointer to an object that is not large enough, rather than NULL. For example, on a 32-bit target, if the user calls calloc(0x00010001, 0x00010001), even though each argument by itself is reasonable, the request cannot be satisfied because the product is 0x000100020001, which exceeds size_t. (Note that we cannot check for overflow by checking if the product is less than either argument, which is commonly done for unsigned addition.) Arguably, we can try to claim that it is undefined behavior to make a call to calloc where the product would exceed size_t, but there doesn't seem to be anything in the standard which says so. The problem is worse on 16-bit targets, where calloc(0x0101, 0x0101) is enough to overflow size_t. It may not be obvious to the user that this overflows. Another concern is that it is hard to figure out whether a multiplication will overflow without having a double-width multiply available. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00016638 ------------------------------------------------------------------------------- Summary : dis2000 does not handle disassembly of expanded BCND instruction properly Affected Component : Disassembler (dis) Description: When C2XLP-specific instruction BCND is specified with multiple condition operands, the disassembly output does not show the expanded instruction sequence properly. Source code is attached, assemble with "asm2000 -v28 -m20 bcnd.asm", then disassemble with "dis2000 bcnd.obj > bcnd.dis". Observe disassembly of sequence of instructions that BCND expands to and you'll notice that the disassembly of the XB instruction encoding is not handled properly. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00016646 ------------------------------------------------------------------------------- Summary : strcmp doesn't correctly handle values with uppermost bit set Affected Component : Runtime Support Libraries (RTS) Description: The standard says: "The sign of a nonzero value returned by the comparison functions memcmp, strcmp, and strncmp is determined by the sign of the difference between the values of the first pair of characters (both interpreted as unsigned char) that differ in the objects being compared." However, this is a problem for 16-bit targets where the size of char is the same as the size of int. In this case, it's easy to mistakenly use an unsigned subtract to do the comparison and return it directly; this value can overflow. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00018691 ------------------------------------------------------------------------------- Summary : Linker gives misleading warning when dot expressions used in SECTION directive for .stack section Affected Component : Linker Description: Linker gives the warning: warning: creating ".stack" section with default size of 0x800; use the -stack option to change the default size even when the application does not link in boot code from RTS lib. A linker command file is used that contains a specialized SECTION directive for the ".stack" section. Because of a series of ". += " assignments in the section spec, the linker is forced to increase the size of the .stack section to 0xc00. The linker is doing the correct thing by making a .stack section large enough to accommodate the dot expressions, but the diagnostic is misleading, as 0x800 isn't the final size of the .stack section. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00037411 ------------------------------------------------------------------------------- Summary : C2000 assembler segmentation fault on RPTB with syntax error Affected Component : Assembler Description: The C2000 assembler will issue a segmentation fault if given a RPTB instruction with faulty syntax. The syntax error is not issued. The attached file rptb_mov32_FAIL.asm illustrates the problem. cl2000 --float_support=fpu32 -v28 rptb_mov32_FAIL.asm INTERNAL ERROR: asm2000 experienced a segmentation fault while processing section .text file rptb_mov32_FAIL.asm line 23 This is a serious problem. Please contact Customer Support with this message and a copy of the input file and help us to continue to make the tools more robust. >> Compilation failure We should see a syntax error on the RPTB instruction on line 21 of the input file. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00037836 ------------------------------------------------------------------------------- Summary : boot-time copy table (BINIT) not implemented in C2000 RTS Affected Component : Runtime Support Libraries (RTS) Description: The BINIT feature to trigger a copy-in at boot time is not implemented in the RTS library. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00039054 ------------------------------------------------------------------------------- Summary : Compiler reports a violation of Misra rule 12.8 for a structure variable Affected Component : C/C++ Compiler (cl) Description: MISRA warning (MISRA-C:2004 12.8/R) The right-hand operand of a shift operator shall lie between zero and one less than the width in bits of the underlying type of the left-hand operand In the following code I get MISRA 12.8 warning on myVar = myStruct.aVar >> 16 shift. Note that shift of unstructured variable myVar = myVar >> 16 is okay. typedef struct { unsigned long aVar; } myStruct_T; myStruct_T myStruct = {0xFFFFFFFFUL}; unsigned long myVar; myVar = myStruct.aVar >> 16; myVar = myVar >> 16; ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00039236 ------------------------------------------------------------------------------- Summary : Sometimes MISRA rule 19.15 is incorrectly emitted. The rule is about failing to use an inclusion guard in a header file. Affected Component : Parser Description: In the attached test case rule 19.15 gets emitted even though the files mentioned do have proper inclusion guards. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00040934 ------------------------------------------------------------------------------- Summary : Structure is not initialized correctly when using -o2 or -o3 optimization Affected Component : Optimizer Description: There is a problem with the initialization of a structure using symbols generated in the linker command file. We use symbols generated in the linker cmd file using the dot operator. These symbols are used as an initial value for a class/struct with a constructor. In our case we want the difference of two addresses that the linker generates. When using optimization -o2 or -o3, the compiler generates .cinit entries instead of the constructor call. In those .init-entries it doesn't use the difference of the addresses; instead it uses the first symbol. When turning off optimization or using lower level of opt than -o2, the constructor calls are generated and the struct is initialized correctly. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00042434 ------------------------------------------------------------------------------- Summary : Compiler misreports Misra warning 6.4 for bitfield definitions Affected Component : C/C++ Compiler (cl) Duplicate Defects : SDSCM00043122 Description: Compiler misreports Misra warning 6.4 for bitfield definitions. typedef unsigned int uint16_t; typedef unsigned int bool_t; #define FALSE ((bool_t)0U) #define TRUE ((bool_t)1U) typedef struct mystructtag { uint16_t u16_hw_rev1; bool_t bl_hardware_supported:1; /* this violates rule 6.4 */ } st_software_info_t ; This generates the warning: "misra_test.c", line 9: warning: (MISRA-C:2004 6.4/R) Bit fields shall only be defined to be of type unsigned int or signed int Related forum thread: http://e2e.ti.com/support/development_tools/compiler/f/343/t/147639.aspx According to Misra, this is not a Misra violation. http://www.misra- c.com/forum/viewtopic.php?f=62&t=1167&sid=6fd53ec7591d33a4fa1b38e975c580bc ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00042435 ------------------------------------------------------------------------------- Summary : Compiler misreports Misra warning 10.1 Affected Component : C/C++ Compiler (cl) Description: Compiler misreports Misra warning 10.1 with the following code: typedef unsigned int uint16_t; typedef unsigned int bool_t; #define FALSE ((bool_t)0U) #define TRUE ((bool_t)1U) typedef struct mystructtag { uint16_t u16_hw_rev1; bool_t bl_hardware_supported:1; /* this violates rule 6.4 */ } st_software_info_t ; void main(void) { uint16_t u16_rev1_min, u16_tmp; st_software_info_t sts_sw_info; u16_rev1_min = 900U; sts_sw_info.bl_hardware_supported = FALSE; if (sts_sw_info.bl_hardware_supported == FALSE) /* this violates rule 10.1 */ { /* do something... */ } if (sts_sw_info.u16_hw_rev1 >= u16_rev1_min) /* this violates rule 10.1 */ { /* do something... */ } u16_tmp = sts_sw_info.u16_hw_rev1; if (u16_tmp >= u16_rev1_min) /* this does not violates rule 10.1 */ { /* do something... */ } The warning is: "misra_test.c", line 22: warning: (MISRA-C:2004 10.1/R) The value of an expression of integer type shall not be implicitly converted to a different underlying type if it is not a conversion to a wider integer type of the same signedness "misra_test.c", line 27: warning: (MISRA-C:2004 10.1/R) The value of an expression of integer type shall not be implicitly converted to a different underlying type if it is not a conversion to a wider integer type of the same signedness Related forum thread:http://e2e.ti.com/support/development_tools/compiler/f/3- 43/t/147639.aspx Related Misra threads that say this is not a Misra violation: http://www.misra- c.com/forum/viewtopic.php?f=62&t=1167&sid=6fd53ec7591d33a4fa1b38e975c580bc http://www.misra- c.com/forum/viewtopic.php?f=66&t=1168&sid=6fd53ec7591d33a4fa1b38e975c580bc ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00043043 ------------------------------------------------------------------------------- Summary : Array that is correctly initialized erroneously gets a MISRA diagnostic about size not being specified Affected Component : C/C++ Compiler (cl) Description: For this input ... int16_t y[]={1,5,8}; The compiler incorrectly issues this diagnostic ... "try1.c", line 2: warning: (MISRA-C:2004 8.12/R) When an array is declared with external linkage, its size shall be stated explicitly or defined implicitly by initialisation ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00044056 ------------------------------------------------------------------------------- Summary : Compiler misreports Misra warning 10.1 Affected Component : C/C++ Compiler (cl) Description: Compiler misreports MISRA warning 10.1/R for the following code. typedef enum _MyEnum { One, Two } MyEnum; MyEnum MyVariable; int foo(void) { int result = 1; if (One == MyVariable) // fails here with MISRA-C:2004 10.1/R { result = 2; } return result; } Our coding style convention requires that the variable is at the right hand side. Therefore I don't want to swap One and MyVariable, although that makes the warning to disappear. Is that a bug in the MISRA checker? If not, why is the comparison of two terms not commutable? ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00045452 ------------------------------------------------------------------------------- Summary : Compiler misreports MISRA warning 17.6 Affected Component : C/C++ Compiler (cl) Description: Compiler misreports MISRA warning 17.6 with the attached code. (MISRA-C:2004 17.6/R) The address of an object with automatic storage shall not be assigned to another object that may persist after the first object has ceased to exist In the following code, the assignment of &myLocalStruct->data to myDataPtr in myFunc has MISRA 17.6 reported. myDataPtr only persists for the duration of the function, and therefore does not persist longer than data passed into that function. typedef struct { uint8 data; } Struct_T; void myFunc(Struct_T *myLocalStruct); void main(void); void myFunc(Struct_T *myLocalStruct) { uint8 *myDataPtr; myDataPtr = &myLocalStruct->data; /* (MISRA-C:2004 17.6/R) reported here */ } void main(void) { Struct_T myStruct = { 0U }; myFunc(&myStruct); } ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00045473 ------------------------------------------------------------------------------- Summary : Compiler misreports violation of Misra 9.2 for zero initialization of structures Affected Component : C/C++ Compiler (cl) Description: Compiler misreports violation of Misra 9.2 for zero initialization of structures. (MISRA-C:2004 9.2/R) Braces shall be used to indicate and match the structure in the non-zero initialisation of arrays and structures typedef struct { unsigned char nModuleId; unsigned char nInstanceId; unsigned char nApiId; unsigned char nErrorId; } DetLog_T; DetLog_T sctDetLog_M[0x100] = { 0U }; ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00048321 ------------------------------------------------------------------------------- Summary : C2000 binary file IO does not handle char data with more than 8-bits of data Affected Component : Runtime Support Libraries (RTS) Description: On C2000 a char is 16 bits, but the fread and fwrite functions will only read and write the lower 8 bits of every char. The problem looks to be in the __TI_writemsg/__TI_readmsg functions and the PACKCHAR macro. The macro only writes the lower 8 bits, but the function increments by 16 bits for every invocation of PACKCHAR. I'm not sure which piece is wrong. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00049284 ------------------------------------------------------------------------------- Summary : Compiler misreports Misra warning 10.1 Affected Component : Parser Description: Compiler misreports MISRA warning 10.1/R for the following code. typedef enum _MyEnum { One, Two } MyEnum; MyEnum MyVariable; int foo(void) { int result = 1; if (One == MyVariable) // fails here with MISRA-C:2004 10.1/R { result = 2; } return result; } ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00050131 ------------------------------------------------------------------------------- Summary : Local struct with non-constant initializer treated as static scope variable Affected Component : Parser Description: We've discovered a problem where the C++ compiler places a local structure variable not on the stack but in the data segment, as if it was a static structure. The problem is especially insidious because the issue will only have an impact on re-entrance. The problem seems to occur only for C++ files, and only if the structure initializer list contains a variable. Constant initializer lists do not trigger the issue. The structure in the first function will be allocated on the stack, but the structure in the second will be compiled as if it was declared static. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00050540 ------------------------------------------------------------------------------- Summary : CLA Assembler accepts invalid instruction MMOV32 mem, MRn, COND Affected Component : Assembler Description: The CLA assembler accepts and invalid instruction and encodes a different instruction, generating an object file. See the attached assembly and disassembly output. There is no conditional MMOV32 to a memory destination. The only valid conditional MMOV32 instructions have register (MRn) destinations. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00051315 ------------------------------------------------------------------------------- Summary : The type _Bool is illegal by default only for CLA code Affected Component : C/C++ Compiler (cl) Description: Any use of the built-in type _Bool is not allowed in CLA code. But it is allowed in C code. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00052021 ------------------------------------------------------------------------------- Summary : Compiler incorrectly issues MISRA warnings 10.1 and 10.3 in some circumstances Affected Component : C/C++ Compiler (cl) Description: For this code ... typedef unsigned int ui; ui x; ui *px; void fxn(void); void fxn(void) { px = &x; /* 10.1 warning */ px = (ui *)&x; /* 10.3 warning */ } The compiler issues MISRA warnings 10.1 and 10.3. This appears to be an error in the compiler. ------------------------------------------------------------------------------- KNOWN ISSUE SDSCM00052276 ------------------------------------------------------------------------------- Summary : hex2000, while using -b option, mistakenly states a section "falls in unconfigured memory" Affected Component : Hex Converter (hex) Description: Through the utility tiobj2bin.bat, the customer invokes the hex utility in this manner ... % hex2000 -q -b -image -o output.bin hhh.txt file.out Where hhh.txt contains ... ROMS { all_mem: o = 0x7c0000, l = 0x2fff0 } Because -b is used, -memwidth=8 is implied. With that option, all addresses (which count in terms of 16-bit words) must be doubled. The first initialized section preset is at address 0x3e0000. Double that to get 0x7c0000. Even so, when hex2000 runs, it issues the following ... warning: section file.out(preset) at 07c0000h falls in unconfigured memory (skipped)