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 !
