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.

TMS320F28384D: Flash Erase and program while debug mode hangs & make processor asm "estop0"

Part Number: TMS320F28384D

Dear TI team,

       We have our custom board using  TMS320F28384D , our application is to write value in flash sector (Bzero_Sector6_start )  of regular interval 10secs..its working fine in running state, 

while(program_start==1)
{
if(Write_Sec>=10){
spindle_parameter();
Flash_claimPumpSemaphore(FLASH_CPU1_WRAPPER);
EEPROM_Erase(Bzero_Sector6_start);
EEPROM_ProgramSingleByte(spindle1_parameter,12,Bzero_Sector6_start);
Flash_releasePumpSemaphore();
Write_Sec=0;}
}

but while I connect debugger in debug mode ,  we are facing a issue that erase sector function fails and processor gets hang( estop) in EEPROM_Erase(); function

Most case, while in debug mode works fine for 1 to 2 minute ..after that program get strucks in erase function.

processor struck in "oReturnCheck = Fapi_issueAsyncCommandWithAddress(Fapi_EraseSector,(uint32*)Bzero_SectorB_start2);"" please find function below.

//############################ EEPROM_ERASE_START- Sector C ######################################################################################

void EEPROM_Erase(uint32 ERASESECTOR)
{
DINT;
EALLOW;
uint32 Bzero_SectorB_start2;
Bzero_SectorB_start2= ERASESECTOR;
oReturnCheck = Fapi_issueAsyncCommandWithAddress(Fapi_EraseSector,(uint32*)Bzero_SectorB_start2);
//
// Wait until FSM is done with erase sector operation
//
while (Fapi_checkFsmForReady() != Fapi_Status_FsmReady){

}

// Read FMSTAT register contents to know the status of FSM after
// erase command to see if there are any erase operation related errors
//
oFlashStatus = Fapi_getFsmStatus();
if(oFlashStatus != 0)
{
//
// Check Flash API documentation for FMSTAT and debug accordingly
// Fapi_getFsmStatus() function gives the FMSTAT register contents.
// Check to see if any of the EV bit, ESUSP bit, CSTAT bit or
// VOLTSTAT bit is set (Refer to API documentation for more details).
//
__asm(" ESTOP0");
}
//
// Verify that SectorL is erased. The Erase step itself does a
// verify as it goes. This verify is a 2nd verification that can be done.
//
oReturnCheck = Fapi_doBlankCheck((uint32 *)Bzero_SectorB_start2,
Bzero_64KSector_u32length,
&oFlashStatusWord);

if(oReturnCheck != Fapi_Status_Success)
{

//
// Check Flash API documentation for possible errors
// If Erase command fails, use Fapi_getFsmStatus() function to get the
// FMSTAT register contents to see if any of the EV bit, ESUSP bit,
// CSTAT bit or VOLTSTAT bit is set (Refer to API documentation for
// more details)
//
Example_Error(oReturnCheck);
}
c1=4;
EDIS;
EINT;
}

kindly, help us to solve this issue and provide a solution 

Thanks & Regards,

Ajay S 

  • Hi Ajay,

    I will review this and get back to you in a day or two.

    Thanks and regards,
    Vamsi

  • Ajay,

    Are flash API and EEPROM_Erase() mapped to execute from RAM or not?  They should be mapped to RAM - please confirm.

    Also, I noticed in your code snippet that the erase function is hardcoded to always erase sectorB irrespective of which address you pass in - Is that intentional?

    Thanks and regards,
    Vamsi

  •  Vamsi,

        yes, we have executing  "EEPROM_ERASE" in ram function  as mentioned below . As our application need to update value in every 10secs ..so we are hard-coding erase sector purposely.. kindly provide us better solution for hard-coding.

    main.c:

     #pragma CODE_SECTION(EEPROM_Erase,"TI.ramfunc");
     #pragma CODE_SECTION(EEPROM_Write,"TI.ramfunc");
     

    flash linker command file:
       GROUP
       {
           .TI.ramfunc
           { -l F2838x_C28x_FlashAPI.lib}

       } LOAD = FLASH3,
         RUN = RAMLS03,
         LOAD_START(RamfuncsLoadStart),
         LOAD_SIZE(RamfuncsLoadSize),
         LOAD_END(RamfuncsLoadEnd),
         RUN_START(RamfuncsRunStart),
         RUN_SIZE(RamfuncsRunSize),
         RUN_END(RamfuncsRunEnd),
         ALIGN(8)

    Thanks&regards,

    Ajay S

  • Ajay,

    You are executing both the flash API and EEPROM_Erase from RAM - which is good.

    When you say it halts at ESTOP-> Do you mean the ESTOP in the code snippet that you showed near the oFlashStatus check?  OR is it ending up in a BootROM address?  If it is a BootROM address, can you check if it falls in to any of the below ranges?  

    Regarding hard-coding:  Sorry, I missed reading "Bzero_SectorB_start2= ERASESECTOR;" in your code.  I now see that it is not hard-coded and is actually taking the parameter passed in for sector erase. 

    Please note: I am out of office up to March 3rd.  Please expect delay in my response.

    Thanks and regards,

    Vamsi

  • Dear Vamsi,

          Thanks for the response. As mentioned ,when the processor hangs in ERASE SECTOR Function.

    step1:

    initial code hangs in " oReturnCheck = Fapi_issueAsyncCommandWithAddress(Fapi_EraseSector,

    (uint32*)Bzero_SectorB_start2);"

    step2:

       When forces the code execution to stepover.

    step3:

     when try to resume the code execution "RESUME"

    NOTE: "CPU2 GETTING HELD IN RESET"

    C28xx_CPU2: Only CPU1 on-chip Flash Plugin can configure clock for CPU1, CPU2 and CM Flash operations. Plugin automatically configures PLL when CPU1 Flash operations are invoked. However, if users want to do only CPU2 or CM Flash operations without doing a prior CPU1 operation in the current session, they should click on 'Configure Clock' button in CPU1's on-chip Flash Plugin before invoking CPU2 and CM Flash operations. When this button is used, Flash Plugin will configure the clock for CPU1/CPU2 at 190MHz and CM at 95MHz using INTOSC2 as the clock source. Plugin will leave PLL config like this and user application should configure the PLL as required by application.
    C28xx_CPU2: Trouble Reading Register PC: (Error -1137 @ 0x0) Device is held in reset. Take the device out of reset, and retry the operation. (Emulation package 9.2.0.00002)
    C28xx_CPU2: Trouble Reading Register RPC: (Error -1137 @ 0x13) Device is held in reset. Take the device out of reset, and retry the operation. (Emulation package 9.2.0.00002)
    C28xx_CPU2: Trouble Reading Register ST1: (Error -1137 @ 0x6) Device is held in reset. Take the device out of reset, and retry the operation. (Emulation package 9.2.0.00002)
    C28xx_CPU2: Trouble Reading Register PC: (Error -1137 @ 0x0) Device is held in reset. Take the device out of reset, and retry the operation. (Emulation package 9.2.0.00002)
    C28xx_CPU2: Trouble Reading Register RPC: (Error -1137 @ 0x13) Device is held in reset. Take the device out of reset, and retry the operation. (Emulation package 9.2.0.00002)
    C28xx_CPU2: Trouble Reading Register ST1: (Error -1137 @ 0x6) Device is held in reset. Take the device out of reset, and retry the operation. (Emulation package 9.2.0.00002)
    C28xx_CPU2: Trouble Reading Register PC: (Error -1137 @ 0x0) Device is held in reset. Take the device out of reset, and retry the operation. (Emulation package 9.2.0.00002)
    C28xx_CPU2: Trouble Reading Register RPC: (Error -1137 @ 0x13) Device is held in reset. Take the device out of reset, and retry the operation. (Emulation package 9.2.0.00002)
    C28xx_CPU2: Trouble Reading Register ST1: (Error -1137 @ 0x6) Device is held in reset. Take the device out of reset, and retry the operation. (Emulation package 9.2.0.00002)
    C28xx_CPU2: Trouble Reading Register PC: (Error -1137 @ 0x0) Device is held in reset. Take the device out of reset, and retry the operation. (Emulation package 9.2.0.00002)

    "Is it ending up in a Bootrom address?"

            Where we have to check the Bootrom address ,not yet checked out ? kindly help us and provide us solution.

    As we have checked out with FAPI Technical reference manual,

     our application need to erase and write 24bytes every 10secs once for 365days . Then also after from power failure we will retrieve the values. kindly suggest us lifetime of f28384d or need to go with external "SRAM".

    Thanks& Regards,

    Ajay S

  • Hi Ajay,

    1) Address 0x3FE96F in your CCS debug window snapshot is the ITRAP ISR in BootROM space.  Meaning, CPU executed an illegal opcode.  Please make sure the flash API code and the EEPROM_Erase() are still intact in RAM when you notice this issue.

    2) Regarding your flash erase usage:  How many times is the sector erased in your application totally?  It is not clear from your message.  Below datasheet flash parameter spec table shows that a sector can be erased for a max of 20k times.

    Thanks and regards,

    Vamsi

  • Dear TI Team,

            Hope u were back to work,

           2. We are erasing sector every 10 secs once - for a minute 6 times for a whole 365 days, this means if we erase  and write  likewise . How long will be the lifecycle of sector? and How long will be life of processor ?

            1.We are executing flash code with "ram function",Herewith attached linker file for your reference.

    How we can check bootrom space and illegal code execution?  Help us to solve the illegal code executed and resolve this error.

     

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    MEMORY
    {
    /* BEGIN is used for the "boot to Flash" bootloader mode */
    BEGIN : origin = 0x080000, length = 0x000002
    BOOT_RSVD : origin = 0x000002, length = 0x0001AF /* Part of M0, BOOT rom will use this for stack */
    RAMM0 : origin = 0x0001B1, length = 0x00024F
    RAMM1 : origin = 0x000400, length = 0x0003F8 /* on-chip RAM block M1 */
    // RAMM1_RSVD : origin = 0x0007F8, length = 0x000008 /* Reserve and do not use for code as per the errata advisory "Memory: Prefetching Beyond Valid Memory" */
    RAMD0 : origin = 0x00C000, length = 0x000800
    RAMD1 : origin = 0x00C800, length = 0x000800
    RAMLS03 : origin = 0x008000, length = 0x002000
    RAMLS4 : origin = 0x00A000, length = 0x000800
    RAMLS5 : origin = 0x00A800, length = 0x000800
    RAMLS6 : origin = 0x00B000, length = 0x000800
    RAMLS7 : origin = 0x00B800, length = 0x000800
    RAMGS0 : origin = 0x00D000, length = 0x001000
    RAMGS1 : origin = 0x00E000, length = 0x001000
    RAMGS2 : origin = 0x00F000, length = 0x001000
    RAMGS3 : origin = 0x010000, length = 0x001000
    RAMGS4 : origin = 0x011000, length = 0x001000
    RAMGS5 : origin = 0x012000, length = 0x001000
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    asm file:

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    ......... ...
    00085d7d: 761F02C4 MOVW DP, #0x2c4
    00085d7f: E2030008 MOV32 @0x8, R0H
    00085d81: 761F02C3 MOVW DP, #0x2c3
    00085d83: 0E24 MOVU ACC, @0x24
    00085d84: BDA90F12 MOV32 R0H, @ACC
    00085d86: E8020049 MOVIZ R1, #0x4009
    00085d88: E808F5C1 MOVXI R1H, #0x1eb8
    00085d8a: 761F02C5 MOVW DP, #0x2c5
    00085d8c: E9028F59 MOVIX R1L, #0x51eb
    00085d8e: E6870000 UI32TOF64 R0, R0H
    00085d90: E90C28F9 MOVXI R1L, #0x851f
    00085d92: E7800040 MPYF64 R0, R0, R1
    00085d94: E285010A UI32TOF64 R1, @0xa
    00085d96: 7700 NOP
    00085d97: E7800008 MPYF64 R0, R1, R0
    00085d99: E801FA81 MOVIZ R1, #0x3f50
    00085d9b: E80B1269 MOVXI R1H, #0x624d
    00085d9d: E9069789 MOVIX R1L, #0xd2f1
    00085d9f: E90D4FE1 MOVXI R1L, #0xa9fc
    00085da1: E7800008 MPYF64 R0, R1, R0
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    After previous discussion we have changes done ,but it remains error same

    Thanks&Regards

    Ajay S

  • Ajay,

    1) A sector can not be erased for more than 20K cycles.  Your erase requirement seems to be very high.  Since you are programming only 24 bytes each time, instead of erasing the sector after each program operation, you might want to program the next 24 bytes and access the latest data from the latest programmed address; and erase the sector only when the entire sector is used up.  This way, you can reduce the erase cycles drastically and comply to be with in the 20K cycling specification.  

    2) Did you try to do a step execution to see which instruction caused the ITRAP error?  Since you said that the issue occurs when executing the erase code, you can check whether or not the erase code is intact in RAM.

    Thanks and regards,

    Vamsi

  • Dear TI team,

              1.As per reply, We understand that have to write 24byte data in sector6 and once the same data is updated then erase sector6 ,write the updated data in sector7 but we think it is also not reliable for our application.

             2.We have not using software trap,when try to do the step execution  error occurs with EEPROM ERASE function as discussed earlier.kindly help us to check how illegal ITRAP error occurs and resolve this issue.(we have no idea with it kindly guide us)

    Thanks & Regards,

    Ajay.s

  • Hi Ajay,

    Are you available for a debug call early next week?

    If yes, what are your convenient times/days?  You can contact me on private chat like your colleagues did in the past.

    Thanks and regards,

    Vamsi

  • Hi vamsi,

                yes,we are looking foward for debug call .we can connect on monday at your convenience time.

    Thanks & Regards,

    Ajay.S

  • Hi Ajay,

    Please check my private message to you and continue chatting there.

    Thanks and regards,

    Vamsi

  • Hi Ajay,

    I am not available tomorrow (Friday March 18th).  

    Hence, I need to move the meeting to early next week.  Sorry about this.  

    Please check my private message and respond there (I am leaving this message here as well, so that you will check this and not wait for me).  

    Thanks and regards,
    Vamsi

  • Thanks for your valuable time and support and  our issue resolved ,closing our query..

  • Ajay,

    Glad I am able to help and prove that it is not a CPU-hang issue.

    Please stay with in the spec limit using the code suggestions that I provided to avoid flash-erase failure.

    I am closing this post.

    Thanks and regards,
    Vamsi