• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 84 subscribers
  • Views 133 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.

TMS320F28384S: f28384s flash write and program jump

Jeongrok Lee
Prodigy 20 points
Part Number: TMS320F28384S


Tool/software:

I am using the TMS320F28384S and developing a bootloader program, but the program does not jump after performing a flash download.

Issue
Using the same bootloader program, if I write the program using the debugger, the jump works normally. However, if I write it using the bootloader, the jump does not occur.

Normal Operation
1-1. The APP program is directly written via the debugger (starting at 0x84000).
1-2. The bootloader program is directly written via the debugger (0x80000, only using sector 0 and 1).
1-3. In the bootloader, the APP program jump is made to the address of _c_int00.
1-4. The program jumps normally.

Failure Case
2-1. The bootloader program is directly written via the debugger (0x80000, only using sector 0 and 1).
2-2. Using SCIA, the HEX file is written to flash starting at address 0x84000, using the Fapi_issueProgrammingCommand function.
I have added the following hex file options:
-map=sections.txt --entrypoint=_c_int00 --memwidth=16 --romwidth=8 --order=LS
2-3. In the bootloader, the APP program jump is made to the address of _c_int00.
2-4. The program does not jump.

Points Checked / Questions

When comparing memory contents after writing with the debugger vs. writing with the bootloader,
the 8-bit Hex - TI Style view in the Memory Browser looks identical.
However, the 16-bit Hex - TI Style view shows differences. Which one should be considered correct?

Since the same bootloader is used, can we assume the program jump code itself is correct?

  • 0
    Prodigy 20 points

    Part Number: TMS320F28384S

    Tool/software:

    Below are the first six lines of the hex file.

    The image is a memory browser in CCS.

    Do the hex file and memory match?

    I'm developing a bootloader. I wrote the hex file through the bootloader, and I'm wondering if the data matches.

    :020000040008F2
    :064000009DD90800489D57
    :2040080003BD03BD1C58574C4A5A4C4E575BAD96A407840048464548471F000E101100A946
    :204028008098A61EA9269492AF10AF0E656565656565656565656565656565656565656547
    :204048006565656565656565656565650348034600444241484648AF006F00A98098AF10CD
    :20406800AF0E92A61EA926941F58000A65656565656565656565656565656565656565655D

  • 0 in reply to Jeongrok Lee
    TI__Genius 11055 points

    Hello,

    Did you align the flash sections in your linker command file on a 64-bit boundary? How are you programming the flash? Please refer to the F2838x Flash API Guide Recommended FSM Flows for the recommended Flash erase and program flows.

    Jeongrok Lee said:
    -map=sections.txt --entrypoint=_c_int00 --memwidth=16 --romwidth=8 --order=LS

    What HEX format are you using (TI_TXT, ASCII, INTEL, etc.)?

    Please try using a memwidth and romwidth of 16. Please search the C28x assembly tools manual for the sub-chapter titled Understanding Memory Widths.  That explains the relationship between target width, --memwidth, and --romwidth. On C28x, each address corresponds to one 16-bit word.  

    Best,

    Matt

  • 0 in reply to Matt Kukucka
    Prodigy 20 points



    MEMORY
    {
    BEGIN : origin = 0x084000, length = 0x000008 /* Reset vector / codestart */
    BOOT_RSVD : origin = 0x000004, length = 0x0001AD /* Reserved part of M0, used by BOOT ROM for stack */
    RAMM0 : origin = 0x0001B1, length = 0x00024F
    RAMM1 : origin = 0x000400, length = 0x0003F8

    RAMLSxDxGSx : origin = 0x008000, length = 0x00FFFF
    RAMGSx : origin = 0x018000, length = 0x004FF8

    FLASH_APP : origin = 0x084008, length = 0x03BFF8 /* Application code, data, etc. (example: 0x084002~0x0BFFFF) */
    // Additional FLASH sections can be added if needed

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

    SECTIONS
    {
    codestart : > BEGIN, ALIGN(8) /* Start at 0x084000 */
    .text : >> FLASH_APP, ALIGN(8) /* Place entire application code in FLASH_APP */
    .cinit : > FLASH_APP, ALIGN(8)
    .switch : > FLASH_APP, ALIGN(8)
    .const : > FLASH_APP, ALIGN(8)
    .TI.ramfunc : {} LOAD = FLASH_APP,
    RUN = RAMGSx,
    LOAD_START(RamfuncsLoadStart),
    LOAD_SIZE(RamfuncsLoadSize),
    LOAD_END(RamfuncsLoadEnd),
    RUN_START(RamfuncsRunStart),
    RUN_SIZE(RamfuncsRunSize),
    RUN_END(RamfuncsRunEnd),
    ALIGN(8)

    .stack : > RAMLSxDxGSx
    .bss : > RAMGSx
    .data : > RAMGSx
    .sysmem : > RAMLSxDxGSx
    .freertosHeap : > RAMLSxDxGSx
    .freertosStaticStack: >> RAMLSxDxGSx

    // Other sections remain unchanged
    }


    static inline bool flash_prog8(uint32_t lineAddr_word, const uint8_t *src8)
    {

    // lineAddr_word: 4-word(8byte)
    Fapi_StatusType st = Fapi_issueProgrammingCommand(
    (uint32_t *)lineAddr_word,
    (uint16_t *)src8,
    4, // 4 word
    0, 0, Fapi_AutoEccGeneration);//Fapi_DataOnly, Fapi_AutoEccGeneration
    if (st != Fapi_Status_Success) return false;
    while (Fapi_checkFsmForReady() != Fapi_Status_FsmReady) {}
    return true;
    }

    and The HEX file is Intel HEX format.

    I'll try changing romwidth to 16.

  • 0 in reply to Jeongrok Lee
    Prodigy 20 points

    The program is working properly after I set the ROM width to 16. Thanks for your help!

  • 0 in reply to Jeongrok Lee
    TI__Genius 11055 points

    Hello,

    That's great to hear! I'm glad you were able to resolve it quickly.

    Best,

    Matt