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.

关于CCS5.5中调试C6455 DSP时使用clock的问题求教!!!



大家好!

    我在使用CCS5.5 开发环境调试C6455的程序,为了统计一个函数void foo();的执行时间,将断点设置在该函数所在行,然后再【run】/【clocl】/【enable】工具中打开了clock,并设置为统计CPU 执行周期数,从而确定该函数void foo()的执行时间。结果遇到了如下问题:

   有时板卡上电后,链接仿真器,单步执行即step over统计该函数的执行周期数,结果该函数所需周期数目特别大,如下图:

从图可以看出,执行一次foo()函数的时间为15,004,187个周期。说明该函数肯定执行不正常了(正常情况下周期数不会大于6,000,000)。多次执行该函数重新统计用时依然是这么多个周期。

于是硬件复位DSP,仿真器保持连接状态,重新reload program后,再次统计该函数的执行时间,则周期数缩短为5,000,000左右,从此以后永远是5,000,000左右,不会再出现超时现象。

该超时现象是偶发,大概10次上电中有2次会碰到这种超时现象,每次发现超时后,复位DSP都会解决。请问有可能是什么原因导致同一个函数的执行周期数发生如此巨大的变化?

我自己做了几个实验,依然没找到头绪:

实验1)将代码与二次bootloader烧写到flashh中,并设置为8bit EMIF启动,依然偶尔会出现超时现象(通过其它方法观察到的);复位后则程序回复正常;

实验2)连接仿真器,一旦该次上电出现超时现象,则查看了DEVSTAT寄存器,发现与正常时的值一致,boot mode与硬件板卡的配置也一致;观察PC指针,其值始终在0x800000空间中运行,并未指向falsh所在的0xb0000000空间中,因此并不是在flash中直接运行程序导致的。

请大家帮忙分析一下,可能的问题原因在哪里?小弟在此谢过了。。。。。。。

  • 使用CCS的clock功能,可以看这里的描述方法:

    http://processors.wiki.ti.com/index.php/Profile_clock_in_CCS

  • 现在需要先把偶尔dsp有boot失败的问题解决掉。

    软件上应该没问题,主要可能是硬件启动配置管脚信号的电路部分。

  • 您好!首先谢谢您的回复。

    1、如果BOOT失败了,DEVSTAT中应该是错误的配置值,但是我对比了正常时刻和超时时刻的DEVSTAT寄存器配置,二者相同,并且与硬件配置一致,并未发生错误采样。

    2、今天用示波器测量了3.3、1.2、1.8的上电时间,其先后顺序满足datasheet要求,间隔均在6ms左右;

    3、测量了POR_RESET和SYSRESET在上电时刻的间隔,1.8V上电后,延迟12ms左右POR_RESET失效,SYSRESET还会继续active 400ms左右,然后释放;对照datasheet也未发现RESET相关时序的异常。

     

    POR_RESET        ____________|`````````````````````````````````

    SYS_RESET        ___________________________|`````````````````````````````

    实际测量的时序是这样的,是否需要将SYS_RESET改为在POR_RESET释放后再出现脉冲?即如下图所示?

    POR_RESET        ____________|`````````````````````````````````

    SYS_RESET        `````````````````````````````|_____________|`````````````````````````````

    4、看了您给的关于clock使用方法的连接,上面说可能导致周期数增大的原因有:1)访问存储器;2)中断; 3)跳转语句;

           1)改函数的确有访问存储器,但访问的是L2存储器,对两个数组进行累加统计。

    for (i=0;i<IMG_BIT_OFF_SET+1;i++)
       {
        HistInfor->hist_addr[i]=_sadd((u32)hist16_1[i],(u32)hist16_2[i]);
       }

    其中hist16_1、hist16_2是指向两个数组的指针:

    typedef struct tagHistInfor
    {
     u32   hist_addr[IMG_BIT_OFF_SET+1]; 

     u16   hist16_1[IMG_BIT_OFF_SET+1];
     u16   hist16_2[IMG_BIT_OFF_SET+1];
    }HistInfor_st;

    HistInfor_st   far    HistInfor;

    该结构体定义由far关键字指明,CMD文件中的分配如下:

    MEMORY
    {
            L1D:     o = 00f00000h   l = 00008000h
            L1P:     o = 00e00000h   l = 00008000h
            BOOT:    o = 00800000h   l = 00000400h
            L2:      o = 00800400h   l = 0001f000h
            L2D:     o = 00820000h   l = 0003ffffh

    }

    SECTIONS
    {
        .boot_load  >       BOOT
        .csl_vect   >       L2
        .text       >       L2
        .stack      >       L2
        .bss        >       L2
        .cinit      >       L2
        .cio        >       L2
        .const      >       L2D
        .data       >       L2D
        .switch     >       L2
        .sysmem     >       L2
        .far        >       L2D

    }

    所有操作都是再L2中,请问,对L2的访问也会额外的增加周期数?而且是偶发性的?我在程序超时时,查看了编译器对HistInfor中的成员分配的地址,均在L2D中,且复位并不会导致该全局结构体变量的地址被重新分配;

    2)中断在调用该函数的全程已经全部关闭;

    3)几乎无跳转语句;

    谢谢!

     

  • 你好,计算执行一次foo()函数的时间,你可以使用定时器的方式来计算,不使用CCS profile功能,这样应该会准确一些。

  • 您好!问题定位了:

        超时时刻:L1DCFG = 0x0;   L1PCFG = 0x0;

        正常时刻: L1DCFG = 0x7;   L1PCFG = 0x7;

    超时发生时,进行复位操作,可将上述两个寄存器回复到0x7,然后就正常了。

     

    手册上说:After device reset, L1P and L1D cache are configured as all cache or all SRAM. The on-chip Bootloader changes the reset configuration for L1P and L1D.

    板卡硬件上的确设置的是EMIFA ROM boot模式,且从DEVSTAT读出的数据也是该模式,正常情况下L1 Cache应该为32KB,即L1P/DCFG = 0x7。但从现象上分析,可能是上电后,出现了on chip bootloader配置Cache为32KB失败的情况,将Cache大小设置为了0,所以需要reset重新运行onchip bootloader。

    请问导致该现象的原因是silicon版本的问题么?现在采用的解决办法只能通过应用软件在上电后,重新对L1P/D CFG进行手动配置了。

  • 恭喜你定位出问题所在,这里的确应该是由on-chip Bootloader 来配置L1 Cache为32KB的。

    这个问题在silicon版本手册中没有提及,你可以用手动的方法来配置L1P/D CFG。

    http://www.ti.com/general/docs/lit/getliterature.tsp?baseLiteratureNumber=sprz234&fileType=pdf