TI中文支持网调试的芯片是C6678，用的CCS版本是5.5。
一开始发现该问题，是因为发现在一个函数调用出双击设置断点，step in进函数体调试时，发现有时候函数参数居然传递的不对！！！同样的程序，reset然后load进8个核后，有时候传递的参数是对的，有时候不对，有的核是对的，有的核不对！！
函数调用就是一个很简单的函数调用，DNUM作为参数传递给函数，作为通道号。如下图：
最后查找原因发现：8个核设置断点后，表现正常的核，反汇编代码如下图（注意第0c1c3e40行）：
表现不正常的核如下图：（注意第0c1c3e40行）
二者居然不一致！出问题的核，DNUM到B5寄存器的值传递被SWBP覆盖了，导致B5没有接受到参数，仍然保留的以前的值，并把这个错误的值传给了A4（也就是函数里入口参数ChannelNUM所保存的寄存器），导致程序执行错误！
我知道软件断点的原理是：将断点处的代码修改为断点指令，然后程序就会在运行到断点时停下来，但是我浏览了TI关于断点的wiki：
http://processors.wiki.ti.com/index.php/Data_Breakpoint/Watchpoint
软件断点部分截图如下：
也就是说，正常情况下：软件断点所修改的代码，是不会让用户感知的，也就是说CCS的disassembly窗口里的反汇编代码是不会随着加断点而改变的。
还请TI的工程师帮助解决该问题！万分感谢！
另外：当错误的情况发生时，0c1c3e40行的代码被错误刷新成了SWBP，并且永远不会恢复！，也就是说即使通过breakpoint控制窗口取消了断点，程序还是会在这里停下来！
huanan liu1：
另外为了避免是CCS5.5的bug，我在CCS6.0下也试了下，问题依旧。为了避免是仿真器的问题，我用开发板（自带仿真器）试了下，问题也依旧存在。真不知道是哪里的除了问题了。。。
Na Li7：
这个好像是CCS调用的dvr驱动的bug，按理说这条语句是最普通的语句，不涉及跳转，不涉及16bit，不涉及并行，不应该出错的，可能是有别的设置引起的连锁反应
