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.

CCS/TMS320C6748: The frequency of the core is set up to 300MHz, which is identified by checking the settings of PLL part, but the real running speed is much lower than the ideal, why?

Part Number: TMS320C6748
Other Parts Discussed in Thread: OMAPL138

Tool/software: Code Composer Studio

 From the actual test,the function  Timer_setPeriod()  or Timer_start() supported by the sys/bios needs about 10 microseconds,  even the write to the output register of GPIO costs about 240 nanoseconds. in case of  the influence of sys/bios , I do the same thing in the simple CCS project without RTSC or bios, but the problem remains.Thanks a lot for some suggestions.  

  • Which CCS & Processor SDK RTOS version are you using?

    Best Regards,
    Yordan
  • Thank you for your asking. I use  CCS8.0 and  Processor SDK RTOS OMAPL138 05_01_00_11, by the way  the problem is remained in the simple CCS project and I use  the BH-USB-560v2 emulator of BlackHawk to debug. the code in the main function is as below:

    GPIO_Init(); 

    while(1)

    {

    HWREG(SOC_GPIO_0_REGS+0x14)|=0x00000002;//set gp[0][1]

    HWREG(SOC_GPIO_0_REGS+0x14)&=0xfffffffd;// clear gp[0][1]

    }

    As you see, the code is simple. Just write the Output register of GPIO  repeatedly, then watch the output by the oscilloscope and It shows one write operation to the register costs about 240 nanosenconds.

    Thanks!

  • Hello,

    I am sorry this was missed. Do you still need assistance with this issue?
  • Yes please!

    Now the new Progress is that i set the whole L2 memory  for  Cache and the speed is remarkably raised,but still needed to be  faster.So expect your advice.

  • user5338487 said:

    while(1)

    {

    HWREG(SOC_GPIO_0_REGS+0x14)|=0x00000002;//set gp[0][1]

    HWREG(SOC_GPIO_0_REGS+0x14)&=0xfffffffd;// clear gp[0][1]

    }

    Your code above is performing a read-modify-write to the OUT_DATA01 register.  This is a very slow operation:

    1. Reads will stall the processor.
    2. Access to the GPIO peripheral requires the data to cross multiple interconnects, clock domains, etc.  It is slow.

    The good news is that you can tremendously improve this code by appropriately leveraging the SET and CLEAR registers.  This will convert your read-modify-write operations into write-only operations.  For example:

    while(1)

    {

    HWREG(SOC_GPIO_0_REGS+0x18) = 0x00000002;//set gp[0][1]

    HWREG(SOC_GPIO_0_REGS+0x1C) = 0x00000002;// clear gp[0][1]

    }

    In the case above where you're doing nothing but these register writes, your write buffer will quickly fill up which will still stall the CPU (though for a lot less time than your read-modify-write).  So I expect your performance should double with this change.  And I think if you're doing a more "real world" example where you have other code mixed with this the performance will get even better, because those writes will be non-blocking as long as your write buffer doesn't fill up completely.  So if you're just doing one or two register writes here and there the performance improvement will be dramatic.

    Best regards,
    Brad

  • PS. One other benefit to using the "SET" and "CLEAR" registers is that you are guaranteed an atomic operation. So in other words, if you go back to your original read-modify-write code, it is possible for an interrupt to occur between the read and the write. When that happens and that register gets updated by code elsewhere, you end up clobbering that new value! So you would potentially need to disable/restore interrupts around your read-modify-write, or much better yet just use the SET and CLEAR registers that I mentioned. FYI, this scenario that I'm describing was exactly the issue behind another customer's issue here:

    e2e.ti.com/.../2570073
  • Thank you very much!