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.

TMS320F280034: TMS320F280034 Booting from flash in a standalone operation without a debugger

Part Number: TMS320F280034
Other Parts Discussed in Thread: UNIFLASH, C2000WARE, SYSCONFIG, , TMS320F280039C

Hello,

for some days I am struggling to make this F280034 run in standalone mode. I started off with the LAUNCHXL_F280039 board. The code runs there with no problem booting from flash. I tried to move to my custom board with F280034. I updated the liker file becuase in 0034 it starts from 0x88000 and in 0039 it starts from 0x80000:

/*
//###########################################################################
//
// FILE:	F280034_flash_lnk.cmd
//
// TITLE:	Linker Command File For F280034 Device
//
//###########################################################################
*/
MEMORY
{
 
   BOOT_RSVD		: origin = 0x00000002, length = 0x00000126

   RAMM0           	: origin = 0x00000128, length = 0x000002D8
   RAMM1            : origin = 0x00000400, length = 0x000003F8     /* on-chip RAM block M1 */
// RAMM1_RSVD       : origin = 0x000007F8, length = 0x00000008 /* Reserve and do not use for code as per the errata advisory "Memory: Prefetching Beyond Valid Memory" */


   RAMLS0           : origin = 0x00008000, length = 0x00000800
   RAMLS1           : origin = 0x00008800, length = 0x00000800
   RAMLS2           : origin = 0x00009000, length = 0x00000800
   RAMLS3           : origin = 0x00009800, length = 0x00000800
   RAMLS4           : origin = 0x0000A000, length = 0x00000800
   RAMLS5           : origin = 0x0000A800, length = 0x00000800
   RAMLS6           : origin = 0x0000B000, length = 0x00000800
   RAMLS7           : origin = 0x0000B800, length = 0x00000800

   /* Combining all the LS RAMs */
   //RAMLS            : origin = 0x00008000, length = 0x00004000
   
   RAMGS0           : origin = 0x0000C000, length = 0x00001000
   RAMGS1           : origin = 0x0000D000, length = 0x00001000
   RAMGS2           : origin = 0x0000E000, length = 0x00001000
   RAMGS3           : origin = 0x0000F000, length = 0x00000FF8
// RAMGS3_RSVD       : origin = 0x000FFF8, length = 0x00000008 /* Reserve and do not use for code as per the errata advisory "Memory: Prefetching Beyond Valid Memory" */

   BOOTROM          : origin = 0x003F8000, length = 0x00007FC0
   SECURE_ROM       : origin = 0x003F2000, length = 0x00006000

   RESET            : origin = 0x003FFFC0, length = 0x00000002
/*
#ifdef __TI_COMPILER_VERSION__
   #if __TI_COMPILER_VERSION__ >= 20012000
   #endif
#endif

 */
  BEGIN           	: origin = 0x00088000, length = 0x00000002
   /* Flash sectors */
   /* BANK 0 */
   FLASH_BANK0_SEC0  : origin = 0x088002, length = 0x000FFE
   FLASH_BANK0_SEC1  : origin = 0x089000, length = 0x001000
   FLASH_BANK0_SEC2  : origin = 0x08a000, length = 0x001000
   FLASH_BANK0_SEC3  : origin = 0x08b000, length = 0x001000
   FLASH_BANK0_SEC4  : origin = 0x08c000, length = 0x001000
   FLASH_BANK0_SEC5  : origin = 0x08d000, length = 0x001000
   FLASH_BANK0_SEC6  : origin = 0x08e000, length = 0x001000
   FLASH_BANK0_SEC7  : origin = 0x08f000, length = 0x000FF0
   FLASH_BANK0_SEC7_DO_NOT_USE : origin = 0x08FFF0, length = 0x000010  /* Reserve and do not use for code as per the errata advisory "Memory: Prefetching Beyond Valid Memory" */

   /* BANK 1 */
   FLASH_BANK1_SEC0  : origin = 0x090000, length = 0x001000
   FLASH_BANK1_SEC1  : origin = 0x091000, length = 0x001000
   FLASH_BANK1_SEC2  : origin = 0x092000, length = 0x001000
   FLASH_BANK1_SEC3  : origin = 0x093000, length = 0x001000
   FLASH_BANK1_SEC4  : origin = 0x094000, length = 0x001000
   FLASH_BANK1_SEC5  : origin = 0x095000, length = 0x001000
   FLASH_BANK1_SEC6  : origin = 0x096000, length = 0x001000
   FLASH_BANK1_SEC7  : origin = 0x097000, length = 0x000FF0
   FLASH_BANK1_SEC7_DO_NOT_USE : origin = 0x097FF0, length = 0x000010  /* Reserve and do not use for code as per the errata advisory "Memory: Prefetching Beyond Valid Memory" */
/*
#ifdef __TI_COMPILER_VERSION__
  #if __TI_COMPILER_VERSION__ >= 20012000
}  crc(_ccs_flash_checksum, algorithm=C28_CHECKSUM_16)
  #endif
#endif
*/
}


SECTIONS
{
   codestart        : > BEGIN, ALIGN(8)
   .text            : >> FLASH_BANK0_SEC2 | FLASH_BANK0_SEC3 | FLASH_BANK0_SEC4,   ALIGN(8)
   .cinit           : > FLASH_BANK0_SEC1,  ALIGN(8)
   .switch          : > FLASH_BANK0_SEC1,  ALIGN(8)
   .reset           : > RESET,                  TYPE = DSECT /* not used, */

   .stack           : > RAMM1

#if defined(__TI_EABI__)
   .init_array      : > FLASH_BANK0_SEC1,  ALIGN(8)
   .bss             : > RAMLS5
   .bss:output      : > RAMLS3
   .bss:cio         : > RAMLS0
   .data            : > RAMLS5
   .sysmem          : > RAMLS5
   .const           : > FLASH_BANK0_SEC4,  ALIGN(8)
#else
   .pinit           : > FLASH_BANK0_SEC1,  ALIGN(8)
   .ebss            : > RAMLS5
   .esysmem         : > RAMLS5
   .cio             : > RAMLS0
   .econst          : > FLASH_BANK0_SEC4,  ALIGN(8)
#endif

    ramgs0 : > RAMGS0
    ramgs1 : > RAMGS0

    /*  Allocate IQ math areas: */
   IQmath           : > FLASH_BANK0_SEC1, ALIGN(8)
   IQmathTables     : > FLASH_BANK0_SEC2, ALIGN(8)

   .TI.ramfunc      : LOAD = FLASH_BANK0_SEC1,
                      RUN = RAMLS0,
                      LOAD_START(RamfuncsLoadStart),
                      LOAD_SIZE(RamfuncsLoadSize),
                      LOAD_END(RamfuncsLoadEnd),
                      RUN_START(RamfuncsRunStart),
                      RUN_SIZE(RamfuncsRunSize),
                      RUN_END(RamfuncsRunEnd),
                      ALIGN(8)

   /* crc/checksum section configured as COPY section to avoid including in executable */
   .TI.memcrc          : type = COPY

}
/*
//###########################################################################
// End of file.
//###########################################################################
*/

What I did afterwards was to adjust the GEL file. The one provided with CCS was not adapted for the start address of 0x88000 and I could not flash with the X110 debugger. It was complaining that the address 0x80000 is not available or something similar. I replaced

    ...
    GEL_MapAddStr(0x00080000,0, 0x10000, "R|AS2",0);                     /*   FLASH BANK0 (128 KBytes)                                */
    ...
    GEL_MapAddStr(0x00080000,1, 0x10000, "R|AS2",0);                     /*   FLASH BANK0 (64 KBytes)                                */
    GEL_MapAddStr(0x00090000,1, 0x10000, "R|AS2",0);                     /*   FLASH BANK1 (64 KBytes)                                */
    GEL_MapAddStr(0x01080000,1, 0x2000, "R|AS2",0);                      /*   FLASH BANK0 ECC (16 KBytes)                             */
    GEL_MapAddStr(0x01082000,1, 0x2000, "R|AS2",0);                      /*   FLASH BANK0 ECC (16 KBytes)                             */
    ...

with this one:

    ...
    GEL_MapAddStr(0x00088000,0, 0x10000, "R|AS2",0);                     /*   FLASH BANK0 (128 KBytes)                                */
    ...
    GEL_MapAddStr(0x00088000,1, 0x8000, "R|AS2",0);                      /*   FLASH BANK0 (64 KBytes)                                */
    GEL_MapAddStr(0x00090000,1, 0x8000, "R|AS2",0);                      /*   FLASH BANK1 (64 KBytes)                                */
    GEL_MapAddStr(0x01081000,1, 0x1000, "R|AS2",0);                      /*   FLASH BANK0 ECC (16 KBytes)                             */
    GEL_MapAddStr(0x01082000,1, 0x1000, "R|AS2",0);                      /*   FLASH BANK0 ECC (16 KBytes)                             */
    ...
    

After flashing, the code runs properly with a debugger. In the "codestart" section I have

WD_DISABLE  .set  1    ;set to 1 to disable WD, else set to 0

so watchdog should be disabled immediately after reaching my code. But when I disconnect the debugger and do a HW reset, then the microcontroller starts resetting. Both of the pins GPIO24 and GPIO32 are set to HIGH and I do not expect a HW issue, the board is already verified and the HW works as expected (still I tried with 2 boards just to be sure that there was no HW problem somewhere). So the MCU should boot from flash. But on XRS pin I can see periodic pulses for around 50us every 20ms as seen in the image below. This seems like a watchdog reset, but I cannot be completely sure. This pin is "open drain" on the other side so the component on the other side should not have any impact on the behaviour of this MCU.

I tried since then many different things. I have ticked "auto ECC generation" in the debugger settings and I can see in the ECC memory some data. So the ECC seems to be there.Then I found that the BootROM will probably jump to the entry address in flash if it is configured that way (as it is in my case). But since the probably default option 0 is address 0x80000 (check image below), then I thought that I have to write in the OTP that I want the entry point to be 0x88000.

So I tried to write on address 0x78008 --> 0x5AFFFF20 so that it boots only dependent on GPIO32. And in 0x7800C --> 0x00000C23. First option is to boot from flash at address 0x88000, second is to flash from SPI.

I am not able to write to the OTP. I tried adding this in the code, but I could not make it compile properly with the FAPI code. Then I tried adding it to the linker file, but it does not get flashed. I can see the data at this address in the "out" file (actually checking it in the s19 file that is generated by hex2000), but if I flash with XDS110 this image and then check with the "memory browser" I see only 0xFF at this addresses. Then I tried the same thing with Uniflash, again it did not succeed. Then I tried both in CCS and Uniflash to manually write these registers as seen below.

the error I get from both CCS and Uniflash is:

[ERROR] C28xx_CPU1: Error during Flash programming (Flash algorithm returned error code 0x00000000, FMSTAT (STATCMD on some devices) 0x00000000). Operation cancelled.
[ERROR] C28xx_CPU1: Please make sure the memory location you are programming have not already been programmed.
[ERROR] C28xx_CPU1: Error encountered during security operation. Operation Cancelled.

Since this was the first custom board I thought that maybe OTP was written unintentionally before and is already locked (even if it has the value 0xFF in all these registers). Then I took another custom board from the same type and without flashing any SW, just reading the memory to be sure that it is new, then directly writing these OTP registers, it failed agian in the same way.

I am running out of ideas. Does anybody have ideas what the problem could be? Do I need at all to flash the OTP of 0034 so that it jumps to 0x88000 or is this the default entry point on this MCU? Why do I see this reset on the XRS pin? What could this be? My assumption is that my code is not executed at all, it gets reset before reaching it.

thank you

 
  • Hi Peter,

    Thanks for the detailed and clear explanation of the steps you have tried. You seem to have followed the right steps.

    To write to OTP you can direct initialized global variables pointing to 0x78008 and 7800C. and then load the program via CCS. The flash plugin in CCS will take care to program the OTP values. After loading you need not run the program, just loading will do.

    Alternatively you can make use of the exmaple project at C2000ware \c2000\C2000Ware_4_03_00_00\driverlib\f28003x\examples\dcsm

    Open the sysconfig tool and make necessary changes to OTP value, compile and load the program.

    Regards

    Baskaran

  • Hi Baskaran,

    thank you for your reply. I also tried the dcsm project, configured everything as described above, but I get exactly the same problem:

    C28xx_CPU1: GEL Output: 
    
    RAM initialization done
    
    C28xx_CPU1: GEL Output: 
    Memory Map Initialization Complete
    C28xx_CPU1: GEL Output: ... DCSM Initialization Start ... 
    C28xx_CPU1: GEL Output: ... DCSM Initialization Done ...
    C28xx_CPU1: GEL Output: ... DCSM Initialization Start ... 
    C28xx_CPU1: GEL Output: ... DCSM Initialization Done ...
    C28xx_CPU1: GEL Output: ... DCSM Initialization Start ... 
    C28xx_CPU1: GEL Output: ... DCSM Initialization Done ...
    C28xx_CPU1: Error during Flash programming (Flash algorithm returned error code 0x00000000, FMSTAT (STATCMD on some devices) 0x00000000). Operation cancelled.
    C28xx_CPU1: File Loader: Memory write failed: Unknown error
    C28xx_CPU1: GEL: File: C:\temp\dcsm_security_tool\CPU1_FLASH\dcsm_security_tool.out: Load failed.
    C28xx_CPU1: Error during Flash programming (Flash algorithm returned error code 0x00000000, FMSTAT (STATCMD on some devices) 0x00000000). Operation cancelled.
    C28xx_CPU1: Please make sure the memory location you are programming have not already been programmed.

    I am also attaching the complete project below.

    5381.dcsm_security_tool.zip

    do you know what this problem means? I think the CSS flash plugin does not succeed flashing this image and writing to the OTP on the F280034 MCU.Have you been able to flash in the OTP on this type of MCU?

    best regards,

    joao peter

  • Yes, i have tired earlier and was able to program. 

    I will loop in our flash expert to see if there is any issue with programming the OTP.

  • Hi Peter,

    We will review and get back to you by the end of week.

    Thanks and regards,

    Vamsi

  • I think i have the same problem. We have custom boards with the TMS320f280034 (48pin) and controlcards with docing station having the TMS320f280039C (100 pin). 
    If we want to program the custom boards we get the same error as above. It happens for Z1 and Z2 OTP

    C28xx_CPU1: Error during Flash programming (Flash algorithm returned error code 0x00000000, FMSTAT (STATCMD on some devices) 0x00000000). Operation cancelled.

    The TMS320f280039C can be programmed correctly. We also tried to flash the TMS320f280039C a second time and the shown error does not match the error of the TMS320f280034. 

    C28xx_CPU1: Error during Flash Programming. Address 0x00078008, FMSTAT (STATCMD on some devices) 0x00000030

    The OTPs we want to write are 

    Z1OTP 1 0x5AFFFFFF

    Z1OTP 2 0x5AFFFFEF

    Z1OTP 3 0xFFFFFF23

  • Hi Peter,

    Regarding your statement "I tried adding this in the code, but I could not make it compile properly with the FAPI code. Then I tried adding it to the linker file, but it does not get flashed.":

    1) What compile error did you get when you tried to program the fields using the flash API?  

    2) What do you mean by adding it to the linker file?  Please provide more details.

    3) Does your map file show that some data is mapped to the intended OTP locations?

    Thanks and regards,

    Vamsi

  • Hi KMay,

    Please open a new post for your query.

    Thanks and regards,

    Vamsi

  • Hi Vamsi,

    thank you for your reply. Regarding your questions:

    1) I did not spend much time trying to make a project with the flash API to run (so I do not remember what the problem was), becuase the other two options already failed - using CCS/uniflash (as shown in my first post) and also by placing variables on these positions with the specified values (via linker file). For this second option I have uploaded in my previous post the complete project together with the map file and out file as reference. In case you think there is a chance that through flash API it could work, I could try to make it work. I will adapt the example project "flashapi_ex1_programming" tomorrow and I will write back

    2) I meant that I added a global varaible that is positioned through the linker file at position 0x78006 with the value 0x5AFFFF20 as it is done in attached project from my previous post:

    in the .asm file:

    ...
         .sect "dcsm_otp_z1_gpreg"
          .retain
          .long 0x5AFFFF20     ;Z1OTP_GPREG1 = Z1_BOOTPIN
          .long 0x5AFFFFff     ;Z1OTP_GPREG2
          .long 0xFFFF0623     ;Z1OTP_GPREG3 = Z1OTP_BOOTDEF_LOW
          .long 0xFFFFFFFF     ;Z1OTP_GPREG4 = Z1OTP_BOOTDEF_HIGH
    ...

    and in the linker file:

    MEMORY {
    ...
          DCSM_OTP_Z1_GPREG     : origin = 0x78008, length = 0x00008
    ...
    SECTIONS {
    ...
       dcsm_otp_z1_gpreg        : > DCSM_OTP_Z1_GPREG		    PAGE = 0
    ...
        

    3) yes, the map file shows that this space is used:

            name            origin    length      used     unused   attr    fill
    ----------------------  --------  ---------  --------  --------  ----  --------
    ...
      DCSM_OTP_Z1_LINKPOINT 00078000   00000006  00000000  00000006  RWIX
      DCSM_OTP_Z1_JLM_ENABL 00078006   00000002  00000002  00000000  RWIX
      DCSM_OTP_Z1_GPREG     00078008   00000008  00000008  00000000  RWIX
      DCSM_OTP_Z1_PSWDLOCK  00078010   00000002  00000002  00000000  RWIX
    ...

    So it seems that these values and properly set in the map file and should be flashed by the XDS110 on these exact addresses in OTP, but the flashing process fails.

    Would you mind answering these questions:

    1) is it needed at all for the F280034 to write in OTP in order to be able to boot from the first position in flash? As I wrote in my first post, this MCU and the F280033 do not start from 0x80000, but from 0x88000. But the data sheet specifies that they should be able to boot from flsah and I would expect that the BOOTROM should jump to 0x88000 for these MCUs, not 0x80000. But I cannot find any proof in the data sheet or in the reference manual. If this is the case, then I do not need to write in the OTP at all, right? But the MCU does not boot without a debugger unfortunately so I assume it does not boot from 0x88000

    2) what does this error message mean when flashing?

    [ERROR] C28xx_CPU1: Error during Flash programming (Flash algorithm returned error code 0x00000000, FMSTAT (STATCMD on some devices) 0x00000000). Operation cancelled.

    3) Does the watchdog generate the pulses that I get on the XRS pin? Does this mean that the Bootrom does not jump properly to my code since the first thing I do in my code is to disable the watchdog?

    I checked in the reference manual that if FMSTAT is 0, then it does not mark any error, right?

    thank you.

    best regards,

    joao peter

  • Hello,

    an example of an compiler error (actually a liker error) I encountered is that when using the linker file from CCS for the 280034 and during compilation I get the following error:

    "../28003x_generic_flash_lnk.cmd", line 45: error #10468-D: The memrange group 'MEMORY_GROUP_1' contains a gap. 'FLASH_BANK0_SEC7_DO_NOT_USE' ends at address 0x88000 and 'FLASH_BANK1_SEC0' starts at address 0x90000. Group cannot contain gaps.
    error #10010: errors encountered during linking;

    the linker is the one from CCS and is attached only for reference (agian the flash sectors do not match the data sheet, but the current issue is regarding the GAP, after that if I remove this CRC generation, the debugger gives me an error that 0x80000 is not a valid flash space):

    /*
    //###########################################################################
    //
    // FILE:	F280034_flash_lnk.cmd
    //
    // TITLE:	Linker Command File For F280034 Device
    //
    //###########################################################################
    */
    MEMORY
    {
    
       BOOT_RSVD		: origin = 0x00000002, length = 0x00000126
    
       RAMM0           	: origin = 0x00000128, length = 0x000002D8
       RAMM1            : origin = 0x00000400, length = 0x000003F8     /* on-chip RAM block M1 */
    // RAMM1_RSVD       : origin = 0x000007F8, length = 0x00000008 /* Reserve and do not use for code as per the errata advisory "Memory: Prefetching Beyond Valid Memory" */
    
    
       RAMLS0           : origin = 0x00008000, length = 0x00000800
       RAMLS1           : origin = 0x00008800, length = 0x00000800
       RAMLS2           : origin = 0x00009000, length = 0x00000800
       RAMLS3           : origin = 0x00009800, length = 0x00000800
       RAMLS4           : origin = 0x0000A000, length = 0x00000800
       RAMLS5           : origin = 0x0000A800, length = 0x00000800
       RAMLS6           : origin = 0x0000B000, length = 0x00000800
       RAMLS7           : origin = 0x0000B800, length = 0x00000800
    
       /* Combining all the LS RAMs */
       //RAMLS            : origin = 0x00008000, length = 0x00004000
    
       RAMGS0           : origin = 0x0000C000, length = 0x00001000
       RAMGS1           : origin = 0x0000D000, length = 0x00001000
       RAMGS2           : origin = 0x0000E000, length = 0x00001000
       RAMGS3           : origin = 0x0000F000, length = 0x00000FF8
    // RAMGS3_RSVD       : origin = 0x000FFF8, length = 0x00000008 /* Reserve and do not use for code as per the errata advisory "Memory: Prefetching Beyond Valid Memory" */
    
       BOOTROM          : origin = 0x003F8000, length = 0x00007FC0
       SECURE_ROM       : origin = 0x003F2000, length = 0x00006000
    
       RESET            : origin = 0x003FFFC0, length = 0x00000002
    
    #ifdef __TI_COMPILER_VERSION__
       #if __TI_COMPILER_VERSION__ >= 20012000
    GROUP {      /* GROUP memory ranges for crc/checksum of entire flash */
       #endif
    #endif
       BEGIN           	: origin = 0x00080000, length = 0x00000002
       /* Flash sectors */
       /* BANK 0 */
       FLASH_BANK0_SEC0  : origin = 0x080002, length = 0x000FFE
       FLASH_BANK0_SEC1  : origin = 0x081000, length = 0x001000
       FLASH_BANK0_SEC2  : origin = 0x082000, length = 0x001000
       FLASH_BANK0_SEC3  : origin = 0x083000, length = 0x001000
       FLASH_BANK0_SEC4  : origin = 0x084000, length = 0x001000
       FLASH_BANK0_SEC5  : origin = 0x085000, length = 0x001000
       FLASH_BANK0_SEC6  : origin = 0x086000, length = 0x001000
       FLASH_BANK0_SEC7  : origin = 0x087000, length = 0x000FF0
       FLASH_BANK0_SEC7_DO_NOT_USE : origin = 0x087FF0, length = 0x000010  /* Reserve and do not use for code as per the errata advisory "Memory: Prefetching Beyond Valid Memory" */
    
       /* BANK 1 */
       FLASH_BANK1_SEC0  : origin = 0x090000, length = 0x001000
       FLASH_BANK1_SEC1  : origin = 0x091000, length = 0x001000
       FLASH_BANK1_SEC2  : origin = 0x092000, length = 0x001000
       FLASH_BANK1_SEC3  : origin = 0x093000, length = 0x001000
       FLASH_BANK1_SEC4  : origin = 0x094000, length = 0x001000
       FLASH_BANK1_SEC5  : origin = 0x095000, length = 0x001000
       FLASH_BANK1_SEC6  : origin = 0x096000, length = 0x001000
       FLASH_BANK1_SEC7  : origin = 0x097000, length = 0x000FF0
       FLASH_BANK1_SEC7_DO_NOT_USE : origin = 0x097FF0, length = 0x000010  /* Reserve and do not use for code as per the errata advisory "Memory: Prefetching Beyond Valid Memory" */
    
    #ifdef __TI_COMPILER_VERSION__
      #if __TI_COMPILER_VERSION__ >= 20012000
    }  crc(_ccs_flash_checksum, algorithm=C28_CHECKSUM_16)
      #endif
    #endif
    
    }
    
    
    SECTIONS
    {
       codestart        : > BEGIN, ALIGN(8)
       .text            : >> FLASH_BANK0_SEC2 | FLASH_BANK0_SEC3 | FLASH_BANK0_SEC4,   ALIGN(8)
       .cinit           : > FLASH_BANK0_SEC1,  ALIGN(8)
       .switch          : > FLASH_BANK0_SEC1,  ALIGN(8)
       .reset           : > RESET,                  TYPE = DSECT /* not used, */
    
       .stack           : > RAMM1
    
    #if defined(__TI_EABI__)
       .init_array      : > FLASH_BANK0_SEC1,  ALIGN(8)
       .bss             : > RAMLS5
       .bss:output      : > RAMLS3
       .bss:cio         : > RAMLS0
       .data            : > RAMLS5
       .sysmem          : > RAMLS5
       .const           : > FLASH_BANK0_SEC4,  ALIGN(8)
    #else
       .pinit           : > FLASH_BANK0_SEC1,  ALIGN(8)
       .ebss            : > RAMLS5
       .esysmem         : > RAMLS5
       .cio             : > RAMLS0
       .econst          : > FLASH_BANK0_SEC4,  ALIGN(8)
    #endif
    
        ramgs0 : > RAMGS0
        ramgs1 : > RAMGS0
    
        /*  Allocate IQ math areas: */
       IQmath           : > FLASH_BANK0_SEC1, ALIGN(8)
       IQmathTables     : > FLASH_BANK0_SEC2, ALIGN(8)
    
       .TI.ramfunc      : LOAD = FLASH_BANK0_SEC1,
                          RUN = RAMLS0,
                          LOAD_START(RamfuncsLoadStart),
                          LOAD_SIZE(RamfuncsLoadSize),
                          LOAD_END(RamfuncsLoadEnd),
                          RUN_START(RamfuncsRunStart),
                          RUN_SIZE(RamfuncsRunSize),
                          RUN_END(RamfuncsRunEnd),
                          ALIGN(8)
    
       /* crc/checksum section configured as COPY section to avoid including in executable */
       .TI.memcrc          : type = COPY
    
    }
    /*
    //###########################################################################
    // End of file.
    //###########################################################################
    */
    

    this was an info just because you asked. If I remove the CRC generation, adjust the flash spaces, then I get the error from my first post when trying to flash with the debugger:

    [ERROR] C28xx_CPU1: Error during Flash programming (Flash algorithm returned error code 0x00000000, FMSTAT (STATCMD on some devices) 0x00000000). Operation cancelled.
    [ERROR] C28xx_CPU1: Please make sure the memory location you are programming have not already been programmed.
    [ERROR] C28xx_CPU1: Error encountered during security operation. Operation Cancelled.

    best regards,

  • Hi Peter,

    Thank you for the info.  I will review this once I am back to office next week and get back to you.

    Best regards,
    Vamsi

  • Hello Vamsi,

    thank you, I will wait for your reply. As promised in my post above, I checked now also what happens when using Flash API. I took the example project called "flashapi_ex1_programming", I adjusted the linker, gel file etc. and updated the main function to contain besides the initialization following code:

    #define FLASH0CTRL_BASE           0x0005F800U
    #define FLASH0ECC_BASE            0x0005FB00U
    #define DCSM_Z1OTP_BASE           0x00078000U
    
    Flash_initModule(FLASH0CTRL_BASE, FLASH0ECC_BASE, 5);
    
    Fapi_initializeAPI(FLASH0CTRL_BASE, DEVICE_SYSCLK_FREQ/1000000U);
    Fapi_setActiveFlashBank(Fapi_FlashBank0);		//Fapi_ = 0 in the enum in Types.h
    
    Buffer[0] = 0x5AFF;
    Buffer[1] = 0xFF20;
    Buffer[2] = 0x5AFF;
    Buffer[3] = 0xFFFF;
    Buffer[4] = 0xFFFF;
    Buffer[5] = 0x0623;
    Buffer[6] = 0xFFFF;
    Buffer[7] = 0xFFFF;
    
    Fapi_issueProgrammingCommand((uint32 *)DCSM_Z1OTP_BASE + 8,Buffer, 8, 0, 0, Fapi_AutoEccGeneration);

    This code is executed from RAM as in the example so that there are no conflicts with the flash space (probably this is necessary only for flash spaces, not OTP, but it does not hurt).

    Now the error being returned by the last function in this code is "invalid address". Maybe I am not setting something properly, but I am not sure what addresses I shluld provide in "Fapi_initializeAPI", probably you do not count the OTP as part of the flash memory (which is what I would expect). But the enum contians only bank0, bank1 and bank2, no OTP options available. Then what address should I provide in "Fapi_setActiveFlashBank", maybe I should remove this funciton.

    Unfortunately with flash API it did not work for now, but I would also want to focus on the problems when using the debugger, not the flash API.

    thank you.

    best regards,

    joao peter

  • Hi Peter,

    Ok, will consider this while reviewing your updates.

    Thanks and regards,

    Vamsi

  • Hi Vamsi,

    do you have any update on this topic?

    thank you

  • Hi Peter,

    I will be reviewing this today.  

    Thanks and regards,

    Vamsi

  • Hi Joao Peter,

    Thank you for the information that you provided.

    1) Based on your interaction with Baskaran (Boot expert), he confirmed that you do need to program the OTP in order for the application to boot from 0x88000.

    2) Error is saying that the program command is not issued - If issued, it would give a failure status of FMSTAT that is not zero.  Program command is not issued for reasons like invalid address etc.

    3) It can be watchdog since your application is not booting due to the OTP program failure.

    Please note: Our team is trying to get some F280034 devices to try this.

    Thanks and regards,

    Vamsi

  • Hi Joao Peter,

    Thank you for experimenting with the flash API and providing the results you obtained.  

    Let me review and get back to you.

    You confirmed that you are able to program the same OTP locations in F280039 but not in F280034 - correct?

    Thanks and regards,
    Vamsi

  • Hi Vamsi,

    thank you.

    1) I cannot find where  Baskaran confirms that by default the F280034 will boot by default to 0x80000 and that I need to write in the OTP so that the SW can start. Because then the documentation is wrong. It says that the bootrom will just to flash, the flash starts at 0x88000 so the bootrom will not just to flash if it jumps to 0x80000 by default. In anycase, could you please double check and confirm if it is correct that it jumps in F280034 to 0x80000 and it is mandarory to write to the OTP so that it can boot from flash? It is important for me know that this is the case. Please, check again and maybe updating the errata would be great.

    3) ok, since there is another thread from KMay with exactly the same issue, I hope you will find some pieces of F280034 soon. Would it take 1-2 days or more like weeks?

    EDIT: It is interesting that Baskaran confirmed that he was able to flash in the OTP of F280034, check his post above. This is strange, either he did not understand my question, or he really succeeded. Maybe you can get in contact with him, he should already have F280034 that you could borrow for the tests

    thank you.

    Best regards

  • I have not tried to flash in F280039 since it works fine and boots properly. And since we have currently only 1 pcs of it, I would like to not try it for now. I could try after you to some trials with F280034 if we are stuck with this problem. But there is no reason that OTP does not work, since your colleagues have already confirmed that it works on F280039 and KMay also confirmed that in the other threadt

    best regards,

  • Hi Joao Peter,

    Baskaran said that you did the right steps - However, I already messaged him to confirm whether you need to program the OTP or not.  If this needs an update in the BootROM chapter, he will take care of it.  

    Yes, I agree that you should not waste your device.  Our team is trying to get the samples - should be able to get in couple of days (not weeks).

    Thanks and regards,
    Vamsi

  • Hi Vamsi,

    thank you for your fast reply, I will wait for your updates on the OTP issue and the confirmation of the jump address from Bootrom in flash.

    best regards,

  • Hi Joao,

    Regarding your flash API usage question: Fapi_FlashBank0 is good enough for Bank 0's OTP.

    Sure, we will get back to you in couple of days.

    Thanks and regards,
    Vamsi

  • Hi Joao,

    Could you please attach a snapshot of the F280034 device that you are using?

    Thanks and regards,
    Vamsi

  • Hi Vamsi,

    what do you mean with snapshot? a photo of the physical componnet? or a snapshot of the memory? or something else?

    best regards

  • Hi Joao,

    Please send a photo of the physical component.

    Thanks and regards,
    Vamsi

  • Hi Joao,

    I think I found the issue.  I will provide you the new tool file that you can use to avoid this issue.  Please expect an update in a day or two.

    Thanks and regards,

    Vamsi

  • Please go ahead and send a snapshot of the device just in case.

    Thanks and regards,
    Vamsi

  • Hi Vamsi,

    this sounds great, thank you. I can't wait to get this issue solved :).

    EDIT: I will send you a snapshot tomorrow morning, becuase it is almost midnight here.

    best regards,

    joao peter

  • Hi Joao,

    Sure, tomorrow is fine.

    Please send me a friend request when you are back tomorrow so that I can send you the file offline to try.

    Thanks and regards,
    Vamsi

  • Hi Joao Peter,

    I sent you the solution offline.

    Please let me know how it goes.

    Thanks and regards,
    Vamsi

  • Hi Joao Peter,

    I saw your reply on the other post that the provided solution worked for you.  

    Thank you for the confirmation.

    We will align with CCS/Uniflash team to release this update in the next revisions.

    Can I close this post now?  

    Best regards,
    Vamsi

  • Hi Vamsi,

    this is the image of hte component as promised.

    Yes, the issue is solved. Just to have it written for others that could face this issue, I tried only with variables that are positioned in this specified addressed by the linker file, i.e. they are present in the map file and of course in the out file and then I flash the out file with the debugger via CCS and the OTP memory is updated. I wanted to try also through CCS, and than I was about to write back here, but since you wrote now, I can confirm that this update fixes the issue. Thank you for your support. Please, close this topic.

    best regards

  • Hi Joao Peter,

    Many thanks for bringing this issue to our attention.  

    Have a great day.

    Best regards,
    Vamsi