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.

LAUNCHXL-F280039C: F28003x Bootloader to App Jump Issue

Part Number: LAUNCHXL-F280039C
Other Parts Discussed in Thread: UNIFLASH

Tool/software:

Hi TI Experts,

I’m working on a F28003x bootloader and an App1. Here’s my setup:

 What I’ve Done So Far

  • Bootloader is located at 0x80000.

  • App1 is built to be located starting at 0x88000.

  • Bootloader receives .bin data via CAN and writes it to flash starting at 0x88000.

  • After writing, I compute and verify the CRC32 of the .bin — it matches, confirming the data was flashed correctly.

Issue

I try to jump from the bootloader to the App1 entry point (_c_int00) using the address from the App1 .map (0x000896BA), but I get an illegal interrupt handler.

Here’s the code I’m using for the jump:

#define APP1_ENTRY_ADDR  0x000896BAUL  // From App1 .map (_c_int00)

void jump_to_application(void)
{
    DEVICE_DELAY_US(100);

    CPUTimer_stopTimer(CPUTIMER0_BASE);
    CPUTimer_reloadTimerCounter(CPUTIMER0_BASE);
    CPUTimer_setEmulationMode(CPUTIMER0_BASE, CPUTIMER_EMULATIONMODE_STOPAFTERNEXTDECREMENT);

    DINT;
    IER = 0x0000;
    IFR = 0x0000;

    asm(" NOP"); asm(" NOP"); asm(" NOP"); asm(" NOP");
    DEVICE_DELAY_US(5000);

    void (*app_entry)(void) = (void (*)(void))APP1_ENTRY_ADDR;

    app_entry();

    // Never returns
}

What I’m Confused About

  • The .map is generated for the .out, which has symbols like _c_int00.

  • However, I’m downloading only the .bin (raw data) into flash at 0x88000. So:

    • Should I be jumping to the _c_int00 address from the .map?

    • Do I need to locate .codestart or any other entry point instead?

  • What’s the correct method for jumping from a bootloader to an app built for F28003x when using .bin files?

 What I’m Seeking

  • Clarification on how the .map vs .bin addresses relate.

  • Advice on the right entry point for a .bin-based App1.

  • Is my jumping method correct, or do I need to adjust it (e.g., setting SP, using .codestart)?

Thank you in advance!

If needed, I can also attach the .cmd files and .map files for both projects.

  • Hello,

    Yes, you need to jump to the address that the codestart symbol is mapped to in your linker cmd file. I recommend storing your entry point in an auxiliary register and using the LB command to branch to the application entry point. You can refer to the Long Indirect Branch in this document.

    How are you generating the bin file? If using the same method from this thread, it appears that the bin file will contain the first initialized data from your program and fill in any gaps until it reaches the last initialized word.

    Kind regards,

    Skyler

  • Hi ,

    Thank you for your response — I really appreciate your help!

    I wanted to give an update: Jumping to Application is now working fine with the same jumping sequence with address 0x88000 - codestart. The issue turned out to be with the .bin file generation. Currently, I am using this command:

    echo "========= Generating .bin firmware image ============="
    "${CG_TOOL_ROOT}/bin/hex2000" "${BuildArtifactFileName}" --binary -o="${BuildArtifactFileBaseName}.bin"
    

    This .bin contains only the raw data (about 14,302 bytes) and doesn’t include the padding (0xFF) across the actual flash range. In the memory browser, I observed chunks of 0xFF between actual data when the image is placed from 0x88000 to 0x90000.

    What worked for me was extracting the .bin file using Uniflash from the actual flash range (0x880000x90000), yielding a .bin. When I load this .bin over CAN starting at 0x88000, the app jumps successfully.

    What I’m looking for now: Is there a way to generate the .bin file with the padding (0xFF) already included — i.e., specifying the address range when invoking hex2000? In other words, is there an option or command to produce the .bin image for the app partition, including the “gap” filler (0xFF) in between actual sections, so I don’t have to rely on extracting it with Uniflash?

    Thank you in advance for your guidance!

  • Hi Prashanth,

    Please refer to the solution from George highlighted in this thread.

    Kind regards,

    Skyler

  • Hi ,

    Thanks a lot for your response! 
    My bootloader-to-app jump issue is now resolved.

    I also want to mention that by referring to this thread — I was able to understand the .hex conversion process clearly, and it helped fix the .bin generation for my app.

    • This is the Commad line for .bin file generation

    "C:/ti/ccs1281/ccs/tools/compiler/ti-cgt-c2000_22.6.1.LTS/bin/hex2000" --image --memwidth=16 --quiet --romwidth=16 --diag_wrap=off --binary -o "flashapi_ex1_programming_1.bin"  "flashapi_ex1_programming_1.out"  ../hexcmd.txt


    Additionally, I referred to the official CCS Hex Utility documentation here: Blog
    This gave me a solid understanding of how the ROMS settings work for .bin generation.

    Thanks again for your support!