Because of the holidays, TI E2E™ design support forum responses will be delayed from Dec. 25 through Jan. 2. Thank you for your patience.

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.

TMS320F28075 freezes when enabling the flash API

Other Parts Discussed in Thread: TMS320F28075, TMS320F28377D, CONTROLSUITE

After programming the TMS320F28075 numerous times, it has suddenly developed a strange issue after programming the device over a JTAG connection from Code Composer.  Stepping through the code shows that it seems to get stuck after calling "Fapi_setActiveFlashBank(Fapi_FlashBank0);" in my source below (most of which was copied from the Control Suite examples).  Looking at the disassembly view, I see that after entering "Fapi_setActiveFlashBank(Fapi_FlashBank0)", the code jumps to address 0x3fe493 where the asm command is ESTOP.  I see that the memory address corresponds to Secure ROM, so I'm not really sure what is going on in there.  When stepping through the source, I see that the previous API call to "Fapi_initializeAPI(F021_CPU0_BASE_ADDRESS, 120)" was successful.  In InitSysCtrl, I have defined _FLASH so that the API gets moved into RAM and InitFlash is called.  This issue has happened before and after 20 or so attempts at programming the device via JTAG, the issue disappeared.  My problem seems similar to this issue https://e2e.ti.com/support/microcontrollers/c2000/f/171/p/399191/1454360%22, but I did not see any suggestions other than that the Control Suite version might be causing the issue - could it be the version of F021_API_F2837xD_FPU32.lib that I should change?  I did think it was odd that this was the API in Control Suite even though the chip is different.

Note: commenting out the call to "Fapi_setActiveFlashBank(Fapi_FlashBank0);" allows the device to be programmed and run properly.

void main(void)
{
// initialize the system

InitSysCtrl();

Fapi_StatusType oReturnCheck;
EALLOW;
Flash0EccRegs.ECC_ENABLE.bit.ENABLE = 0x0;

oReturnCheck = Fapi_initializeAPI(F021_CPU0_BASE_ADDRESS, 120);//for now keeping it out
// make sure flash initialization was successful
if(oReturnCheck != Fapi_Status_Success) {
// error handling
}

oReturnCheck = Fapi_setActiveFlashBank(Fapi_FlashBank0);
// make sure the setting the active flash bank was successful
if(oReturnCheck != Fapi_Status_Success) {
// error handling
}
EDIS;

  • Benjamin,

    1) What are the wait-states that you are using in the Flash initialization routine?
    2) It is not clear from your post on exactly when the issue is happening. Is it happening after you load the code to Flash using CCS Flash Plugin? If yes, what did you program using CCS Flash Plugin ?- I mean what does that application do?
    3) Did you try to give a debug reset before programming the Flash contents using CCS Flash Plugin?
    4) Did you try to give a debug reset after programming the Flash contents using CCS Flash Plugin and before doing a restart?
    5) What are the PLL GUI settings that are using in CCS Flash Plugin?
    6) You said the issue disappeared. Did it disappear after few more trials of programming using API or using CCS Flash Plugin?
    7) Can you share your project?
    8) I am looking in to the BootROM location that you mentioned. Will let you know.
    9) I am not able to access the forum post link that you mentioned. Are you able to access it? What is discussed in it?
    10) You can use F021_API_F2837xD_FPU32.lib to do erase/program operations on F28075 Flash bank since F2837xD and F2807x share the same flash bank architecture.

    Thanks and regards,
    Vamsi
  • 1. The "F2807x_SysCtrl.c" file was not modified from Control Suite v190, so my waitstate setting is Flash0CtrlRegs.FRDCNTL.bit.RWAIT = 0x2;.  FlashInit is called inside "InitSysCtrl".

    2. The issue happens whenever I run the code.  This means that it happens on a power cycle (the code will not run), running from CCS debug, or doing a CPU reset from CCS debug.  Stepping through the code I know that the function call to Fapi_setActiveFlashBank causes the MCU to jump to 0x3fe493 and stop program execution.  I have stripped the application down to simply enable flash and enter an infinite loop to blink LED's.  Commenting out the call to Fapi_setActiveFlashBank allows the program to actually get to the LED blinking portion of main().

    3. Is CCS Flash Plugin the utility that flashes the code into the MCU when clicking the Debug button in Code Composer?  If so, then yes, doing a CPU reset results in the same issue.  

    4. Yes, same issue.

    5.  OSCCLK(MHz)(INTOSC2) = 10, SPLLIMULT = 24, SPLLFMULT = 0, SYSDIVSEL = 1[/2]

    6.  The only calls to the flash API that were made are Fapi_initializeAPI and Fapi_setActiveFlashBank - the current code does not do any flash erase or flash writes.  The issue went away after erasing and reprogramming the device through CCS - no code modifications were made.  The issue has since returned.

    7. Not sure if I am allowed to upload, will get back to you on that.

    9. The post was by  titled TMS320F28377D: Flash programming issue.  The only real similarity was the memory address I mentioned.  He was actually getting an error message reported back (I do not).  They told him to update his version of Control Suite. 

  • I've been running a number of tests to try to figure out what is going on. I got the code to successfully return from the "Fapi_setActiveFlashBank(Fapi_FlashBank0)" function by commenting out some global variables and functions unrelated to the flash API initialization functions. This made me think the real issue had to do with memory/linking rather than the code itself. The issue seemed to go away after modifying my .cmd file. I will post both versions of the .cmd file below (the broken one first, and the one that works second). I would appreciate it if you can explain what I was doing wrong initially.

    Notice that the only difference between the two is that in the first, PROG is defined to be FLASHA, FLASHB, and FLASHC. In the second PROG is defined to be FLASHB, FLASHC, and FLASHD. According to the .map file, the used portion of PROG is only 00003be2.

    MEMORY
    {
    PAGE 0 : /* Program Memory */
    /* Memory (RAM/FLASH) blocks can be moved to PAGE1 for data allocation */
    /* BEGIN is used for the "boot to Flash" bootloader mode */

    BEGIN : origin = 0x080000, length = 0x000002
    //RAMLS0 : origin = 0x008000, length = 0x000800
    //RAMLS1 : origin = 0x008800, length = 0x000800
    //RAMLS2 : origin = 0x009000, length = 0x000800
    //RAMLS3 : origin = 0x009800, length = 0x000800
    //RAMLS4 : origin = 0x00A000, length = 0x000800
    RAMLS : origin = 0x008000, length = 0x002800
    RESET : origin = 0x3FFFC0, length = 0x000002

    /* Flash sectors */

    PROG : origin = 0x080002, length = 0x005FFE /* Program code - unified flash */
    //FLASHA : origin = 0x080002, length = 0x001FFE /* on-chip Flash */
    //FLASHB : origin = 0x082000, length = 0x002000 /* on-chip Flash */
    //FLASHC : origin = 0x084000, length = 0x002000 /* on-chip Flash */
    FLASHD : origin = 0x086000, length = 0x002000 /* on-chip Flash */
    FLASHE : origin = 0x088000, length = 0x008000 /* on-chip Flash */
    FLASHF : origin = 0x090000, length = 0x008000 /* on-chip Flash */
    FLASHG : origin = 0x098000, length = 0x008000 /* on-chip Flash */
    FLASHH : origin = 0x0A0000, length = 0x008000 /* on-chip Flash */
    FLASHI : origin = 0x0A8000, length = 0x008000 /* on-chip Flash */
    FLASHJ : origin = 0x0B0000, length = 0x008000 /* on-chip Flash */
    FLASHK : origin = 0x0B8000, length = 0x002000 /* on-chip Flash */

    PAGE 1 : /* Data Memory */
    /* Memory (RAM/FLASH) blocks can be moved to PAGE0 for program allocation */

    BOOT_RSVD : origin = 0x000002, length = 0x000120 /* Part of M0, BOOT rom will use this for stack */
    RAMM0 : origin = 0x000122, length = 0x0002DE
    RAMM1 : origin = 0x000400, length = 0x000400 /* on-chip RAM block M1 */
    RAMD0 : origin = 0x00B000, length = 0x000800
    RAMD1 : origin = 0x00B800, length = 0x000800

    RAMLS5 : origin = 0x00A800, length = 0x000800

    RAMGS0 : origin = 0x00C000, length = 0x001000
    RAMGS1 : origin = 0x00D000, length = 0x001000
    RAMGS2 : origin = 0x00E000, length = 0x001000
    RAMGS3 : origin = 0x00F000, length = 0x001000
    RAMGS4 : origin = 0x010000, length = 0x001000
    RAMGS5 : origin = 0x011000, length = 0x001000
    RAMGS6 : origin = 0x012000, length = 0x001000
    RAMGS7 : origin = 0x013000, length = 0x001000


    FLASHL : origin = 0x0BA000, length = 0x002000 /* on-chip Flash */
    FLASHM : origin = 0x0BC000, length = 0x002000 /* on-chip Flash */
    FLASHN : origin = 0x0BE000, length = 0x002000 /* on-chip Flash */
    }


    SECTIONS
    {
    /* Allocate program areas: */
    .cinit : > PROG PAGE = 0, ALIGN(4)
    .pinit : > PROG, PAGE = 0, ALIGN(4)
    .text : >> PROG PAGE = 0, ALIGN(4)
    codestart : > BEGIN PAGE = 0, ALIGN(4)
    ramfuncs : LOAD = PROG,
    RUN = RAMLS,
    LOAD_START(_RamfuncsLoadStart),
    LOAD_SIZE(_RamfuncsLoadSize),
    LOAD_END(_RamfuncsLoadEnd),
    RUN_START(_RamfuncsRunStart),
    RUN_SIZE(_RamfuncsRunSize),
    RUN_END(_RamfuncsRunEnd),
    PAGE = 0, ALIGN(4)

    /* Allocate uninitalized data sections: */
    .stack : > RAMD0 PAGE = 1
    .ebss : >> RAMGS6 | RAMGS7 PAGE = 1
    .esysmem : >> RAMGS6 | RAMGS7 PAGE = 1

    /* Initalized sections go in Flash */
    .econst : >> PROG PAGE = 0, ALIGN(4)
    .switch : > PROG PAGE = 0, ALIGN(4)

    .reset : > RESET, PAGE = 0, TYPE = DSECT /* not used, */

    ramgs0 : > RAMGS0, PAGE = 1
    ramgs1 : > RAMGS1, PAGE = 1

    /* The following section definition are for SDFM examples */
    Filter1_RegsFile : > RAMGS1, PAGE = 1, fill=0x1111
    Filter2_RegsFile : > RAMGS2, PAGE = 1, fill=0x2222
    Filter3_RegsFile : > RAMGS3, PAGE = 1, fill=0x3333
    Filter4_RegsFile : > RAMGS4, PAGE = 1, fill=0x4444
    Difference_RegsFile : >RAMGS5, PAGE = 1, fill=0x3333

    }





    MEMORY
    {
    PAGE 0 : /* Program Memory */
    /* Memory (RAM/FLASH) blocks can be moved to PAGE1 for data allocation */
    /* BEGIN is used for the "boot to Flash" bootloader mode */

    BEGIN : origin = 0x080000, length = 0x000002
    //RAMLS0 : origin = 0x008000, length = 0x000800
    //RAMLS1 : origin = 0x008800, length = 0x000800
    //RAMLS2 : origin = 0x009000, length = 0x000800
    //RAMLS3 : origin = 0x009800, length = 0x000800
    //RAMLS4 : origin = 0x00A000, length = 0x000800
    RAMLS : origin = 0x008000, length = 0x002800
    RESET : origin = 0x3FFFC0, length = 0x000002

    /* Flash sectors */

    FLASHA : origin = 0x080002, length = 0x001FFE /* on-chip Flash */
    PROG : origin = 0x082000, length = 0x006000 /* Program code - unified flash*/
    //FLASHB : origin = 0x082000, length = 0x002000 /* on-chip Flash */
    //FLASHC : origin = 0x084000, length = 0x002000 /* on-chip Flash */
    //FLASHD : origin = 0x086000, length = 0x002000 /* on-chip Flash */
    FLASHE : origin = 0x088000, length = 0x008000 /* on-chip Flash */
    FLASHF : origin = 0x090000, length = 0x008000 /* on-chip Flash */
    FLASHG : origin = 0x098000, length = 0x008000 /* on-chip Flash */
    FLASHH : origin = 0x0A0000, length = 0x008000 /* on-chip Flash */
    FLASHI : origin = 0x0A8000, length = 0x008000 /* on-chip Flash */
    FLASHJ : origin = 0x0B0000, length = 0x008000 /* on-chip Flash */
    FLASHK : origin = 0x0B8000, length = 0x002000 /* on-chip Flash */

    PAGE 1 : /* Data Memory */
    /* Memory (RAM/FLASH) blocks can be moved to PAGE0 for program allocation */

    BOOT_RSVD : origin = 0x000002, length = 0x000120 /* Part of M0, BOOT rom will use this for stack */
    RAMM0 : origin = 0x000122, length = 0x0002DE
    RAMM1 : origin = 0x000400, length = 0x000400 /* on-chip RAM block M1 */
    RAMD0 : origin = 0x00B000, length = 0x000800
    RAMD1 : origin = 0x00B800, length = 0x000800

    RAMLS5 : origin = 0x00A800, length = 0x000800

    RAMGS0 : origin = 0x00C000, length = 0x001000
    RAMGS1 : origin = 0x00D000, length = 0x001000
    RAMGS2 : origin = 0x00E000, length = 0x001000
    RAMGS3 : origin = 0x00F000, length = 0x001000
    RAMGS4 : origin = 0x010000, length = 0x001000
    RAMGS5 : origin = 0x011000, length = 0x001000
    RAMGS6 : origin = 0x012000, length = 0x001000
    RAMGS7 : origin = 0x013000, length = 0x001000


    FLASHL : origin = 0x0BA000, length = 0x002000 /* on-chip Flash */
    FLASHM : origin = 0x0BC000, length = 0x002000 /* on-chip Flash */
    FLASHN : origin = 0x0BE000, length = 0x002000 /* on-chip Flash */
    }


    SECTIONS
    {
    /* Allocate program areas: */
    .cinit : > PROG PAGE = 0, ALIGN(4)
    .pinit : > PROG, PAGE = 0, ALIGN(4)
    .text : >> PROG PAGE = 0, ALIGN(4)
    codestart : > BEGIN PAGE = 0, ALIGN(4)
    ramfuncs : LOAD = PROG,
    RUN = RAMLS,
    LOAD_START(_RamfuncsLoadStart),
    LOAD_SIZE(_RamfuncsLoadSize),
    LOAD_END(_RamfuncsLoadEnd),
    RUN_START(_RamfuncsRunStart),
    RUN_SIZE(_RamfuncsRunSize),
    RUN_END(_RamfuncsRunEnd),
    PAGE = 0, ALIGN(4)

    /* Allocate uninitalized data sections: */
    .stack : > RAMD0 PAGE = 1
    .ebss : >> RAMGS6 | RAMGS7 PAGE = 1
    .esysmem : >> RAMGS6 | RAMGS7 PAGE = 1

    /* Initalized sections go in Flash */
    .econst : >> PROG PAGE = 0, ALIGN(4)
    .switch : > PROG PAGE = 0, ALIGN(4)

    .reset : > RESET, PAGE = 0, TYPE = DSECT /* not used, */

    ramgs0 : > RAMGS0, PAGE = 1
    ramgs1 : > RAMGS1, PAGE = 1

    /* The following section definition are for SDFM examples */
    Filter1_RegsFile : > RAMGS1, PAGE = 1, fill=0x1111
    Filter2_RegsFile : > RAMGS2, PAGE = 1, fill=0x2222
    Filter3_RegsFile : > RAMGS3, PAGE = 1, fill=0x3333
    Filter4_RegsFile : > RAMGS4, PAGE = 1, fill=0x4444
    Difference_RegsFile : >RAMGS5, PAGE = 1, fill=0x3333

    }
  • Benjamin,

    Where is the Flash API getting loaded and where is it getting executed from?  

    Flash API should be executed from RAM on this device.  You can load it to Flash but should be moved to RAM before executing it.

    See below linker command file snippet taken from C:\ti\controlSUITE\device_support\F2807x\v190\F2807x_examples_Cpu1\flash_programming\cpu01\flash_programming_cpu1_FLASH.cmd :

    GROUP
    {
    ramfuncs
    { -l F021_API_F2837xD_FPU32.lib}

    } LOAD = FLASHD,
    RUN = RAMLS03,
    LOAD_START(_RamfuncsLoadStart),
    LOAD_SIZE(_RamfuncsLoadSize),
    LOAD_END(_RamfuncsLoadEnd),
    RUN_START(_RamfuncsRunStart),
    RUN_SIZE(_RamfuncsRunSize),
    RUN_END(_RamfuncsRunEnd),
    PAGE = 0

     

    Thanks and regards,
    Vamsi

  • Thanks, I added the linker commands to run the flash API out of RAM.  I am curious though, why the flash API functions would sometimes work even though they were running out of flash?  Shouldn't it have failed every time?

  • The flash fetch and buffer fill will change slightly depending on the alignment of the code. I believe what you have experienced is an artifact of this. If it happens that nothing is being fetched when the flash becomes unavailable then it is "ok". However if code is being fetched things go wrong.