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.

TMS320F28388D: .data section contains uninitialized data

Part Number: TMS320F28388D

Tool/software:

Hello,

I am trying to build a custom bootloader for FW update for F28388D.
I have implemented the mechanism which seems to work in specific conditions.

My flash memory is splitted as follow :


[SELECTION LOGIC]
[PARTITION1]
[PARTITION2]

[SELECTION LOGIC] is placed at the FLASH entry point 0x080000. It checks which partition is the newest and jump to the beginning of it.

[PARTITION1] entry point starts with the codestartbranch.asm. This partition is able flash the [PARTITION2] by executing the FlashAPI from RAM.

Symmetrically, [PARTITION2] entry point starts with the codestartbranch.asm. This partition is able flash the [PARTITION1] by executing the FlashAPI from RAM.

At the end of an update process, the system reboot, [SELECTION LOGIC] executes and jumps to the newest [PARTITION].

Unfortunately, this flows is not behaving as expecting. When I flash with the debugger the [PARTITION1], my code is running as expected and I am able to write the [PARTITION2]. Note that in this scenario the [SELECTION LOGIC] has not been executed.

However, if I let the code start from the [SELECTION LOGIC] and attach the debugger without flashing, I can see that my code is not behaving as expecting and my application just run weirdly. By going further into the debugging, I noticed that some static global variables are uninitialized and filled with 0 even if they are initialized in my code.

The linker command file used is the following : (linker of the Partition1) 

MEMORY
{
    BOOT_RSVD           : origin = 0x000002, length = 0x0001AF     /* Part of M0, BOOT rom will use this for stack */

    RAMLS0_2		    : origin = 0x008000, length = 0x001800
   	RAMLS3		        : origin = 0x009800, length = 0x000800

	RAMGS0_4            : origin = 0x00D000, length = 0x005000
    RAMGS10       	    : origin = 0x017000, length = 0x001000
    RAMGS14             : origin = 0x01B000, length = 0x001000

	PART1_HEADER   		: origin = 0x084000, length = 0x000100
	FW_IMAGE_0			: origin = 0x084100, length = 0x003F00  /* on-chip Flash */
   	BEGIN            	: origin = 0x088000, length = 0x000100
   	FW_IMAGE_1			: origin = 0x088100, length = 0x01FF00  /* on-chip Flash */


    CPU1TOCPU2RAM_0     : origin = 0x03A000, length = 0x000400
    CPU2TOCPU1RAM_0     : origin = 0x03B000, length = 0x000400
    CPUTOCMRAM_0        : origin = 0x039000, length = 0x000400
    CMTOCPURAM_0        : origin = 0x038000, length = 0x000400


    RESET               : origin = 0x3FFFC0, length = 0x000002
}

SECTIONS
{

   codestart           : > BEGIN, ALIGN(8)
   .text               : >> FW_IMAGE_0 | FW_IMAGE_1, ALIGN(8)
   .cinit              : > FW_IMAGE_0 | FW_IMAGE_1, ALIGN(8)
   .switch             : > FW_IMAGE_0 | FW_IMAGE_1, ALIGN(8)
   .reset              : > RESET, TYPE = DSECT /* not used, */
   .stack              : > RAMGS0_4

#if defined(__TI_EABI__)
   .init_array      : > FW_IMAGE_0 | FW_IMAGE_1, ALIGN(8)
   .bss             : > RAMLS0_2
   .bss:output      : > RAMLS3
   .bss:cio         : > RAMLS0_2
   .data            : > RAMLS0_2
   .sysmem          : > RAMLS0_2
   /* Initalized sections go in Flash */
   .const           : > FW_IMAGE_0 | FW_IMAGE_1, ALIGN(8)
#else
   .pinit           : > FW_IMAGE, ALIGN(8)
   .ebss            : > RAMLS0_1
   .esysmem         : > RAMLS0_1
   .cio             : > RAMLS0_1
   /* Initalized sections go in Flash */
   .econst          : >> FW_IMAGE, ALIGN(8)
#endif

   MSGRAM_CPU1_TO_CPU2 : > CPU1TOCPU2RAM_0, type=NOINIT
   MSGRAM_CPU2_TO_CPU1 : > CPU2TOCPU1RAM_0, type=NOINIT
   MSGRAM_CPU_TO_CM    : > CPUTOCMRAM_0, type=NOINIT
   MSGRAM_CM_TO_CPU    : > CMTOCPURAM_0, type=NOINIT


  GROUP
   {
       .TI.ramfunc
       {
          -l F2838x_C28x_FlashAPI.lib
       }
   }  LOAD = FW_IMAGE_0,
	  RUN = RAMGS10,
	  LOAD_START(RamfuncsLoadStart),
	  LOAD_SIZE(RamfuncsLoadSize),
	  LOAD_END(RamfuncsLoadEnd),
	  RUN_START(RamfuncsRunStart),
	  RUN_SIZE(RamfuncsRunSize),
	  RUN_END(RamfuncsRunEnd),
	  ALIGN(8)


DataBufferSection : > RAMGS14, ALIGN(8)
}

And by looking at the generated .map file, I can see that the .data section is marked as UNINITIALIZED.

.data 0 0000928e 0000024b UNINITIALIZED
0000928e 00000200 Codec.obj (.data:CRC32_TABLE)
0000948e 00000018 FW_updater.obj (.data)
000094a6 00000018 Sk.obj (.data:sk)
000094be 00000008 Codec.obj (.data:FRAME_HEADER_MAGIC_NUM)
000094c6 00000006 rts2800_fpu64_eabi.lib : exit.c.obj (.data)
000094cc 00000004 Codec.obj (.data:ENCODE_FRAME_HEADER_MAGIC_NUM)
000094d0 00000002 Main_Master_CPU1.obj (.data)
000094d2 00000002 SCIA.obj (.data)
000094d4 00000002 rts2800_fpu64_eabi.lib : _lock.c.obj (.data:_lock)
000094d6 00000002 : _lock.c.obj (.data:_unlock)
000094d8 00000001 HWConfig_cpu1.obj (.data)

In practive, the UNINITIALIZED variables are : 

  • initialized correctly when I debug and flash at the same time, leading to normal behaviour
  • uninitialized when code boot from flash entry point and debug without flashing, leading to abnormal behaviour.

By looking at other forum post, I could see that --abi=eabi option is important for build and link. This option is present for me.
Also, the linker uses the --rom_model option.

I hope this is clear and someone can help me with this issue.

Thanks !

  • Hi,

    Do you have codetstart.asm programmed in [SELECTION LOGIC] as well? Are you building them as 3 separate .outs?

    I noticed that some static global variables are uninitialized and filled with 0 even if they are initialized in my code.

    Are these variables part of [SELECTION LOGIC] or [PARTITIONx]?

    And by looking at the generated .map file, I can see that the .data section is marked as UNINITIALIZED.

    You should also see copy tables info in the .map file that has the details on what sections gets initialized . Eg -

    This means the .data section will be initialized as mentioned in the table and this copy will be done by TI_auto_init function which is called as part c_int00 function

    Regards,

    Veena

  • Hi Veena,
    Thank you for your help.
    My problem was that c_int00 was commented out in the codestartbranch.asm. I copied this file from an example project without paying attention.