Bugs Galore

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...

  • 0
    •  Analog Employees 
    on Dec 31, 2018 12:51 PM

    Hi,

    - 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.
    >> To assist you better, could you please share the screenshot for this
    >> issue

    - 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.
    >> The build time issue is almost certainly the assembler XML issue addressed in 2.9.0. Can you please confirm this by adding the –time switch to the compiler and assembler additional options and see that the compiler takes about the same time whilst the assembler takes a lot longer.
    Also can you please share us your example project with the steps to reproduce the issue. This will help us to assist you further.

    - 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!!!
    >> We are not able to simulate this issue. Please let us know if you facing this issue with all projects or with any specific project? Can you please try with simple project and let us know how you gets on.

    - 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.
    >> Please ensure that you have added the path via Properties -> C/C++ General -> Paths and Symbols -> Include tab -> C/C++ with ADI extensions.
    Adding the path in "ADI Assembly" will reflect in Assembler preprocessor paths Adding the path in "C/C++ with ADI extensions" will reflect in Compiler preprocessor paths Adding the path in "Object files" will reflect in Linker preprocessor paths

    - Can't single step in assembly. Goes into dispatcher (?).
    - Step functions (step into/over/return) are useless.  They cause the core to hang requiring a hard restart.
    >> The stepping problem you are encountering is most likely caused by interrupts within your system. Although the processor is halted when you are stepping, the peripherals such as DMA, sports and timers continue to run. Consequently, they produce interrupts which the core latches. So, you may find it to be the case that instead of stepping into the function, the debugger actually steps into the ISR. Once the ISR is complete, the PC is back to the original instruction being stepped. Additionally, there is a breakpoint there which halts execution before entering the desired function (before the step-in has completed). So, the 'Step Over', or when running from a breakpoint, appears to stay at the same PC, while the 'Step Into' can result in the Halt occurring within the ISR.

    There is an option you can enable that should help with this problem.Please try to step over after enabling 'Mask interrupts during step' under 'Target > Settings > Target Options' in debug perspective.

    The Target menu is available only for emulator connections, once you load your application and select a core.

    - Can't delete completed tasks.
    >> Could you please explain the issue in detail so that we can assist you better.

    - 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.
    - Frequent freezes, especially when large files are open in the editor.
    >> Please refer the below FAQ:
    FAQ: Reporting a Crash or Hang in CrossCore Embedded Studio
    https://ez.analog.com/dsp/software-and-development-tools/cces/w/documents/5318/faq-reporting-a-crash-or-hang-in-crosscore-embedded-studio

    It would also be useful if you could create a .zip file with the .metadata directory that's located in your work space directory and attach it to your e-mail.  The .metadata directory includes your work space preferences, launch configuration settings, and a log of what commands were executed during your debug session.
     
    If you have a project to reproduce the crash or hang, it would be helpful to include as well.

    - Expressions window doesn't show addresses.
    >> Select the Address in the Expression window > View Menu > Layout > Select Columns > Address.
    Now you can able to see Address of variable in the expression window. (Please refer Image1 & Image2)

    - No "mixed" mode in C editor.  Assembly listing is useless.
    >> You cannot view the disassembly in the source window as you did with VisualDSP++. We don't believe there are any plans in the Eclipse Community to enable such behaviour. Instead, the Disassembly Window can display the source. If you right-click in the disassembly window, there are options to 'display symbols' and 'display source'.
    Also, you can enable the 'Save temporary files' option which is found by selecting Project->Properties->C/C++ build->Settings->C/C++  Compiler->General. This will save all the *.s assembly files generated by the compiler for any C source.

    - If you edit the .ldf and then change the stack, heap, etc. from system.svc all your changes are lost.
    >> Any hand-edits you make within the LDF file in a Source Window should be made within the generated $VDSG sections, to preserve them if/when the LDF is automatically regenerated by the tools. Below is an example:
    /*$VDSG<insert-......>                            */
    /* Text inserted between these $VDSG comments will be preserved */
     /*$VDSG<insert-.....>                            */

    - Reloading program or loading a new program when stopped at a breakpoint causes core hang.
    >> We are not able to simulate this issue. Can you please share us the sample project with steps to reproduces this issue so that we can assist you better.

    We are looking in to the remaining issues, We will get back to you as soon as possible.

    Regards,

    Santha kumari.K


  • - 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.
    >> The build time issue is almost certainly the assembler XML issue addressed in 2.9.0. Can you please confirm this by adding the –time switch to the compiler and assembler additional options and see that the compiler takes about the same time whilst the assembler takes a lot longer.
    Also can you please share us your example project with the steps to reproduce the issue. This will help us to assist you further.

    >>> We cannot share the project.  It is huge (100 thousand lines at least) and full of proprietary content.  Every engineer working on the project is experiencing the same problem.  It is a systemic issue in CCES. 

    - Expressions window doesn't show addresses.
    >> Select the Address in the Expression window > View Menu > Layout > Select Columns > Address.
    Now you can able to see Address of variable in the expression window. (Please refer Image1 & Image2)

    >>> There is no option to select address.  We are using CCES 2.8.1.0.

    >> Please ensure that you have added the path via Properties -> C/C++ General -> Paths and Symbols -> Include tab -> C/C++ with ADI extensions.

    >>> This is what we are doing.  It does not work.  The paths and symbols are NOT added to the compiler path.

    - Can't delete completed tasks.
    >> Could you please explain the issue in detail so that we can assist you better.

    >>> When you insert "// TODO" into a file this creates a task.  This task shows up in the task tab.  If you then finish the task and delete "// TODO" the task is NOT removed from the task list.  This makes the task list useless.

    - Frequent freezes, especially when large files are open in the editor.
    >> Please refer the below FAQ:
    FAQ: Reporting a Crash or Hang in CrossCore Embedded Studio
    https://ez.analog.com/dsp/software-and-development-tools/cces/w/documents/5318/faq-reporting-a-crash-or-hang-in-crosscore-embedded-studio

    >>> Myself and four other engineers are all experiencing the same freezes and hangs.  There is a systemic issue in CCES.  The FAQ is just an excuse to not address the issue.

  • 0
    •  Analog Employees 
    on Jan 2, 2019 12:00 PM

    Hi,

    Thanks for the feedback. I'm going to work through them and see what I can recommend or enter bug tracker entries to improve things.

    Regarding the build time, we've released a version 2.8.2 which addresses an XML access issue which caused a significant degradation. Can you confirm if that makes any difference and if needs be we can see if we can make further improvements elsewhere.

    Regarding the startup/ldf being overwritten, this is because the files are generated from configations within the system.svc file. We provide some sections which are preserved, which look like this:
    /*$VDSG<insert-libraries-internal>                              */
    /* Text inserted between these $VDSG comments will be preserved */
    /*$VDSG<insert-libraries-internal>

    Any code inserted between the $VDSG comments will be preserved over regeneration, with anything else being lost. There should be sufficient preserve blocks here to allow you to customize anything you need, but if you feel others are necessary please let me know so we can look at adding them.

    Regarding the re-building on Debug session launch, this can time-consuming for large projects but can be disabled the Preferences dialog (under the Window menu). The option is "Build (if required) before launching", under Run/Debug > Launching. You'll then need to be careful that you are re-building any appropriate changes manually before launching any debug sessions.

  • Our license is for 2.8.1.  If we install 2.8.2 will this invalidate our license?  We couldn't even upgrade from 2.7 to 2.8 without buying all new licenses and I refuse to buy all the licenses a third time.

  • 0
    •  Analog Employees 
    on Jan 3, 2019 11:42 AM in reply to Lemmiwinks

    The license without subscription is good for 1 year of updates, so you shouldn't have any problem moving from 2.8.1 to 2.8.2.