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.

TMS320F28035: Bootloader Problem

Part Number: TMS320F28035

Hi, my name is Fernando from Argentina

I am using the TMS320F28035. I have a program that works OK.

Now, I am trying to flash this Application using the bootloader.

I followed exactly the steps stated in the Application Report SPRABV4B Serial Flash Programming of C2000™ Microcontrollers

I compile the flash Kernel provided. I also generate the sci8 of my application.

I run the application like this.

serial_flash_programmer -d f2803x -k f2803x_flash_kernel.txt -a CARGADOR.txt -p COM11


Watching the signals. Everything seems to works fine. When is loading the flash kernel you can see the echo done by target.

When is loading the application I only see some bytes that is suppose to be the cheksums.

There are no error messages of the host application. But the loaded application doesn´t works.

The kernel seems to erase the Piccolo because the application that was running before I try the bootloader doesn´t works anymore. But the new doesn´t

I don´t know where to start or if there is some configuration to be done in my application.

       Best Regards

          Fernando

  • I have activated the verbose.

    It appears the Message Application AutoBaud Successful. But there is no other message. So Something could be wrong when is loading the application. Probably I have to change something of my application. But I don´t know what

    Regards
  • Hi Fernando,

    The flash kernel will first erase the contents of the flash and then load the flash application via SCI and program it into the flash using the flash API.

    Make sure that your flash application resides entirely in the flash. No RAM contents. Make sure your flash application is linked entirely to flash.

    You can begin to debug by loading the kernel via the debugger and executing it with the serial flash programmer. Just comment out the downloadKernel() function in the serial flash programmer.

    Hope this helps.
    sal
  • Hi Sal,
    Thanks for you rapid response.

    Regarding the thing that the entirely application must resides in the flash i have the following doubt

    In this application I am using the flash api. As this functions must resides in RAM, I use the #pragma CODE_SECTION(FlashAPISaver,"ramfuncs") directive in all the places where I need to call the Flash APi.

    At the start of main I use

    memcpy((uint16_t *)&RamfuncsRunStart,(uint16_t *)&RamfuncsLoadStart, (unsigned long)&RamfuncsLoadSize);

    I have tried to flash another small program that I made to test PWMs and the bootloader in this case works fine.

    So It is clearly a Problem of how my application is Linked. But I am not sure of how to fix it

    Here is my linker command, maybe you could see something wrong

    MEMORY
    {
    PAGE 0: /* Program Memory */
    /* Memory (RAM/FLASH/OTP) blocks can be moved to PAGE1 for data allocation */
    RAML0 : origin = 0x008000, length = 0x000800 /* on-chip RAM block L0 */
    RAML1 : origin = 0x008800, length = 0x000400 /* on-chip RAM block L1 */
    OTP : origin = 0x3D7800, length = 0x000400 /* on-chip OTP */
    //FLASHG : origin = 0x3EA000, length = 0x002000 /* on-chip FLASH */
    FLASHF : origin = 0x3EC000, length = 0x002000 /* on-chip FLASH */
    FLASHE : origin = 0x3EE000, length = 0x002000 /* on-chip FLASH */
    FLASHD : origin = 0x3F0000, length = 0x002000 /* on-chip FLASH */
    //FLASHC : origin = 0x3F2000, length = 0x002000 /* on-chip FLASH */
    //FLASHA : origin = 0x3F6000, length = 0x001F80 /* on-chip FLASH */
    FLASHA : origin = 0x3F2000, length = 0x005F80 /* 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_PWL_P0 : origin = 0x3F7FF8, length = 0x000008 /* Part of FLASHA. CSM password locations in FLASHA */

    IQTABLES : origin = 0x3FE000, length = 0x000B50 /* IQ Math Tables in Boot ROM */
    IQTABLES2 : origin = 0x3FEB50, length = 0x00008C /* IQ Math Tables in Boot ROM */
    IQTABLES3 : origin = 0x3FEBDC, length = 0x0000AA /* IQ Math Tables in Boot ROM */

    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 */
    RAML2 : origin = 0x008C00, length = 0x000400 /* on-chip RAM block L2 */
    RAML3 : origin = 0x009000, length = 0x001000 /* on-chip RAM block L3 */
    //FLASHB : origin = 0x3F4000, length = 0x002000 /* on-chip FLASH */
    FLASHH : origin = 0x3E8000, length = 0x002000 /* on-chip FLASH */
    FLASHG : origin = 0x3EA000, length = 0x002000 /* 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 : > FLASHA PAGE = 0
    .pinit : > FLASHA PAGE = 0
    .text : > FLASHA PAGE = 0
    codestart : > BEGIN PAGE = 0
    ramfuncs : LOAD = FLASHD,
    RUN = RAML0,
    LOAD_START(_RamfuncsLoadStart),
    LOAD_SIZE(_RamfuncsLoadSize),
    RUN_START(_RamfuncsRunStart),
    PAGE = 0

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

    /* Allocate uninitalized data sections: */
    .stack : > RAMM0 PAGE = 1
    .ebss : > RAML2, fill = 0x00 PAGE = 1
    .esysmem : > RAML2 PAGE = 1

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

    AJUSTES_RUN : > FLASHH PAGE = 1
    AJUSTES_CAL : > FLASHG PAGE = 1

    /* Allocate IQ math areas: */
    IQmath : > FLASHA 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

    }


    Best Regards
    Fernando
  • Fernando, the linker command file looks fine to me. As long as the ramfuncs is being loaded to flash and run from RAM, then everything should be OK as long as you do not directly load things to RAM. which is looks like you are not doing this.

    I am not sure what the problem is right now. The bootloader does an echo-back and the kernel does a checksum. So what you are seeing is correct.

    You can begin to debug by loading the kernel via the debugger and executing it with the serial flash programmer. Just comment out the downloadKernel() function in the serial flash programmer. You can see what is going on when you finish loading the application and then branch to the application from the kernel. set a breakpoint at this point and see what is going on.

    sal
  • Ok Sal, I will try to debug as you propose

    Thanks
  • Hi Sal,
    After doing debug with both programs at the same time, I realized that the Kernel was receiving a section of data initizialized with 0 pointing to RAM, obviusly the FlashApi returns an error.

    After checking this I notice that in linker comand I have

    .ebss : > RAML2, fill = 0x00 PAGE = 1

    The fill options is the problem

    By the way I added a filter of valid flash´s directions in the Kernel program and problem solved

    Thank you for your Help
  • Frenando,

    Great!

    Can you explain this statement, "By the way I added a filter of valid flash´s directions in the Kernel program and problem solved" ? Or give me an example, please?


    sal
  • Hi Sal,

               What I mean is this

    if ( ( BlockHeader.DestAddr >= 0x3E8000) && ( BlockHeader.DestAddr < 0x3F8000 ) )
    {
           status = Flash_Program((Uint16 *) BlockHeader.DestAddr, (Uint16 *)progBuf, BlockHeader.BlockSize, &FlashStatus);
           if(status != STATUS_SUCCESS)
           {
                  return ;
           }
    }

    If the Direction is not a valid one of the TMS320F28035, the Flash_Program function isn't called

    Regards

  • Got it! Makes sense.

    Thanks,
    sal