TMS320F28054F: Overmodulation with/without emulator for TMS320F28054F

Hello, a subject matter expert has been assigned to your question. You should expect a response within 24 hours.

Make sure that the flash configuration is correct, and set all of the used variables to the right initial values. The variables can not be cleared to zero when the code run in flash standalone as run in debug mode with the emulator in CCS.

Btw, we don't recommend the user to change the default optimization level in all of the instaspin projects.

Hi

The variables can not be cleared to zero when the code run in flash standalone as run in debug mode with the emulator in CCS.

about this point, I think the variables have two types: initialized and uninitialized. The initialized variabls should be set to FLASH section.The unitialized variables goes to RAM.

Do you mean that the possible reason is the uninitialized variables allocated to RAM are not cleared when MCU runs in standalone mode, while it can be cleared by debugger  in enmulation mode ?

Regards

Arrow

Correct. You must clear the related variable if you assume its initial value is zero.

 I set all uninitialized variables to zero in CMD file throuth FILL = 0X000 FUNCTION

.ebss            : > RAML3                PAGE = 1 ,FILL = 0X0000

in the map file, there will be no uninitialized data. Howerver this phenomenon still happens.

（there is a warning: Data is being written to auto-generated file proj_lab09.i10, do I need do special opertation for this .i10 file?）

MODULE SUMMARY

       Module                      code    initialized data   uninitialized data
       ------                      ----    ----------------   ------------------

    +--+---------------------------+-------+------------------+--------------------+
       Total:                       18073     2955                    0 

I just load the recomplied .out file to the MCU. Do I need do some special opertaion to clear the variables?

Or can we exclude this reason?

I also check the hal_setupflash() function to make sure there is no change .

void HAL_setupFlash(HAL_Handle handle)
{
  HAL_Obj *obj = (HAL_Obj *)handle;


  FLASH_enablePipelineMode(obj->flashHandle);

  FLASH_setNumPagedReadWaitStates(obj->flashHandle,FLASH_NumPagedWaitStates_2);

  FLASH_setNumRandomReadWaitStates(obj->flashHandle,FLASH_NumRandomWaitStates_2);

  FLASH_setOtpWaitStates(obj->flashHandle,FLASH_NumOtpWaitStates_3);

  FLASH_setStandbyWaitCount(obj->flashHandle,FLASH_STANDBY_WAIT_COUNT_DEFAULT);

  FLASH_setActiveWaitCount(obj->flashHandle,FLASH_ACTIVE_WAIT_COUNT_DEFAULT);

  return;
} // HAL_setupFlash() function

BTW, Is it possible that it has some releationship with secure zone?

I didn't add any Z1 or Z2 DCSM.asm file. While the Zone1 is secured by TI.

Regards

Arrow

Regards

Arrow

Or is it maybe the reason of .gel file, for CCS will use this file to excute the debug?

Yes, the CCS will use the .gel to clear all of the uninitialized variables in the RAM.

Sorry, this didn't help.

I will check if there is some difference else, and I will give a feedback if there is any progress.

Regards

Are you using your own board? Or a TI EVM kit? It seems like the issue can't be repeated on the TI EVM kit if I didn't set any passcode for the security function.

Could you please post the related .cmd and .c file? 

I‘m using my own board. Below is the CMD file，and which C file can be useful ?

The zone1 is secured by TI. I once asked about this question before, and one of your colleague conformed about this point.

/*
// TI File $Revision: /main/3 $
// Checkin $Date: March 16, 2012   14:54:07 $
//###########################################################################
//
// FILE:    F28054F.cmd
//
// TITLE:    Linker Command File For F28054F Device
//
//###########################################################################
// $TI Release: 2805x C/C++ Header Files vBeta1 $
// $Release Date: December 9, 2011 $
//###########################################################################
*/

/* ======================================================
// For Code Composer Studio V2.2 and later
// ---------------------------------------
// In addition to this memory linker command file,
// add the header linker command file directly to the project.
// The header linker command file is required to link the
// peripheral structures to the proper locations within
// the memory map.
//
// The header linker files are found in <base>\F28054F_Headers\cmd
//
// For BIOS applications add:      F28054F_Headers_BIOS.cmd
// For nonBIOS applications add:   F28054F_Headers_nonBIOS.cmd
========================================================= */

/* ======================================================
// For Code Composer Studio prior to V2.2
// --------------------------------------
// 1) Use one of the following -l statements to include the
// header linker command file in the project. The header linker
// file is required to link the peripheral structures to the proper
// locations within the memory map                                    */

/* Uncomment this line to include file only for non-BIOS applications */
/* -l F28054F_Headers_nonBIOS.cmd */

/* Uncomment this line to include file only for BIOS applications */
/* -l F28054F_Headers_BIOS.cmd */

/* 2) In your project add the path to <base>\F28054F_headers\cmd to the
   library search path under project->build options, linker tab,
   library search path (-i).
/*========================================================= */

/* Define the memory block start/length for the F28035
   PAGE 0 will be used to organize program sections
   PAGE 1 will be used to organize data sections

   Notes:
         Memory blocks on F28054F are uniform (ie same
         physical memory) in both PAGE 0 and PAGE 1.
         That is the same memory region should not be
         defined for both PAGE 0 and PAGE 1.
         Doing so will result in corruption of program
         and/or data.

         Contiguous SARAM memory blocks or flash sectors can be
         be combined if required to create a larger memory block.
*/

MEMORY
{
PAGE 0:    /* Program Memory */
           /* Memory (RAM/FLASH/OTP) blocks can be moved to PAGE1 for data allocation */
   RAML1L2            : origin = 0x008800, length = 0x000800        /* on-chip RAM block L1 */
   FLASHJ            : origin = 0x3E8000, length = 0x001000        /* on-chip FLASH */
   FLASHI            : origin = 0x3E9000, length = 0x001000        /* on-chip FLASH */
   FLASHH            : origin = 0x3EA000, length = 0x002000        /* on-chip FLASH */
   FLASHG            : origin = 0x3EC000, length = 0x002000        /* on-chip FLASH */
/*   FLASHF            : origin = 0x3EE000, length = 0x002000        /* on-chip FLASH */
/*   FLASHE            : origin = 0x3F0000, length = 0x002000        /* on-chip FLASH */
/*   FLASHD            : origin = 0x3F2000, length = 0x002000        /* on-chip FLASH */
   FLASHC_F            : origin = 0x3EE000, length = 0x008000        /* on-chip FLASH */
//   FLASHA            : origin = 0x3F7000, length = 0x000F7E        /* on-chip FLASH */
   FLASHA            : origin = 0x3F7000, length = 0x000FFE        /* on-chip FLASH */

   BEGIN            : origin = 0x3F7FFE, length = 0x000002        /* Part of FLASHA.  Used for "boot to Flash" bootloader mode. */
//   BEGIN            : origin = 0x3F7FFE, length = 0x000002        /* Part of FLASHA.  Used for "boot to Flash" bootloader mode. */
   
   Z1_SCC_ROM        : origin = 0x3F8000, length = 0x000400        /* Zone 1 Safe-Copy Code Secure ROM */
   Z2_SCC_ROM        : origin = 0x3F8400, length = 0x000400        /* Zone 2 Safe-Copy Code Secure ROM */
   Z1_SECURE_ROM    : origin = 0x3F8808, length = 0x0044F8        /* Z1 Secure ROM */
   
   IQTABLES           : origin = 0x3FDB52, length = 0x000b50  /* IQ Math Tables in Boot ROM */
   IQTABLES2          : origin = 0x3FE6A2, length = 0x00008C  /* IQ Math Tables in Boot ROM */
   IQTABLES3          : origin = 0x3FE72E, length = 0x0000AA  /* IQ Math Tables in Boot ROM */


   DCSM_OTP_Z2_P0    : origin = 0x3D7800, length = 0x000006        /* Part of Z1 OTP.  LinkPointer/JTAG lock/ Boot Mode */
   DCSM_OTP_Z1_P0    : origin = 0x3D7A00, length = 0x000006        /* Part of Z2 OTP.  LinkPointer/JTAG lock */
   
   /* DCSM Z1 Zone Select Contents and Reserved Locations (!!Movable!!) */
   /* Z1_DCSM_RSVD must be programmed to all 0x0000 and must immediately follow Z1 Zone Select block */
   DCSM_ZSEL_Z1_P0    : origin = 0x3D7A10, length = 0x000010        /* Part of Z1 OTP.  Z1 password locations / Flash and RAM partitioning */
   Z1_DCSM_RSVD     : origin = 0x3D7A20, length = 0x0001E0        /* Part of Z1 OTP.  Program with all 0x0000 when Z1 DCSM is in use. */
   
   /* DCSM Z1 Zone Select Contents and Reserved Locations (!!Movable!!) */
   /* Z2_DCSM_RSVD must be programmed to all 0x0000 and must immediately follow Z2 Zone Select block */
   DCSM_ZSEL_Z2_P0    : origin = 0x3D7810, length = 0x000010        /* Part of Z2 OTP.  Z2 password locations / Flash and RAM partitioning  */
   Z2_DCSM_RSVD     : origin = 0x3D7820, length = 0x0001E0        /* Program with all 0x0000 when Z2 DCSM is in use. */
   
   ROM                : origin = 0x3FF27C, length = 0x000D44        /* Boot ROM */
   RESET            : origin = 0x3FFFC0, length = 0x000002        /* part of boot ROM  */
   VECTORS            : origin = 0x3FFFC2, length = 0x00003E        /* part of boot ROM  */

PAGE 1 :   /* Data Memory */
           /* Memory (RAM/FLASH/OTP) blocks can be moved to PAGE0 for program allocation */
           /* Registers remain on PAGE1                                                  */
   BOOT_RSVD        : origin = 0x000000, length = 0x000050        /* Part of M0, BOOT rom will use this for stack */
//   RAMM0            : origin = 0x000050, length = 0x0003B0        /* on-chip RAM block M0 */
//   RAMM1            : origin = 0x000400, length = 0x000400        /* on-chip RAM block M1 */
   RAMM01            : origin = 0x000050, length = 0x0007B0        /* on-chip RAM block M0 */
   RAML3            : origin = 0x009000, length = 0x001000        /* on-chip RAM block L3 */
//   RAML3_Reserved   : origin = 0x009E00, length = 0x000200
//   FLASHB            : origin = 0x3F6000, length = 0x001000        /* on-chip FLASH */

}

/* Allocate sections to memory blocks.
   Note:
         codestart user defined section in DSP28_CodeStartBranch.asm used to redirect code
                   execution when booting to flash
         ramfuncs  user defined section to store functions that will be copied from Flash into RAM
*/

SECTIONS
{

   /* Allocate program areas: */
//   .cinit            : > FLASHC_F            PAGE = 0
//   .pinit            : > FLASHC_F            PAGE = 0

   .cinit            : > FLASHC_F            PAGE = 0
   .pinit            : > FLASHC_F            PAGE = 0
   .text            : > FLASHC_F            PAGE = 0

   codestart        : > BEGIN                PAGE = 0

//   ctrl_object      : > FLASHG              PAGE = 0
//   hal_object       : > FLASHH              PAGE = 0

//   ramfuncs         : > FLASHC_F           PAGE = 0

   ramfuncs            : LOAD = FLASHA,
                         RUN = RAML1L2,
                         LOAD_START(_RamfuncsLoadStart),
                         LOAD_END(_RamfuncsLoadEnd),
                         RUN_START(_RamfuncsRunStart),
                         PAGE = 0
   
   dcsm_otp_z1        : > DCSM_OTP_Z1_P0        PAGE = 0
   dcsm_otp_z2        : > DCSM_OTP_Z2_P0        PAGE = 0
   
   dcsm_zsel_z1        : > DCSM_ZSEL_Z1_P0        PAGE = 0
   dcsm_rsvd_z1        : > Z1_DCSM_RSVD        PAGE = 0
   dcsm_zsel_z2        : > DCSM_ZSEL_Z2_P0        PAGE = 0
   dcsm_rsvd_z2        : > Z2_DCSM_RSVD        PAGE = 0

   /* Allocate uninitalized data sections: */
//   .stack            : > RAMM0                PAGE = 1
   .stack            : > RAMM01                PAGE = 1
   .ebss            : > RAML3                PAGE = 1
   .esysmem            : > RAML3                PAGE = 1

   /* Initalized sections go in Flash */
   /* For SDFlash to program these, they must be allocated to page 0 */
   .econst            : > FLASHC_F            PAGE = 0
   .switch            : > FLASHC_F            PAGE = 0

   /* Allocate IQ math areas: */
   IQmath            : > FLASHC_F            PAGE = 0            /* Math Code */
   IQmathTables        : > IQTABLES,            PAGE = 0, TYPE = NOLOAD

  /* Uncomment the section below if calling the IQNexp() or IQexp()
      functions from the IQMath.lib library in order to utilize the
      relevant IQ Math table in Boot ROM (This saves space and Boot ROM
      is 1 wait-state). If this section is not uncommented, IQmathTables2
      will be loaded into other memory (SARAM, Flash, etc.) and will take
      up space, but 0 wait-state is possible.
   */
   /*
   IQmathTables2    : > IQTABLES2,            PAGE = 0, TYPE = NOLOAD
   {

              IQmath.lib<IQNexpTable.obj> (IQmathTablesRam)

   }
   */
    /* Uncomment the section below if calling the IQNasin() or IQasin()
       functions from the IQMath.lib library in order to utilize the
       relevant IQ Math table in Boot ROM (This saves space and Boot ROM
       is 1 wait-state). If this section is not uncommented, IQmathTables2
       will be loaded into other memory (SARAM, Flash, etc.) and will take
       up space, but 0 wait-state is possible.
    */
    /*
    IQmathTables3    : > IQTABLES3,            PAGE = 0, TYPE = NOLOAD
    {

               IQmath.lib<IQNasinTable.obj> (IQmathTablesRam)

    }
    */

   /* .reset is a standard section used by the compiler.  It contains the */
   /* the address of the start of _c_int00 for C Code.   /*
   /* When using the boot ROM this section and the CPU vector */
   /* table is not needed.  Thus the default type is set here to  */
   /* DSECT  */
   .reset            : > RESET,                PAGE = 0, TYPE = DSECT
   vectors            : > VECTORS                PAGE = 0, TYPE = DSECT

}

/*
//===========================================================================
// End of file.
//===========================================================================
*/

Did you meet the same issue if you didn't change the .cmd file in the example project?

I didn't use the original CMD file，cause the ram allocation is not enough for .ebss in my project.

The difference is the .ebss allocation.

The orginal .cmd file set

   .ebss            : > RAMM0_M1            PAGE = 1
   .esysmem            : > RAMM0_M1            PAGE = 1

In my .cmd file

   .stack            : > RAMM01                PAGE = 1
   .ebss            : > RAML3                PAGE = 1

It's too difficult to find the diffence between two running ways.

It works the same as the vs limit lower than 0.5777.

It works worse when vs limit higher than 0.5777 in standalone, while it runs well to vs limit 0.6666  on debugger mode, even runs well when removing the emulator and keep power on the MCU.

The line voltage I measure, has large distorison when working standalone and votlage more than 0.5777.

I believe the CCS will mask the problems associated with the initialized sections and their linkage in memory.And I'll keep on this issue.

Btw, I'm not sure the f28054f.gel file will set the uninitialized virables to zero. And you can compare it with the f28379d_cpu1.gel.

28379's .gel file will intialize the virables OnTargetConnect() function.

    *(int *)0x5F412 =0x000F;      /* RAM INIT FOR M0/M1/D0/D1 Memory  */
    *(int *)0x5F432 =0x003F;      /* RAM INIT FOR LS0..LS5  Memory    */
    *(int *)0x5F452 =0xFFFF;      /* RAM INIT FOR GS0..GS15 Memory    */

Regards

Arrow

The cause should be from the current sensing and ADC registers settings, you might have to check if there are any variables or registers that have differences between these two cases. You might load the code into the flash and run it standalone, and then connect the emulator to check the settings.

Hi

I find the difference between debugger and standalone mode.

I set the MCU Emulation Boot, and boot from flash. TRST = 1, 0XD00 = 0X55AA,0XD01=0X0003.

Just connect CCS with or without .gel file, and run(source file preloaded, and will not be loaded when CCS is connected again).

With .gel File，it woks ok. Without .gel File，it making worse in high speed.

I remove all the code in .gel file ,except the OnTargetConnect() function.

When I comment the  GEL_Reset();                 /*Reset DSP */,  it just show the same phenomenon as standalone mode(without .gel file.)

So, if it possible for me to do the GEL_Reset() function in standalone mode, and how?

Regards

Arrow

As replied to you before. You might try to clear all of the uninitialized RAM before you call any functions that is the only difference I know.