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.

TMS320F28069F: controlSUITE : a problem in using the serial_flash_programmer

Part Number: TMS320F28069F
Other Parts Discussed in Thread: CONTROLSUITE, , C2000WARE

Hello,

I am planning to use the utility of serial_flash_programmer included in the controlSUITE package for our project employing the TMS320F28069F device.

I have two files in the SCI boot format for download use.

When I try to download FILE1 into our target board employing the TMS320F28069F device, the serial_flash_programmer.exe seems to complete its downloading execution as shown in the following captured image.

Meanwhile when  I try to download FILE1 into our target board, the serial_flash_programmer.exe does not complete its downloading execution as shown in the following captured image.

It stalls during its execution.

For your review obviousy, I may have to attach two files in the SCI boot format for download use. However I do not know how to attach .txt files in this post.

For your reference, the file sizes of FILE1 and FILE2 are 130kB and 268kB, respectively.

Please inform me how to  attach .txt files in this post.

Thank you for your guidance.

With regards,

G. Kim

  • Hello,
    Concerned experts have been notified of this query.
    Note that it is US Spring holiday today and most of the TI engineers are away.
    Please expect a delayed response, surely by early next week.

    Regards,
    Himanshu
  • Hi,

    Please use the code provided in C2000Ware.

    Also, please use the -v command line parameter for verbose printing. This may help you debug your issue.

    Also, please see this application report. www.ti.com/.../sprabv4c.pdf

    sal
  • Dear Sal,

    Thank you for your review.

    Today I have worked with the serial_flash_programmer.exe utility program nearly all day.

    As a result, I have found out the reason that the serial_flash_programmer stalls during its execution of my application loading as shown in the following captured image.

    My appplication source file contains a few #pragmas for "ramfuncs" as below.

    --------------------------------------------------------------------------------------------------------

    #ifdef FLASH
    #pragma CODE_SECTION(mainISR,"ramfuncs");
    #pragma CODE_SECTION(MAIN_calculateIrms,"ramfuncs");
    #pragma CODE_SECTION(MAIN_readCurrent,"ramfuncs");
    #pragma CODE_SECTION(timer0ISR,"ramfuncs");
    #pragma CODE_SECTION(spiARxISR,"ramfuncs");
    #pragma CODE_SECTION(spiATxISR,"ramfuncs");
    #endif

    -----------------------------------------------------------------------------------------------------------

    I have found out that, when the above-listed #pragmas are not included, my application is downloaded into the TMS320F28069F device with no problem.

    Therefore I suppose that there is some memory contention between the flash kernel and the included "ramfuncs".

    I guess I may have to modify the linker command file (F28069.cmd) applied for my CCS project, which is attached below.

    --------------------------------------------------------------------------------------------------------------------------------------------------------------------------

    MEMORY
    {
    PAGE 0 :   /* Program Memory */
               /* Memory (RAM/FLASH/OTP) blocks can be moved to PAGE1 for data allocation */
       /*RAML0_1     : origin = 0x008000, length = 0x000C00*/     /* on-chip RAM block L0 and L1 */
       RAML0_1     : origin = 0x008000, length = 0x002000
       OTP         : origin = 0x3D7800, length = 0x000400     /* on-chip OTP */

       FLASHH      : origin = 0x3D8000, length = 0x004000     /* on-chip FLASH */
       FLASHG      : origin = 0x3DC000, length = 0x004000     /* on-chip FLASH */
       FLASHF      : origin = 0x3E0000, length = 0x004000     /* on-chip FLASH */
       FLASHA_B    : origin = 0x3E4000, length = 0x013F80     /* on-chip FLASH A_B + C + D + E*/
       /* FLASHE      : origin = 0x3E4000, length = 0x004000 */    /* on-chip FLASH */  
       /* FLASHD      : origin = 0x3E8000, length = 0x004000 */     /* on-chip FLASH */
       /* FLASHC      : origin = 0x3EC000, length = 0x004000 */    /* on-chip FLASH */  
       /* FLASHA_B    : origin = 0x3F0000, length = 0x007F80 */    /* on-chip FLASH */
       /* CSM_RSVD    : origin = 0x3F7F80, length = 0x000076 */    /* Part of FLASHA.  Program with all 0x0000 when CSM is in use. */
       /* BEGIN       : origin = 0x3F7FF6, length = 0x000002 */    /* Part of FLASHA.  Used for "boot to Flash" bootloader mode. */
       CSM_RSVD    : origin = 0x3F7F80, length = 0x000074     /* Part of FLASHA.  Program with all 0x0000 when CSM is in use. */
       BEGIN       : origin = 0x3F7FF4, length = 0x000004     /* Part of FLASHA.  Used for "boot to Flash" bootloader mode. */
       CSM_PWL_P0  : origin = 0x3F7FF8, length = 0x000008     /* Part of FLASHA.  CSM password locations in FLASHA */

       FPUTABLES   : origin = 0x3FD590, length = 0x0006A0  /* FPU Tables in Boot ROM */
       IQTABLES    : origin = 0x3FDC30, length = 0x000B50    /* IQ Math Tables in Boot ROM */
       IQTABLES2   : origin = 0x3FE780, length = 0x00008C    /* IQ Math Tables in Boot ROM */
       IQTABLES3   : origin = 0x3FE80C, length = 0x0000AA  /* IQ Math Tables in Boot ROM */

       ROM         : origin = 0x3FF3B0, length = 0x000C10     /* 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 */
       RAML2_3     : origin = 0x00A000, length = 0x004000
    /*   RAML2_3     : origin = 0x008C00, length = 0x005400 */    /* on-chip RAM block L2 + L4*/
    /*   RAML2_3     : origin = 0x008C00, length = 0x001400 */    /* on-chip RAM block L2 */
    /*   RAML4       : origin = 0x00A000, length = 0x002000 */    /* on-chip RAM block L4 */
    /*   RAML5       : origin = 0x00C000, length = 0x002000 */    /* on-chip RAM block L5 */
       RAML6       : origin = 0x00E000, length = 0x002000    /* on-chip RAM block L6 */
       RAML7       : origin = 0x010000, length = 0x002000     /* on-chip RAM block L7 */
       RAML8       : origin = 0x012000, length = 0x001800     /* on-chip RAM block L8. From 0x13800 to 0x14000 is reserved for InstaSPIN */
       USB_RAM   : origin = 0x040000, length = 0x000800     /* USB RAM    */  
    }

    /* 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              : > FLASHA_B,   PAGE = 0, ALIGN(4)
       .pinit              : > FLASHA_B,   PAGE = 0, ALIGN(4)
       .text               : > FLASHA_B,   PAGE = 0, ALIGN(4)
       codestart           : > BEGIN,      PAGE = 0, ALIGN(4)
       ramfuncs            : LOAD = FLASHF, /* FLASHD -> FLASHF */
                             RUN = RAML0_1
                             LOAD_START(_RamfuncsLoadStart),
                             LOAD_END(_RamfuncsLoadEnd),
                             RUN_START(_RamfuncsRunStart),
                             PAGE = 0, ALIGN(4)

       csmpasswds          : > CSM_PWL_P0, PAGE = 0
       csm_rsvd            : > CSM_RSVD,   PAGE = 0

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

       graph_data          : > RAML2_3,    PAGE = 1

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

       /* Allocate IQ math areas: */
       IQmath              : > FLASHA_B,   PAGE = 0            /* Math Code */
       IQmathTables        : > IQTABLES,   PAGE = 0, TYPE = NOLOAD
      
       /* Allocate FPU math areas: */
       FPUmathTables       : > FPUTABLES,  PAGE = 0, TYPE = NOLOAD
      
    /*   DMARAML5            : > RAML5,      PAGE = 1 */
       DMARAML6            : > RAML6,      PAGE = 1
       DMARAML7            : > RAML7,      PAGE = 1
       DMARAML8            : > RAML8,      PAGE = 1  

      /* 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, IQmathTables3
          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

    }

    ---------------------------------------------------------------------------------------------------------------------------------------------------------------

    Please inform me how to modify the linker command file if it has to be.

    Thank you for your guidance.

    With regards,

    G. Kim

  • G. Kim,

    What is the behavior you are seeing when it is unsuccessful?

    You should be able to use ramfuncs as long as it is linked to load to flash and then run from RAM, which it appears you have done correctly. It may be worth double checking you have used ramfuncs properly and make sure it is loaded to flash and copied to and run from RAM.

    When using the flash kernel, you need to ensure that the entire application which is being loaded resides 100% in flash.

    sal
  • Dear Sal,

    Thank you for your review.

    Today I have worked with the serial_flash_programmer.exe utility program and resolved this issue at last.

    It is somewhat related with the flash memory allocation in the linker command file, in association with the section of ramfuncs.

    I made a few modifications to the linker command file as follows:

    -------------------------------------------------------------------------------------------------------------------------------------------------------

    PAGE 0 :   /* Program Memory */

              /* Memory (RAM/FLASH/OTP) blocks can be moved to PAGE1 for data allocation */

      /*RAML0_1     : origin = 0x008000, length = 0x000C00*/     /* on-chip RAM block L0 and L1 */

      RAML0_1     : origin = 0x008000, length = 0x002000

      OTP         : origin = 0x3D7800, length = 0x000400     /* on-chip OTP */

      FLASHH      : origin = 0x3D8000, length = 0x004000     /* on-chip FLASH */

      FLASHG      : origin = 0x3DC000, length = 0x004000     /* on-chip FLASH */

      FLASHF      : origin = 0x3E0000, length = 0x004000     /* on-chip FLASH */

      FLASHE      : origin = 0x3E4000, length = 0x004000     /* on-chip FLASH */

      FLASHD      : origin = 0x3E8000, length = 0x004000      /* on-chip FLASH */

      FLASHA_B    : origin = 0x3EC000, length = 0x00BF80     /* on-chip FLASH A_B + C */

    ------------------------------------------------------------------------------------------------------------------------------------------------------

    SECTIONS

    {

      /* Allocate program areas: */

      .cinit              : > FLASHA_B,   PAGE = 0, ALIGN(4)

      .pinit              : > FLASHA_B,   PAGE = 0, ALIGN(4)

      .text               : > FLASHA_B,   PAGE = 0, ALIGN(4)

      codestart           : > BEGIN,      PAGE = 0, ALIGN(4)

      ramfuncs            : LOAD = FLASHD,

                            RUN = RAML0_1

                            LOAD_START(_RamfuncsLoadStart),

                            LOAD_END(_RamfuncsLoadEnd),

                            RUN_START(_RamfuncsRunStart),

                            PAGE = 0, ALIGN(4)

    ---------------------------------------------------------------------------------------------------------------------------------------------------------

    After rebuilding my application on the CCS with only this modifiation in the LCM file and generating the .txt file, I executed the serial_flash_programmer.exe utility program. Then my application was loaded into the DSP device successfully as shown below.

    It took around 106 seconds for the serial flash programmer utility to load my application into the DSP.

    Meanwhile, when I employ the ramfuncs section as follows: ramfuncs            : LOAD = FLASHE, the serial flash programmer utility halted in about 75 seconds.

    I need your guidance as follows:

    (1) Please check the serial flash programmer utility in association with the flash mewmory allocation for the ramfuncs section.

    (2) When the flash kernel file is loaded into the RAM area, where is it loaded? Page 0 or Page 1? Which RAM block?

    Thank you in advance.

    With regards,

    G. Kim

  • G. Kim,

    (1) The serial flash programmer does not care what sections are loaded where? It merely reads the hex file and sends the data to the device and waits for handshake back from the device.

    (2) You can see this yourself. It is loaded entirely in RAM. The SCI flash kernel CCS project is provided in C2000Ware. You can see where it is linked.

    Glad you got it worked out.

    sal
  • Dear Sal,

    Thank you for your review.

    The halting problem of the serial flash programmer, when <ramfuncs : LOAD = FLASHE,> is allocated in the LCM file, may have been arisen from the SCI flash kernel.

    Even though this issue has been resolved by allocating <ramfuncs : LOAD = FLASHD,>  in the LCM file, I may have to allocate <ramfuncs : LOAD = FLASHE,> when the code size of my application becomes bigger in near future.

    Would you please check the SCI flash kernel CCS project for me?

    Thank you for your guidance.

    With regards,

    G. Kim

  • Hi G. Kim,

    I am not sure what you are asking. It shouldn't matter whether it is in sector W or F. So, I am not sure what the issue may be.

    Please be more specific with your question if is it still not working.

    Otherwise, click this has resolved my issue to close the thread.

    Thanks,
    sal
  • Hi G. Kim,

    I noticed you posted on another thread and it should be resolved there.

    e2e.ti.com/.../796537

    If you see the SCI flash kernel, you will notice it only erases sectors A, B, C, D before programming the flash application. Since your device has more sectors, please modify the SCI flash kernel to erase all the sectors you are updated with the flash application. This will resolve your issue.

    sal