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.

CSM slow down the execution of the application, reduces the speed, Does it affect the clock frecuency? With TMS320F28335.

Other Parts Discussed in Thread: TMS320F28335

Hi:

After hours tryng to find some explanation or commentary throughout the documentation, wiki and forum, I resort to this forum to ask for it.

We have a time critical application running on the  TMS320F28335, which we develop and debug with the CCS.

We measure the execution time of one of the most time-critical functions, both with timer1 and with chronometer measurement of a led toggling every 1000 executions of the function, and find that, without CSM password lock, it executes in about 0.7 ms. However, if we "Program Password" (from the CCS On-Chip flash button and "Lock", and we launch the stand-alone execution, we measure (with the led toggling) that the execution time rises to about 3 ms. 

I suppose it won't have any influence on this, but, on top of the same "On-Chip Flash (TMS320C28XX) titled form, the Clock Configuration square has its default values of OSCCLK (MHz) , CLKINDIV and PLLCR Value fields filled to 30, 2 and 10, respectively. (In fact, the clock configuration I beleive is done in the following main called function:

void InitSysCtrl(void)
{

// Disable the watchdog
DisableDog();

// Initialize the PLL control: PLLCR and DIVSEL
// DSP28_PLLCR and DSP28_DIVSEL are defined in DSP2833x_Examples.h
InitPll(DSP28_PLLCR,DSP28_DIVSEL);

// Initialize the peripheral clocks
InitPeripheralClocks();

}

, where DSP28_PLLCR and DSP28_DIVSEL are defined in DSP2833x_Examples.h as:

#define DSP28_DIVSEL 2 // Enable /2 for SYSCLKOUT

#define CPU_RATE 6.667L // for a 150MHz CPU clock speed (SYSCLKOUT)

Could anybody, please, give us any explanation about it? 

Thanks and regards,

Jose

  • Jose,

    You don't say if your critical code is run from RAM or flash.  I will assume flash in my theory that follows.  The flash control registers are protected by the CSM.  When you configure the flash wait-states, you access the flash control registers from your code.  In addition, this code is supposed to be run in memory other than the flash (e.g., RAM) to avoid potential problems (i.e., you shouldn't configure the flash from code running from flash).  Assuming that you followed this, you are copying the flash configuration code to RAM someplace and then running it.  Is this copy being done to a CSM SECURE RAM block?  If you run the flash config code from non-secure RAM, it will not be able to access the flash control registers and you will be running with excess wait-states.  The secure RAM on F28335 are the L0 - L3 SARAM blocks (see the device datasheet).

    That is my theory.

    Regards,

    David

  • Thanks, David, for your quick and interesting reply.

    Actually, the long and critical function is run from CSM protected RAM, to where it's being copied from its initial flash location (I understand all flash is in CSM zone) by a memcpy(..)  executed within the main() function, running also from flash.

    However, although I'd tried to be careful about code execution place in relation to software protection, I wasn't really aware of the important requirements you mention for flash configuration code, so, you have really pointed me to the solution:

    After changing the RAM copying of the InitFlash() function to CSM RAM, the critical function execution time has approximated that with no CSM, which is the important result, as I was afraid that CSM protection could add some speed-reducing protection specific processing that made me have to decide between protection or speed.

    One question still remains strange to me: most of the processing time should be consumed by that critical function (which is quite float number-crunching and doesn't call other functions) and it already executed from CSM RAM. So, I don't understand why it is so much affected by flash configuration (wait states) (as I told you, execution time was trippled). Could it be due to floating point or other library functions unexplicitly called by my critical one, which keep on being executed from flash? In this case, how could I locate them and move them to ram?

    Thanks again,

    Jose.

  • Jose,

    So it sounds like after properly configuring the flash wait-states using code running from CSM RAM, the problem has gone away.  I agree that your critical code in RAM seems to be using some code in flash.

    Jose Glaria said:

    Could it be due to floating point or other library functions unexplicitly called by my critical one, which keep on being executed from flash? In this case, how could I locate them and move them to ram?

    You would know what the critical code does.  Does it make any library calls?  Follow the code by stepping and using run-to-line in CCS.

    Regards,

    David