Part Number: TMS320F280025C
Other Parts Discussed in Thread: C2000WARE
Hi
I encounter a very strange behaviour when I'm using the sci_flash example and flash a app generated with the HEX2000 utility.
When I run the program directly with the JTAG, it works without any trouble. I then use the bootloader provided by TI (C:\ti\c2000\C2000Ware_4_00_00_00\driverlib\f28002x\examples\flash) and the serial flash programmer (C:\ti\c2000\C2000Ware_4_00_00_00\utilities\flash_programmers\serial_flash_programmer) and it extremly depends on what I do in the linker script, if I can flash it or not with the serial flasher.
Application (blinky example with modified linker script):
https://www.mediafire.com/file/pb5n9tti1zg022p/app_example.zip/file
Application after HEX2000:
I used a little modified linker script from the universal motorcontrol lab, since the goal is to use the DFU for this application, but it needs to work reliable first:
/*
// FILE: f28002x_flash_lib_is_eabi.cmd
//
// TITLE: Linker Command File For F280025 examples that run out of Flash
//
//
// Keep in mind that L4, L5,L6 and L7 are protected by the code
// security module.
//
// What this means is in most cases you will want to move to
// another memory map file which has more memory defined.
//
*/
MEMORY
{
BEGIN : origin = 0x00084000, length = 0x00000002
BOOT_RSVD : origin = 0x00000002, length = 0x00000126
/* RAMLS5 : origin = 0x0000A800, length = 0x00000800 */
/* RAMLS6 : origin = 0x0000B000, length = 0x00000800 */
/* RAMLS7 : origin = 0x0000B800, length = 0x00000800 */
RAMLS567 : origin = 0x0000A600, length = 0x00001A00
/* Flash sectors */
/* BANK 0 */
/* FLASHBANK0_SECT0 : origin = 0x00080002, length = 0x00000FFE */
FLASHBANK0_BOOT : origin = 0x00084002, length = 0x00000FFE /* remote update */
/* FLASHBANK0_SECT1 : origin = 0x00081000, length = 0x00001000 */
/* FLASHBANK0_SECT2 : origin = 0x00082000, length = 0x00001000 */
/* FLASHBANK0_SECT3 : origin = 0x00083000, length = 0x00001000 */
/* FLASHBANK0_SECT4 : origin = 0x00084000, length = 0x00001000 */
/* FLASHBANK0_SECT5 : origin = 0x00085000, length = 0x00001000 */
/* FLASHBANK0_SECT6 : origin = 0x00086000, length = 0x00001000 */
/* FLASHBANK0_SECT7 : origin = 0x00087000, length = 0x00001000 */
/* FLASHBANK0_SECT8 : origin = 0x00088000, length = 0x00001000 */
/* FLASHBANK0_SECT9 : origin = 0x00089000, length = 0x00001000 */
/* FLASHBANK0_SECT10 : origin = 0x0008A000, length = 0x00001000 */
/* FLASHBANK0_SECT11 : origin = 0x0008B000, length = 0x00001000 */
/* FLASHBANK0_SECT12 : origin = 0x0008C000, length = 0x00001000 */
/* FLASHBANK0_SECT13 : origin = 0x0008D000, length = 0x00001000 */
FLASHBANK0_CODE : origin = 0x00085000, length = 0x00008000 /* control code */
/* FLASHBANK0_SECT14 : origin = 0x0008E000, length = 0x00001000 */
FLASHBANK0_DATA : origin = 0x0008D000, length = 0x00001000 /* constant data */
FLASHBANK0_SECT15 : origin = 0x0008F000, length = 0x000FF0
FLASHBANK0_SEC15_RSVD : origin = 0x08FFF0, length = 0x000010 /* Reserve and do not use for code as per the errata advisory "Memory: Prefetching Beyond Valid Memory" */
BOOTROM : origin = 0x003F0000, length = 0x00008000
BOOTROM_EXT : origin = 0x003F8000, length = 0x00007FC0
RESET : origin = 0x003FFFC0, length = 0x00000002
RAMM0S : origin = 0x00000128, length = 0x00000118 /* stack, on-chip RAM block M0 part */
RAMM1D : origin = 0x00000240, length = 0x000005B8 /* on-chip RAM block M0 part & M1 */
RAMM1_RSVD : origin = 0x000007F8, length = 0x00000008 /* Reserve and do not use for code as per the errata advisory "Memory: Prefetching Beyond Valid Memory" */
RAMGS0 : origin = 0x0000C000, length = 0x000007F8
RAMGS0_RSVD : origin = 0x0000C7F8, length = 0x00000008 /* Reserve and do not use for code as per the errata advisory "Memory: Prefetching Beyond Valid Memory" */
RAMLS4 : origin = 0x0000A000, length = 0x00000600
}
SECTIONS
{
.reset : > RESET, TYPE = DSECT
codestart : > BEGIN ALIGN(8)
.text : > FLASHBANK0_CODE, ALIGN(8)
.cinit : > FLASHBANK0_CODE, ALIGN(8)
.switch : > FLASHBANK0_CODE, ALIGN(8)
.cio : > FLASHBANK0_CODE
.pinit : > FLASHBANK0_CODE, ALIGN(8)
.const : > FLASHBANK0_CODE, ALIGN(8)
.init_array : > FLASHBANK0_CODE, ALIGN(8)
GROUP
{
#if defined(SFRA_ENABLE)
.TI.ramfunc
{
-l sfra_f32_tmu_eabi.lib<sfra_f32_tmu_collect.obj> (.text)
-l sfra_f32_tmu_eabi.lib<sfra_f32_tmu_inject.obj> (.text)
}
#else
.TI.ramfunc
#endif
ramfuncs
/* Digital Controller Library functions */
dclfuncs
dcl32funcs
} LOAD = FLASHBANK0_CODE
RUN = RAMLS567,
LOAD_START(RamfuncsLoadStart),
LOAD_SIZE(RamfuncsLoadSize),
LOAD_END(RamfuncsLoadEnd),
RUN_START(RamfuncsRunStart),
RUN_SIZE(RamfuncsRunSize),
RUN_END(RamfuncsRunEnd),
ALIGN(2)
ctrlfuncs : {
}
LOAD = FLASHBANK0_CODE
RUN = RAMLS567,
LOAD_START(ctrlfuncsLoadStart),
LOAD_SIZE(ctrlfuncsLoadSize),
LOAD_END(ctrlfuncsLoadEnd),
RUN_START(ctrlfuncsRunStart),
RUN_SIZE(ctrlfuncsRunSize),
RUN_END(ctrlfuncsRunEnd),
ALIGN(2)
.stack : > RAMM0S
.bss : > RAMM1D
.bss:output : > RAMM1D
.bss:cio : > RAMM1D
.data : > RAMM1D
.sysmem : > RAMM1D
est_data : > RAMLS4
}
SECTIONS
{
prms_data : > FLASHBANK0_DATA
GROUP
{
user_data
foc_data
}
LOAD = RAMM1D
LOAD_START(ctrlVarsLoadStart),
LOAD_SIZE(ctrlVarsLoadSize),
LOAD_END(ctrlVarsLoadEnd)
GROUP
{
sys_data
ctrl_data
motor_data
}
LOAD = RAMGS0
LOAD_START(motorVarsLoadStart),
LOAD_SIZE(motorVarsLoadSize),
LOAD_END(motorVarsLoadEnd)
GROUP
{
vibc_data
dmaBuf_data
datalog_data
graph_data
sfra_data
SFRA_F32_Data
}
LOAD = RAMGS0
LOAD_START(extVarsLoadStart),
LOAD_SIZE(extVarsLoadSize),
LOAD_END(extVarsLoadEnd)
}
/*
//===========================================================================
// End of file.
//===========================================================================
*/
Now to the problem I encounter with the SCI flashser:
Somehow it cannot write at address 0x859a2 with the above provided application, but the memory 0xFFFF in this sector and the length given to the flash programmer is also correct (size = 8 bytes). I used the debugger to verify this, and I really don't see, why.
The Fapi_issueProgrammingCommand() in flash_kernel_ex3_boot.c on line 291 fails with a PROGRAM_ERROR (Fapi_Error_AsyncIncorrectDataBufferLength):
//
//program 8 words at once, 128-bits
//
oReturnCheck = Fapi_issueProgrammingCommand(
(uint32_t *) BlockHeader.DestAddr, miniBuffer,
sizeof(miniBuffer), 0, 0, Fapi_AutoEccGeneration);
while (Fapi_checkFsmForReady() == Fapi_Status_FsmBusy);
oFlashStatus = Fapi_getFsmStatus();
if (oReturnCheck != Fapi_Status_Success || oFlashStatus != 0)
{
//
// first fail
//
if (fail == 0)
{
statusCode.status = PROGRAM_ERROR;
statusCode.address =
BlockHeader.DestAddr;
setFlashAPIError(oReturnCheck);
statusCode.flashAPIFsmStatus = oFlashStatus;
}
fail++;
}
The memory address it wants to write to is 0x859A2 and this looks valid to write 8 bytes to, since it is empty memory. Fapi_issueProgrammingCommand seems not to be able to write to a non-aligned address, right? What kind of alingment is expected and why does HEX2000 generate such addresses, that are not aligned?
I really don't see what goes wrong here and why this happens. When I comment out the following in the linker script, the DFU works, so somehow the HEX2000 generates a programm, that can be flashed, but both applications run without any trouble:
GROUP
{
vibc_data
dmaBuf_data
datalog_data
graph_data
sfra_data
SFRA_F32_Data
}
LOAD = RAMGS0
LOAD_START(extVarsLoadStart),
LOAD_SIZE(extVarsLoadSize),
LOAD_END(extVarsLoadEnd)
Maybe someone of you has an idea what goes wrong here? I really cannot find the issue and where this comes from. Are there sever mistakes in the linker script? But then, the app still runs without any trouble, so this should not prevent the flashing process, right?
