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.

LAUNCHXL-F28069M: PWM failure after writing/erasing FLASH

Part Number: LAUNCHXL-F28069M
Other Parts Discussed in Thread: C2000WARE

Dear All

We have a malfunction in the PWMs we suppose because some error in FLASH erase/writing done before.

At the begin of the program is done an InitFlash (see below) and before each writing, erasing operation is done calib() (see below). A calib() is also done just after the InitFlash at the beginning of the program

Is it this procedure Ok? Or something else must be done?

Thanks

Luis Gonçalves

*******************************************************

#pragma CODE_SECTION(InitFlash, "ramfuncs");

//
// InitFlash - This function initializes the Flash Control registers for
// operation at 90MHz.  If you are running slower flash wait states can be
// lessened. Refer to the datasheet for propper flash wait state values.
//                   CAUTION
// This function MUST be executed out of RAM. Executing it
// out of OTP/Flash will yield unpredictable results
//
void
InitFlash(void)
{
    EALLOW;
    
    //
    // Enable Flash Pipeline mode to improve performance of code executed from
    // Flash.
    //
    FlashRegs.FOPT.bit.ENPIPE = 1;

    //                CAUTION
    // Minimum waitstates required for the flash operating
    // at a given CPU rate must be characterized by TI.
    // Refer to the datasheet for the latest information.
    //
    
    //
    // Set the Paged Waitstate for the Flash
    //
    FlashRegs.FBANKWAIT.bit.PAGEWAIT = 3;

    //
    // Set the Random Waitstate for the Flash
    //
    FlashRegs.FBANKWAIT.bit.RANDWAIT = 3;

    //
    // Set the Waitstate for the OTP
    //
    FlashRegs.FOTPWAIT.bit.OTPWAIT = 5;

    //
    // CAUTION -  ONLY THE DEFAULT VALUE FOR THESE 2 REGISTERS SHOULD BE USED
    //
    FlashRegs.FSTDBYWAIT.bit.STDBYWAIT = 0x01FF;
    FlashRegs.FACTIVEWAIT.bit.ACTIVEWAIT = 0x01FF;
    EDIS;
 
    //
    // Force a pipeline flush to ensure that the write to the last register
    // configured occurs before returning.
    //
    __asm(" RPT #7 || NOP");
}

*******************************************************

#pragma CODE_SECTION(calib,"ramfuncs");

void calib(void)
{
   // Uint16 Status;
EALLOW;
SysCtrlRegs.PCLKCR0.bit.ADCENCLK = 1;
(*Device_cal)();
SysCtrlRegs.PCLKCR0.bit.ADCENCLK = 0;
EDIS;

//
// Assuming PLLSTS[CLKINDIV] = 0 (default on XRSn).  If it is not
// 0, then the PLLCR cannot be written to.
// Make sure the PLL is not running in limp mode
//
if (SysCtrlRegs.PLLSTS.bit.MCLKSTS != 1)
{
    if (SysCtrlRegs.PLLCR.bit.DIV != PLLCR_VALUE)
    {
        EALLOW;

        //
        // Before setting PLLCR turn off missing clock detect
        //
        SysCtrlRegs.PLLSTS.bit.MCLKOFF = 1;
        SysCtrlRegs.PLLSTS.bit.DIVSEL = 0;  // 1/4
        SysCtrlRegs.PLLCR.bit.DIV = PLLCR_VALUE;
        EDIS;

        //
        // Wait for PLL to lock.
        // During this time the CPU will switch to OSCCLK/2 until
        // the PLL is stable.  Once the PLL is stable the CPU will
        // switch to the new PLL value.
        //
        // This time-to-lock is monitored by a PLL lock counter.
        //
        // The watchdog should be disabled before this loop, or fed within
        // the loop.
        //
        EALLOW;
        SysCtrlRegs.WDCR= 0x0068;
        EDIS;

        //
        // Wait for the PLL lock bit to be set.
        // Note this bit is not available on 281x devices.
        // For those devices use a software loop to perform the required
        // count.
        //
        while(SysCtrlRegs.PLLSTS.bit.PLLLOCKS != 1)
        {

        }

        EALLOW;
        SysCtrlRegs.PLLSTS.bit.DIVSEL = 2;  // 1/2
        SysCtrlRegs.PLLSTS.bit.MCLKOFF = 0;
        EDIS;
    }
}

//
// If the PLL is in limp mode, shut the system down
//
else
{
    //
    // Replace this line with a call to an appropriate
    //SystemShutdown(); function.
    //
    __asm("        ESTOP0");
}

//
// Unlock the CSM.
// If the API functions are going to run in unsecured RAM
// then the CSM must be unlocked in order for the flash
// API functions to access the flash.
//
// If the flash API functions are executed from secure memory
// (L0-L3) then this step is not required.
//
//Status =  CsmUnlock2();
//if(Status != STATUS_SUCCESS)
//{
//     Error(Status);
//}

//
// Copy API Functions into SARAM
//
// The flash API functions MUST be run out of internal
// zero-waitstate SARAM memory.  This is required for
// the algos to execute at the proper CPU frequency.
// If the algos are already in SARAM then this step
// can be skipped.
// DO NOT run the algos from Flash
// DO NOT run the algos from external memory
//

//
// For Piccolo, we dont need to copy the API from Flash as it is
// present in BOOT ROM
//

//
// Copy the Flash API functions to SARAM
//
// MemCopy(&Flash28_API_LoadStart, &Flash28_API_LoadEnd,
//                &Flash28_API_RunStart);

//
// We must also copy required user interface functions to RAM
//
// MemCopy(&RamfuncsLoadStart, &RamfuncsLoadEnd, &RamfuncsRunStart);

//
// Initalize Flash_CPUScaleFactor.
//
// Flash_CPUScaleFactor is a 32-bit global variable that the flash
// API functions use to scale software delays. This scale factor
// must be initalized to SCALE_FACTOR by the user's code prior
// to calling any of the Flash API functions. This initalization
// is VITAL to the proper operation of the flash API functions.
//
// SCALE_FACTOR is defined in Example_2806xFlashProgramming.h as
// #define SCALE_FACTOR  1048576.0L*( (200L/CPU_RATE) )
//
// This value is calculated during the compile based on the CPU
// rate, in nanoseconds, at which the algorithums will be run.
//
EALLOW;
Flash_CPUScaleFactor = SCALE_FACTOR;
EDIS;

//
// Initalize Flash_CallbackPtr.
//
// Flash_CallbackPtr is a pointer to a function.  The API uses
// this pointer to invoke a callback function during the API operations.
// If this function is not going to be used, set the pointer to NULL
// NULL is defined in <stdio.h>.
//
EALLOW;
Flash_CallbackPtr = NULL;
EDIS;

}

  • What is happening?

    Is the device executing anything at all?

    How is the PWM failing, is it the wrong frequency or duty? Is there any PWM output at all? 

    Why do you think this is related to the Flash, does you code work when executed from RAM?

    Regards,
    Cody 

  • I am going to close this thread due to inactivity. Please feel free to respond here, or start a new thread if it has locked.

    Regards,
    Cody
  • Dear All

    I can only test in the Christmas Holidays.

    Can anyone inform that the procedure below is, or not, the right procedure to Erase/Write the EEPROM? (please also see the code in the first message). I suppose that in TI there are people enought experienced to give that answer or point one alternative procedure. It is not needed to say if it will, or not, solve the problem


    The procedure:

    ****************************************************************

    We have a malfunction in the PWMs we suppose because some error in FLASH erase/writing done before.

    At the begin of the program is done an InitFlash (see below) and before each writing, erasing operation is done calib() (see below). A calib() is also done just after the InitFlash at the beginning of the program

    Is it this procedure Ok? Or something else must be done?

    *******************************************************************

    Thanks

    Luis Gonçalves
  • Luis,

    Erasing / Programming flash shouldn't affect PWM operation unless you erase / program sections of flash which initializes / configures PWM is erased. The calib function you had attached in first message doesn't seem to have Flash_Erase (or) Flash_Program functions. So, I don't know why you say calib function will erase flash.

    Also, please answer questions asked by Cody to get further insight into your problem.

    If you have already not looked into this example, I would urge you to understand this example. It tells user how to embed and use Flash API in your application project.

    <C2000Ware>\libraries\flash_api\f2806x\Example_Flash2806x_API

    Regards,
    Manoj
  • Sir

    I have confidence that the sector where is the PWM program is not erased during Write or erase of Flash because only sector H is erased. And all operations related with Erase, writing and reading of the Flash (acting as EEPROM) are working ok. As I remember of the last tests to the program when the program is started and the parameters were read from the Flash,  the program works Ok. If we transfer new parameters to the Kit (throught serial port) and those parameters are written to Flash, even being the same parameters from the last working ones, the program gave those runtime problems. 

    I suppose that calib() is in conformance with the following document

    luisgo.dyndns.org/.../Flash2806x_API_Quickstart.pdf

    Can you verify, please? Please, read carefully the posts, please

    Thanks

    Luis Gonçalves

    PS: I only can make more tests with the program in Christmas Holidays

  • Sir


    Not reported, I am also puting the FLASH API in the RAM. Also, all the functions are running from RAM.

    Thanks

    Luis Gonçalves
  • Luis,

    I did comment about calib function in my previous post. What were your debug steps taken? Unfortunately you need to single step through your code to understand why PWM isn't working.

    Also, you haven't answered any of Cody's question.

    Regards,
    Manoj
  • Sir

        For now, I can not provide more information because I have not (more information). Only after Christmas when I will do some work on this on site. Now I only can work "offline"

    Thanks

    Luis Gonçalves

  • Luis,

    If you are not planning to work on this only after christmas, I shall mark this thread resolved for now for TI housekeeping purposes. You reopen this thread by posting additional questions on the same thread.

    Regards,
    Manoj