CCES 2.8.1.0 bug list:
- Indexer gets “stuck”. Files show a red error symbol even if the file builds without errors. No amount of rebuilding the index will remove these.
- Environment does not parse .asm files (though the indexer seems to be doing something, see below). For example, if something is not defined (i.e. #if defined(__BYTE_ADDRESSING__) ) that section should be grayed out but it isn’t.
- Environment hangs when opening .asm files that have more than a few dozen lines. It can take several minutes for the program to become responsive again.
- Project builds are very slow. On a very fast computer with parallel build enabled building a moderate project from scratch takes well over 10 minutes. The odd thing is that the compiler reports it completed compilation in, say, 500ms but the time between when you build a file and the console actually reports the build is finished is 10 times longer.
- Environment cannot find library header files if a file of the same name is in one of the project paths. For example we have a file named filter.h in one of our project paths. Any files that use library filter functions, i.e. <filter.h> do not find the library header.
- Related to above any files using header files that match a file of the same name in the project path do not build properly since there is no linkage information (i.e. linker error – symbol not resolved).
- Adding a symbol via Properties -> C/C++ General -> Paths and Symbols corrupts the project and causes all symbols and paths for the compiler to be deleted. No recovery is possible. Even clicking Cancel does not correct the project. Severity – EXTREMELY SEVERE!!!
- Related to above, adding a path via Properties -> C/C++ General -> Paths and Symbols does NOT add that path to the compiler preprocessor paths. In Eclipse-based tools the preferred way to add symbols and paths is via Properties -> C/C++ General -> Paths and Symbols. This does not work properly as the compiler settings do not reflect the general settings.
- Can't single step in assembly. Goes into dispatcher (?).
- Can't delete completed tasks.
- Frequent freezes, especially when large files are open in the editor.
- "Phantom" breakpoints. No breakpoints shown but code stops at breakpoint.
- When a breakpoint is reached the program counter will never advance. Can't step or run to line or next breakpoint. Have to disable breakpoint. This is atypical breakpoint behavior and extremely annoying causing debugging to be a laborious procedure.
- Starting a debug session takes an extremely long time, even when the projects are up-to-date and do not need to be built.
- Expressions window doesn't show addresses.
- No "mixed" mode in C editor. Assembly listing is useless.
- If an assembly file has been edited and you select "Build Project" the assembly file isn't saved.
- Step functions (step into/over/return) are useless. They cause the core to hang requiring a hard restart.
- #pragma align is not honored for stack variables (automatics) even though the stack is aligned (-no-align-stack is false).
- If you edit the .ldf and then change the stack, heap, etc. from system.svc all your changes are lost.
- Terminating a debug session can cause edit history to be lost (can't undo edits to a file).
- Reloading program or loading a new program when stopped at a breakpoint causes core hang.
- No mention in migration guide that 40-bit loading is different from previous products (spent three days trying to figure that out).
- Automatic inlining (-0a) results in illegal instructions.
- If you edit a file and then build just that file and then build the project the file is built again. Since we have some files that take over a minute to compile this is a waste of time.
- Compiler/assembler will randomly report that it can't find a .xml file and abort.
In general CCES is a steaming pile of garbage. I realize that Eclipse-based tools are all the rage because they reduce the time needed to create and maintain the tools but CCES is pretty bad. We have four Eclipse-based development environments and CCES, while not the worst, is very bad. And it's the only one that's not free. TI's Code Composer studio puts CCES to shame and it's free and they are constantly updating and fixing bugs. There hasn't been a single update to CCES since we started it using it months ago. Some of the bugs listed above are inexcusable and others are just downright annoying. Overall using CCES is a frustrating affair. The frequent freeze-ups, the agonizingly slow performance and the raft of bugs make for a tedious and frustrating development experience. VisualDSP++ was a fantastic development environment: fast, full-featured and a pleasure to use. CCES is a huge step backwards and seems to have thrown away all the best features of VisualDSP++ and kept the annoying bits.
Oh, it looks like the environment has finally returned from one of its frequent freezes so I can get back to self-immolation now...
