• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Subscribers 82 subscribers
  • Views 898 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

TMS320F280049: Flash Programming Unknown Error

Trey German8
Expert 1950 points
Part Number: TMS320F280049
Other Parts Discussed in Thread: C2000WARE

Vamsi,

Hope you had some relaxing time off over the holiday :)

I'm getting a strange error from the flashAPI:

C28xx_CPU1: Error during Flash Verification. Address 0x000920EC, Expected 0x0000FFFF, Read 0x0000B2BD
C28xx_CPU1: File Loader: Memory write failed: Unknown error
C28xx_CPU1: GEL: File: /Users/germanpm/Polymorphic_Labs_LLC/Sygnal/Firmware/MCM/Sygnal-MCM/CPU1_FLASH/Sygnal-MCM.out: Load failed.
C28xx_CPU1: Error during Flash Verification. Address 0x00082004, Expected 0x0000FFFF, Read 0x00000049
C28xx_CPU1: Please make sure the memory location you are programming have not already been programmed.
C28xx_CPU1: Error during Flash Verification. Address 0x00082141, Expected 0x0000FFFF, Read 0x00000006
C28xx_CPU1: Please make sure the memory location you are programming have not already been programmed.
C28xx_CPU1: Error during Flash Verification. Address 0x00082154, Expected 0x0000FFFF, Read 0x00003FEF
C28xx_CPU1: Please make sure the memory location you are programming have not already been programmed.
C28xx_CPU1: Error during Flash Verification. Address 0x000920E8, Expected 0x0000FFFF, Read 0x00000000
C28xx_CPU1: Please make sure the memory location you are programming have not already been programmed.

Looking in memory at the locations it's complaining about, all of them are 0xFFFF contrary to what the error message states.  For instance:

I've tried this on my custom board as well as the LP, the behavior is the same.  I am able to program a different application just fine so it appears the problem is localized to a single linker command file.

The linker file is based on the 49 flash command file shipped in C2000ware, but I've modified it to add CRC tables, and some additional sections.  Any idea what could be going on?  I can share the out file over email if you want.

Fullscreen 28004x_sygnal_mcm_flash_lnk.txt Download 
MEMORY
{
PAGE 0 :
   /* BEGIN is used for the "boot to Flash" bootloader mode   */

   BEGIN           	: origin = 0x082004, length = 0x000002
   CRC_PTR			: origin = 0x082006, length = 0x000002
   RAMM0           	: origin = 0x0000F4, length = 0x00030C

   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
   RESET           	: origin = 0x3FFFC0, length = 0x000002

   /* Flash sectors */
   /* BANK 0 */
   //FLASH_BANK0_SEC0  : origin = 0x080002, length = 0x000FFE	/* on-chip Flash */
   //FLASH_BANK0_SEC1  : origin = 0x081000, length = 0x001000	/* on-chip Flash */
   FLASH_BANK0_SEC2  : origin = 0x082008, length = 0x000FF8	/* on-chip Flash */
   FLASH_BANK0_SEC3  : origin = 0x083000, length = 0x001000	/* on-chip Flash */
   FLASH_BANK0_SEC4  : origin = 0x084000, length = 0x001000	/* on-chip Flash */
   FLASH_BANK0_SEC5  : origin = 0x085000, length = 0x001000	/* on-chip Flash */
   FLASH_BANK0_SEC6  : origin = 0x086000, length = 0x001000	/* on-chip Flash */
   FLASH_BANK0_SEC7  : origin = 0x087000, length = 0x001000	/* on-chip Flash */
   FLASH_BANK0_SEC8  : origin = 0x088000, length = 0x001000	/* on-chip Flash */
   FLASH_BANK0_SEC9  : origin = 0x089000, length = 0x001000	/* on-chip Flash */
   FLASH_BANK0_SEC10 : origin = 0x08A000, length = 0x001000	/* on-chip Flash */
   FLASH_BANK0_SEC11 : origin = 0x08B000, length = 0x001000	/* on-chip Flash */
   FLASH_BANK0_SEC12 : origin = 0x08C000, length = 0x001000	/* on-chip Flash */
   FLASH_BANK0_SEC13 : origin = 0x08D000, length = 0x001000	/* on-chip Flash */
   FLASH_BANK0_SEC14 : origin = 0x08E000, length = 0x001000	/* on-chip Flash */
   FLASH_BANK0_SEC15 : origin = 0x08F000, length = 0x001000	/* on-chip Flash */

   /* BANK 1 */
   FLASH_BANK1_SEC0  : origin = 0x090000, length = 0x001000	/* on-chip Flash */
   FLASH_BANK1_SEC1  : origin = 0x091000, length = 0x001000	/* on-chip Flash */
   FLASH_BANK1_SEC2  : origin = 0x092000, length = 0x001000	/* on-chip Flash */
   FLASH_BANK1_SEC3  : origin = 0x093000, length = 0x001000	/* on-chip Flash */
   FLASH_BANK1_SEC4  : origin = 0x094000, length = 0x001000	/* on-chip Flash */
   FLASH_BANK1_SEC5  : origin = 0x095000, length = 0x001000	/* on-chip Flash */
   FLASH_BANK1_SEC6  : origin = 0x096000, length = 0x001000	/* on-chip Flash */
   FLASH_BANK1_SEC7  : origin = 0x097000, length = 0x001000	/* on-chip Flash */
   FLASH_BANK1_SEC8  : origin = 0x098000, length = 0x001000	/* on-chip Flash */
   FLASH_BANK1_SEC9  : origin = 0x099000, length = 0x001000	/* on-chip Flash */
   FLASH_BANK1_SEC10 : origin = 0x09A000, length = 0x001000	/* on-chip Flash */
   FLASH_BANK1_SEC11 : origin = 0x09B000, length = 0x001000	/* on-chip Flash */
   FLASH_BANK1_SEC12 : origin = 0x09C000, length = 0x001000	/* on-chip Flash */
   FLASH_BANK1_SEC13 : origin = 0x09D000, length = 0x001000	/* on-chip Flash */
   FLASH_BANK1_SEC14 : origin = 0x09E000, length = 0x001000	/* on-chip Flash */
   FLASH_BANK1_SEC15 : origin = 0x09F000, length = 0x000FF0	/* on-chip Flash */

//   FLASH_BANK1_SEC15_RSVD : origin = 0x09FFF0, length = 0x000010  /* Reserve and do not use for code as per the errata advisory "Memory: Prefetching Beyond Valid Memory" */

PAGE 1 :

   BOOT_RSVD       : origin = 0x000002, length = 0x0000F1     /* Part of M0, BOOT rom will use this for stack */
   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" */

   RAMLS5      : origin = 0x00A800, length = 0x000800
   RAMLS6      : origin = 0x00B000, length = 0x000800
   RAMLS7      : origin = 0x00B800, length = 0x000800

   RAMGS0      : origin = 0x00C000, length = 0x002000
   RAMGS1      : origin = 0x00E000, length = 0x002000
   RAMGS2      : origin = 0x010000, length = 0x002000
   RAMGS3      : origin = 0x012000, length = 0x001FF8
//   RAMGS3_RSVD : origin = 0x013FF8, length = 0x000008     /* Reserve and do not use for code as per the errata advisory "Memory: Prefetching Beyond Valid Memory" */
}


SECTIONS
{
   codestart        : > BEGIN,     PAGE = 0, ALIGN(4)//, crc_table(_crcTable, algorithm = CRC32_PRIME)
   .TI.crctab		: > FLASH_BANK0_SEC2, 	PAGE = 0, ALIGN(4)
   .text            : >> FLASH_BANK1_SEC2 | FLASH_BANK1_SEC3 | FLASH_BANK1_SEC4 |FLASH_BANK1_SEC5 | FLASH_BANK1_SEC6 | FLASH_BANK1_SEC7 | FLASH_BANK1_SEC8 | FLASH_BANK1_SEC9 | FLASH_BANK1_SEC10 | FLASH_BANK1_SEC11 | FLASH_BANK1_SEC12 | FLASH_BANK1_SEC13 | FLASH_BANK1_SEC14 | FLASH_BANK1_SEC15,   PAGE = 0, ALIGN(4)//, crc_table(_crcTable, algorithm = CRC32_PRIME)
   .cinit           : > FLASH_BANK1_SEC2,     PAGE = 0, ALIGN(4)//, crc_table(_crcTable, algorithm = CRC32_PRIME)
   .switch          : > FLASH_BANK1_SEC2,     PAGE = 0, ALIGN(4)//, crc_table(_crcTable, algorithm = CRC32_PRIME)
   .reset           : > RESET,     PAGE = 0, TYPE = DSECT /* not used, */

   .stack           : > RAMM1,     PAGE = 1

#if defined(__TI_EABI__)
   .init_array      : > FLASH_BANK1_SEC2,       PAGE = 0,       ALIGN(4)//, crc_table(_crcTable, algorithm = CRC32_PRIME)
   .bss             : >> RAMLS5 | RAMLS6 | RAMLS7,       PAGE = 1
   .bss:output      : > RAMLS3,       PAGE = 0
   .bss:cio         : > RAMLS0,       PAGE = 0
   .data            : > RAMLS5,       PAGE = 1
   .sysmem          : > RAMLS5,       PAGE = 1
   /* Initalized sections go in Flash */
   .const           : > FLASH_BANK0_SEC4,       PAGE = 0,       ALIGN(4)//, crc_table(_crcTable, algorithm = CRC32_PRIME)
#else
   .pinit           : > FLASH_BANK1_SEC2,       PAGE = 0//,       ALIGN(4), crc_table(_crcTable, algorithm = CRC32_PRIME)
   .ebss            : >> RAMLS5 | RAMLS6 | RAMLS7,       PAGE = 1
   .esysmem         : > RAMLS5 | RAMLS6 | RAMLS7 | RAMGS0 | RAMGS1 | RAMGS2 | RAMGS3,       PAGE = 1
   .cio             : > RAMLS0,       PAGE = 0
   .econst          : >> FLASH_BANK0_SEC4 | FLASH_BANK0_SEC5 | FLASH_BANK0_SEC6, PAGE = 0, ALIGN(4), crc_table(_crcTable, algorithm = CRC32_PRIME)
#endif

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

 
#if defined(__TI_EABI__) 
   .TI.ramfunc      : LOAD = FLASH_BANK0_SEC2,
                      RUN = RAMLS0,
                      LOAD_START(RamfuncsLoadStart),
                      LOAD_SIZE(RamfuncsLoadSize),
                      LOAD_END(RamfuncsLoadEnd),
                      RUN_START(RamfuncsRunStart),
                      RUN_SIZE(RamfuncsRunSize),
                      RUN_END(RamfuncsRunEnd),
                      PAGE = 0, ALIGN(4)//, crc_table(_crcTable, algorithm = CRC32_PRIME)
#else					  
   .TI.ramfunc      : LOAD = FLASH_BANK0_SEC2,
                      RUN = RAMLS0,
                      LOAD_START(_RamfuncsLoadStart),
                      LOAD_SIZE(_RamfuncsLoadSize),
                      LOAD_END(_RamfuncsLoadEnd),
                      RUN_START(_RamfuncsRunStart),
                      RUN_SIZE(_RamfuncsRunSize),
                      RUN_END(_RamfuncsRunEnd),
                      PAGE = 0, ALIGN(4)//, crc_table(_crcTable, algorithm = CRC32_PRIME)
#endif


   firfilt			: > RAMLS5,		PAGE = 1, ALIGN(4)
   firldb			: > RAMLS5,		PAGE = 1, ALIGN(4)
   crcTablePtr		: > CRC_PTR,	PAGE = 0

}

/*
//===========================================================================
// End of file.
//===========================================================================
*/

Thanks,

Trey

  • 0
    TI__Guru* 87155 points

    Trey,

    Good to hear from you. 

    In the Flash plugin GUI, under erase settings, do you have entire flash selected to be erased?  If not, please try that.  I am wondering if this is due to some ECC content not erased.  

    Thanks and regards,
    Vamsi

  • 0 in reply to Vamsi Gudivada
    Expert 1950 points

    Yes, it is setup to erase the entire flash.  I also tried making the BEGIN and CRC_PTR memories to be 4 words long so they would aligned on 64bit boundaries (in case it wasn't combining them when programming) and this has not improved behavior either.

    Trey

  • 0 in reply to Trey German8
    TI__Guru* 87155 points

    Trey,

    Got it. What is the CCS version that you are using? 

    If possible,

    1. Please use latest CCS (if not already) and see if that fixes it.

    2. Please send me the out file via the E2E friend request.

    Thanks and regards,
    Vamsi

  • 0 in reply to Vamsi Gudivada
    Expert 1950 points

    I'm on 10.1.0.00010 with all the latest emupack updates.

    Just sent you a friend request.

    Trey

  • 0 in reply to Trey German8
    TI__Guru* 87155 points

    Trey,

    Thank you. I will take a look at it some time today or early tomorrow and get back to you.

    Thanks and regards,
    Vamsi

  • 0 in reply to Vamsi Gudivada
    Expert 1950 points

    I'm still playing around with it.  It looks to be the text.1 section which is causing problems.  I've tried changing the memory that .text is placed in, including switching it over to bank 0 and the problem follows where I place it.  The first address it complains about is always populated with 

    rts2800_fpu32.lib : _printfi.c.obj (.text)

    I've also tried switching to the 28004x_generic_flash_lnk.cmd.  The only changes I made were to add some memory ranges so my application fits (no linker CRC tables or additional sections).  I still get the same error and it happens when its trying to program that same obj from the rts library. 

    Just trying to give you more data to help debug :)

    Trey

  • 0 in reply to Trey German8
    Expert 1950 points

    Vamsi,

    I figured it out!!! BUT I think this should behave slightly differently...let me explain.

    To help rule out the RTS library causing issues, I got rid of all my printf stuff so that was no longer linked it.  However I was still getting the same programming error.  The address just pointed to a function in my application this time.  This led me to look elsewhere.

    I'm linking in the DCL library which creates a section called dclfuncs.  Because I'm lazy and I'm not really testing any of that code yet, I was letting the linker throw that section wherever.  The linker ended up putting this code in M0 and gave me a warning about linking a section without a directive.  On a whim, I decided to properly place that section in my linker file and I stopped getting the programming error.

    I know previously we had discussed that when the flashAPI is used for programming with CCS, RAM loading isn't guaranteed.  In this case though it would appear that a potential RAM load really screwed up flashAPI operations.  I'm assuming this is because flashAPI uses M0, right?

    I think it would be really nice for user's like me (that are doing dumb things) if CCS/FlashAPI would compare load addresses in the out file with resources used during flash programming such that a more useful error message could be shown to the user.  This would improve the user experience and help cut down on forum posts of problems like this.

    Best,

    Trey

  • 0 in reply to Trey German8
    TI__Guru* 87155 points

    Trey,

    Glad it is clear now.

    We depend on CCS/Compiler architecture to build the flash plugin.  That means, we assume that users will take care of the warnings provided by the compiler and that they will develop the embedded application based on the suggested linker cmds for flash execution - If they are not taken care by the users, it would give a ripple effect like this in to other plugins' features.  We can keep adding redundant checks in to plugins but that would reduce the performance as it has to now check all the incoming addresses.  

    We did think through the message to report as you said: But, to do that, CCS should know which location is RAM and which location is Flash for each device.  At one point, we decided to use the gel - but customers keep editing gel files as well and also they would eliminate gels sometimes. Hence, the best solution for this would be to take a look at the warnings to make sure that application is fully embedded to flash.  For a few years, I printed this message in the console - but, customers started complaining that console has too much of info and that they are confused when they read those messages thinking that they did something wrong even when not.

    Thanks and regards,

    Vamsi

  • 0 in reply to Vamsi Gudivada
    Expert 1950 points

    Thanks Vamsi.  I understand the reasoning.  I'm of the opinion the console can never have too much info.  I read all the messages and use them to help me figure out my problems.

    Trey