Compiler: Running an Application from Internal Flash Memory on the and Initializing the Flash Control Registers:

Pat,

InitFlash() function should be executed from RAM and not flash. The reason being, this code enable the flash pipeline and configures the the wait states. As the flash wait states control the flash access time, it's possible for the flash instruction fetches to get corrupted resulting in PC getting lost.

Regards,
Manoj

Thank you Manoj for your answer but my problem is a little bit deeper.

I did initialization from RAM but after assembly code check of my function initializing FLASH registers, i see that the 8 wait cycles needed in order to flush pipeline before returning to FLASH execution are not reached (i have only 5).

Indeed, the optimization level is set to 0 and this is enough to delete in my wait loop the decrement i use:

waitCycleNumber = 8;

While (waitCycleNumber >0)

{

waitCycleNumber--

}

I know that it is not the TI recommendation to treat the solution, but launching asm code from C function is forbidden.

I have the solution which is simply to declare waitCycleNumber as volatile, and in that case,  my 8 wat cycles are present.

To finish with code, when back to FLASH execution, i check that registers configuration is correct, otherwise i raise a failure and block execution.

The problem is that in aeronautical process, a quick code modification has big consequences in workload with all tests and documents already in released status.

Moreover, probability to have new functionalities coming from customer is high and this correction will be done later.

But now, just to be clean in my head,  i would like to know clearly with users feedbacks what is the risk to have only 5 wait cycles instead of having 8 wait cycles ?

Thank your for your feedbacks.

I couldn't follow your question. But, I'm intrigued why you would want to have only 5 wait cycles when the recommendation is 8 wait cycles. Also, I don't understand how you get 5 wait cycles? and why you can't increase it?

-Manoj

We thought We had 8 cycles with the loop added.

The compiler optimization has deleted the decrese counter when checking assembly code.

So instead of 8 expected cycles, We have only 5 cycles (one MOV and one B assembly instruction).

Code change takes 2mins, but as this check is one of the last and that all spécification, design, code, Unit tests, validation tests are released, this code change needs everything to be executed once again in a new version.

So that's why i want to know exactly what happens AT pipeline level, and what is done exactly when Program Counter goes from RAM to FLASH.
What could be consequences on détails.

Thanks Manoj for interest to my problem.

Thank you for your answer Manoj.

I fully understand what is required by Texas note, routine is run from RAM and 8 cycles are needed to flush pipeline.

But, ihave another question: is this the same consequence to have 1 cycle missing or 7 cycles missing ?

This is our C function configuring flash and executed in RAM:

void ATCU_DRVDSP_CONFIG_FLASH(void)

{

    /* Internal data */

    Uint16 cycleIndex;

 

    /* Start of algorithm */

 

    /* Enable Flash Pipeline mode to improve performance of code executed from Flash */

    GV_sFlashRegs.FOPT.ENPIPE = 1;

 

    /* Set the Pages and Random Waitstate for the flash */

    GV_sFlashRegs.FBANKWAIT = C_FBANK_WAIT;

 

    /* Set the Waitstate for the OTP */

    GV_sFlashRegs.FOTPWAIT.OTPWAIT = C_OTP_WAIT;

 

    /* Wait eight cycles to let the write instructions propagation through the CPU pipeline. */

    /* This must be done before the return-from-function call is made. */

    cycleIndex = C_UTIL_PIPELINE_FLUSH;

    while (cycleIndex > 0U)

    {

        cycleIndex--;

    }

 

}    /* End of ATCU_DRVDSP_CONFIG_FLASH */

Shall i consider that 8 cycles are needed from line:

- GV_sFlashRegs.FBANKWAIT = C_FBANK_WAIT;

or

-   GV_sFlashRegs.FOTPWAIT.OTPWAIT = C_OTP_WAIT;

 

Thank you for your answer.

Manoj,

The reason of this question is that if we check assembly code to see which instruction are remaining in pipeline.

 When leaving RAM and going back to FLASH, only 3 assembly instructions concerning OTP wait state configuration remain.

The first access to OTP is done around 3000 cyles after this configuration in our software.

Could it be an argument to say that:

- we have at least 8 cycles after the register configuration concerning FLASH (FBANKWAIT)

- we access to OTP a long time after the register configuration (OTPWAIT)

Or, in any case 8 cycles are needed, and we have to be conform to Texas document end of story ?

Sorry to be insistant on this point, but the consequences for us are really not the same at this moment.

Thank you Manoj.