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.

TMS320F28375S: Same application linked at one flash address runs correctly from both flash banks - expected behavior on C2000?

Part Number: TMS320F28375S

Hello TI Team,

I am working on a C2000 device with dual flash banks (Flash Bank0 and Flash Bank1) and a custom CAN bootloader. I am trying to understand an observed behavior related to linker addresses and flash execution that seems to differ from common guidance.

My application is linked for flash starting at address 0x088000 (Flash Bank0). From this build, I generate a TI-TXT file. When flashing to Flash Bank0, my bootloader programs the TI-TXT file exactly as generated. When flashing the same application to Flash Bank1, while reading file, I add a fixed offset of 0x40000 to each address before programming it into flash. In this way, the same application image exists in both banks with an identical internal layout, only shifted by a constant offset. means one code is from 0x88000 to end (flash bank0) and same is from 0xc8000 to end (flashbank1).

At boot time, the bootloader selects the active bank and jumps to the corresponding application entry point in that bank. Even though the application is linked only for the 0x088000 flash address and no explicit runtime relocation logic is implemented, the application runs correctly from both Flash Bank0 and Flash Bank1.

This behavior is observed with a large application and is not limited to a simple test case. The application uses PIE and multiple interrupts, contains switch-case statements, uses Driverlib, and runs normally from either bank without crashes or incorrect behavior.

From general C2000 documentation and LFU examples, it is often stated that applications should be linked specifically for the flash address they execute from, and that separate linker files or relocation logic are required when running from different flash banks. Based on that guidance, I expected this approach to fail when running from Flash Bank1, but in practice it works reliably.

I would like clarification on whether this behavior is expected on C2000 devices. if not, Under what specific conditions would this approach fail? Is this approach considered unsupported but practically workable, or is it officially discouraged? Also, are there compiler options or future toolchain changes that could cause this behavior to break unexpectedly?

I am trying to understand the architectural reason this works in practice and whether it is safe to rely on with proper constraints.

I am attaching my linker file FYR.2837xS_FLASH_CLA_lnk_cpu1.zip 

Thank you for your time and guidance.

  • Hi,

    The expert is currently OoO and will return next week. Please expect a response once they return. 

    Kind regards,
    AJ Favela 

  • Hello,

    If any absolute addresses are used in a jump command, the program will go back to the original firmware. Given that you are programming the exact same application twice, can you confirm if the new firmware is even being executed? If you do not modify the codestart from the bank 0 application, the device will branch back from bank 1 to bank 0's codestartbranch regardless.

    Best,
    Matt

  • Hi Matt,

    thanks for the explanation. that helps clarify the concern around absolute branches and codestart.

    My follow-up is about the recommended architectural approach for dual-bank updates. My requirement is that the currently running application remains in the active bank while new firmware is always programmed into the inactive bank, after which the banks are swapped. From what I’ve seen, the common guidance is to maintain two separate builds with two different linker files, each linked to a specific flash bank.

    However, this creates a practical issue during updates, since it requires manually keeping track of which image corresponds to which bank.

    is there a cleaner TI-supported approach where bank selection is handled by the bootloader while still keeping the application structure consistent? I’m trying to understand what TI considers the correct long-term solution here.

    regards,

    Muzammil

  • Hello,

    True A-B flash bank swapping is not supported on F28x devices (but is now supported on the latest F29x architecture). The general recommendation for F28x is to maintain different linker command files corresponding to each flash bank's build configuration.

    I understand it is impractical, but an additional option is leverage the C2000 Hex Utility to uniquely name the TI-TXT output for bank 0 and bank 1 versions. This can help you track applications from the different build configurations.

    Best,
    Matt