This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Optimizing the DSP_BIOS_config.tcf to speed up debug when using the classic ROV ?



Hi,

I have noticed some CCS12 performance penalties during debug that may have been due to the indexer built into CCS12, however I am noticing that the penalties occur mainly when the ROV (classic) is open during debugging. It may (or may not) be due to the parsing of the .tcf config files that I am using which has over time been modified numerous time and in some cases certain DSP/BIOS configs have been reverted and then changed back etc. and over time this has created a rather large config file. This happens because duplicate changes are not removed and actually retained.

So I am wondering if CCS12 has some built-in DSP-BIOS config file optimizer (cleaner) to remove duplicate entries and keep only the very last entries that represent the latest configuration so as to remove duplicate/redundant entries ?? I am not sure if this might speed up things during debugging but it just seems a coincidence that when I turn the ROV off I am not really seeing the CCS12 debugger churning away every time I re-compile and re-load the program onto the target. Otherwise there would be a manual way of achieving this, but if this feature already exists then where would this be in CCS12 ?

thanks and regards, MM

  • Hello,

    What are some of the performance issues you are seeing with ROV? I assume it is not just with ROV but all of CCS is impacted? Do you see these issues when ROV is simply open and not refreshing the data or anything (like if you halt the target and ROV refreshes the data and the you leave the target halted and do something else in the IDE and it is sluggish)? And if you close the ROV, do the performance issues go away?

    Thanks

    ki

  • Hi Ki,

    It is mainly when I have the classic ROV window open and I'm checking out the trace log. Moving around the interface is not penalized in any way perceivable, however when I go through the load program sequence after some changes to the code, there is a compilation sequence, then the program gets loaded, there is a window showing the status of the load (or it is otherwise shown in the bottom right hand corner with a green bar and percentage of completion), but it seems to also be doing something further and I am not seeing this with the ROV window closed. If I leave the ROV window open throughout the debugging session the penalty accumulates and when the ROV window is closed I'm not seeing this penalty - it kind of does everything normally. Also with an XDS560v2 the actual loading of the .out file is very fast, so this is not the issue, its just the "after churn" that seems to accumulate progressively. Nowdays the "fix" is to open the ROV only when I actually need it, then close it (generally when recompiling and reloading) to prevent excessive after-churn ...

  • in the bottom right hand corner with a green bar

    Can you double-click on that green bar? Doing so should open the "Progress" view which should show all the tasks running in the background and you can get more details.

  • Hi,

    Yes I did double-click on it and it shows : "No operations to display at this time". The green bar continues however to churn for a while and then the ROV windows is updated 100% and the main() entry point is reached - ready for execution.

  • If you disable the indexer, does it help with performance at all?

  • Hello Ki,

    The indexer does not seem to be an issue, as when I don't have a ROV window open to check the traces there is no perceivable delay when re-compiling and reloading a program. It seems to happen when a ROV window is open as I mentioned. So I never switched off the indexer as I might use it for the source code searching (I presume it might make searching more complicated or slower if it is switched off ?!? ).

    My concern is the .TCF config script that contains about 1100 lines of which 15% are probably redundant and don't serve any purpose other than to keep a historical trace of the various changes to the config over time ... I was wanting to look into the possibility that this might be an issue but I am not really familiar with the inner workings of the CCS12 software to say ...

    Regards, MM

  • So I never switched off the indexer as I might use it for the source code searching (I presume it might make searching more complicated or slower if it is switched off ?!? ).

    Yes you would lose all the advanced editor functionality with the indexer turned off. 

    My concern is the .TCF config script that contains about 1100 lines of which 15% are probably redundant and don't serve any purpose other than to keep a historical trace of the various changes to the config over time ... I was wanting to look into the possibility that this might be an issue but I am not really familiar with the inner workings of the CCS12 software to say ...

    This could quite be possible. I would need to confirm this. Please note that DSP/BIOS and classic ROV is no longer supported so any optimization of the tcf file would have to be done manually.

  • I believe you are right. The TCF would keep a history of the changes. Apparently there was some reason why this was recommended but the details are lost and it was likely just for a very specific corner case. But the increased size of the file is likely causing ROV to do more processing and cause CCS to slow down. There is no TCF file optimizer that I am aware of. Please note that both DSP/BIOS and Classic ROV has been completely unsupported for some time hence there is not much support we can provide here. Sorry.

    ki

  • hI Ki,

    Ok. Thanks. It may be possible to get a short script written to parse the .tcf file and defragment it to retain only the very latest configs.

    thanks and regards, MM