• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 83 subscribers
  • Views 154 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.

LAUNCHXL-F2800157: Request for Reference Implementation – Dual Image / Flash Flag / Firmware Validation (TMS320F2800157)

Md Kamarudheen
Prodigy 40 points

Part Number: LAUNCHXL-F2800157
Other Parts Discussed in Thread: TMS320F2800157, C2000WARE

Hello Team,

I am currently working on implementing a software-controlled firmware update mechanism on the TMS320F2800157 (C2000) device using the approach described in the TI application report SPRACN1 (SCI boot-based firmware update using GPIO-controlled boot selection).

While the current approach works for normal firmware update flow, I have concerns regarding robustness and recovery in power failure scenarios.

 Current Implementation

  • Device: TMS320F2800157
  • Boot configuration: Custom boot via OTP using GPIO (similar to SPRACN1)
  • Update method: SCI boot + serial flash programmer
  • Flow:
    • Application sets GPIO high → reset
    • Boot ROM enters SCI boot
    • Kernel downloads and programs application

 Concern

If power loss occurs during flash erase/write, the system may:

  • Boot again into Flash mode (GPIO low)
  • But Flash may contain corrupted/partial application
  • Resulting in invalid execution or non-recoverable state

This makes the current approach non-fail-safe for production use

 Requirement

I would like to enhance the design with robust firmware update mechanisms, including:

1. Dual Image Support

  • A/B application partitions in Flash
  • Safe update without overwriting running image
  • Rollback capability on failure

2. Flash-Based Update Flag

  • Persistent flag stored in Flash indicating:
    • Update in progress
    • Update successful
  • Boot decision based on this flag instead of only GPIO

3. Firmware Validation

  • CRC / checksum verification before jump to application
  • Detection of corrupted image
  • Automatic fallback to update mode

 Specific Questions

  1. Does TI provide any reference examples or demo projects for:

    • Dual image firmware update on F2800157 (or similar devices)
    • Flash flag-based boot flow control
    • Firmware validation (CRC/checksum)

  2. Are there any C2000Ware examples / libraries / APIs for:

    • Image integrity verification
    • Flash metadata handling (flags / headers)

  3. Is there any bootloader reference implementation that supports:

    • Fail-safe firmware update
    • Recovery after power interruption

  4. Are there any recommended best practices for:

    • Flash partitioning for dual image
    • Reliable firmware update over SCI
    • Handling incomplete firmware updates

 Additional Context

  • Use case: Production system requiring reliable firmware update
  • No JTAG access during field updates
  • Requirement: Fail-safe recovery from power failure during update

 Expected Outcome

I am looking for:

  • Reference implementations (if available)
  • Application notes or internal documentation
  • Recommended architecture/design approach

 

Thank you for your support.

Regards,
Kamarudheen Md

  • +1
    TI__Mastermind 20380 points

    Hello,

    Apologies, I am out of office until next Wednesday. Please expect a delay in response until then.

    Best,

    Matt

  • 0 in reply to Matt Kukucka
    TI__Mastermind 20380 points

    Hello,

    Note that F280015x are single flash bank devices, so you'll have to keep firmware images A + B and a custom bootloader (if necessary) in the same bank. There is a level of risk since power loss / interruptions during flash programming can cause flash corruption. You could circumvent this by employing the peripheral bootloaders provided in the ROM to load flash kernel to program the application. This flash kernel can implement the flash metadata and image integrity validation procedures you require. 

    I would refer to the following resources:

    Best,
    Matt

  • 0 in reply to Matt Kukucka
    Prodigy 40 points

    Hello Matt,

    Thank you for your explanation.

    I understand that F280015x is a single flash bank device and full dual-image support is difficult. I will review the flash kernel and LFU examples you mentioned.

    However, I still want to make my firmware update fail-safe, especially for power failure cases.

    I have a few clarifications:

    1. Since dual-image is not fully possible, what is the recommended safe approach?

      • Should we use:
        • Flash flags (update in progress / valid image)?
        • CRC validation before jumping to application?

    2. For storing flags in Flash:

      • Is there any recommended structure?
      • Should we use a separate Flash sector?

    3. For firmware validation:

      • Which is better for production:
        • VCU CRC example
        • Linker-generated CRC

    4. In case of corrupted firmware:

      • Should we always rely on ROM boot mode (SCI boot) for recovery?
      • Or is there any better approach?

    My goal is to build a robust firmware update system that can recover safely after power loss.

    Please suggest the best approach for this device.

    Thanks & Regards,
    Kamarudheen Md

  • 0 in reply to Md Kamarudheen
    TI__Mastermind 20380 points

    Hello,

    Md Kamarudheen said:

    Since dual-image is not fully possible, what is the recommended safe approach?

    • Should we use:
      • Flash flags (update in progress / valid image)?
      • CRC validation before jumping to application?

    I recommend both to mitigate risk. 

    Md Kamarudheen said:

    For storing flags in Flash:

    • Is there any recommended structure?
    • Should we use a separate Flash sector?

    Generally, we recommend:

    • Allocating a dedicated sector at the end of flash so it doesn't interfere with application code
    • Storing:
      • Status flag: Indicates update state
      • CRC: Expected checksum of the new image

    A similar structure (without CRC) is detailed in the LFU documentation I provided above.

    Md Kamarudheen said:

    For firmware validation:

    • Which is better for production:
      • VCU CRC example
      • Linker-generated CRC

    I recommend both. Use the CCS linker option to embed a 32-bit CRC directly into the image. The bootloader reads that value and compares it with a freshly computed CRC of the programmed region.

    Please also check out this documentation on the CRC resources and recommended use-cases for C2000 device: https://www.ti.com/lit/an/spracr3/spracr3.pdf

    Md Kamarudheen said:

    In case of corrupted firmware:

    • Should we always rely on ROM boot mode (SCI boot) for recovery?
    • Or is there any better approach?

    I think that would be the best option. You can implement a multi-layered recovery strategy:

    Primary: Status flag + CRC validation

    • Bootloader detects corruption via CRC check and reads the status flag on every reset
    • If the flag indicates in-progress or the flag indicates done + CRC doesn't match:
      • Stay in bootloader mode (waits for new image via SCI/CAN/etc.)

    Secondary: Watchdog reset

    • If update hangs, watchdog resets the device
    • Bootloader sees "in-progress" flag / CRC mismatch condition and retries firmware update

    Tertiary: ROM boot mode

    • If bootloader itself is corrupted, device falls back to ROM bootloader
    • Can recover via SCI/CAN/etc. boot

    Best,

    Matt

  • 0 in reply to Matt Kukucka
    Prodigy 40 points

    Hello Matt,

    Thank you for your detailed response and for pointing me to the LFU examples, CRC resources, and recommended multi-layer recovery strategy. Your explanation on using status flags + CRC validation + ROM boot fallback was very helpful.

    Based on your suggestions, I am proceeding with the following architecture:

    • Dedicated Flash sector for metadata (status flag + CRC)
    • Linker-generated CRC + runtime CRC validation
    • ROM SCI bootloader fallback for recovery
    • Use of flash kernel (from C2000Ware) for programming

    Additional Clarification: Custom Bootloader + GPIO-Based Recovery

    In addition to the above, I am planning to integrate a small custom bootloader in Flash along with the GPIO-based boot switching approach (similar to SPRACN1), and I would like your opinion on this combined approach.

    Proposed Enhancement

    1. At reset (Flash boot):

      • Custom bootloader executes first
      • Reads:
        • Flash status flag (update state)
        • CRC validation result

    2. Boot decision:

      • White check mark If firmware is valid → Jump to application
      • X If firmware is invalid OR flag indicates "update in progress":
        • Drive boot GPIO (e.g., GPIO15) HIGH
        • Trigger software reset
        • Device enters ROM SCI boot mode

    3. SCI programming phase:

      • Flash kernel executes
      • Metadata sector updated:
        • Set "update in progress"
        • Program new image
        • Update CRC
        • Set "update complete"

    4. Recovery behavior (power failure case):

      • If interruption occurs:
        • Flag remains "in progress" OR CRC mismatch
        • Bootloader detects failure on next reset
        • Forces SCI boot again (via GPIO + reset)

    Questions

    1. Architecture Validation

      • Is this combination of:
        • Flash bootloader (for validation + decision)
        • GPIO-based boot switching (to force ROM bootloader)
        a recommended and safe approach for F2800157?

    2. GPIO-Based Boot Override

      • Instead of relying only on ROM fallback, is actively forcing SCI boot via GPIO (as in SPRACN1) considered reliable for production systems?

    3. Bootloader Location Safety

      • Since this custom bootloader resides in Flash (same bank):
        • What precautions should be taken to protect it from corruption during flash erase/write?
        • Is it recommended to:
          • Place it in a separate sector and never erase it?
          • Use any hardware/software protection mechanisms?

    4. Failure Edge Case

      • In the worst case where:
        • Bootloader itself is corrupted
      • I assume ROM bootloader is the only recovery path.
      • Is this understanding correct, and is there anything else recommended to handle this scenario?

    Goal

    My goal is to build a fail-safe firmware update system that:

    • Detects corrupted or incomplete firmware
    • Automatically recovers using SCI boot
    • Handles power failures safely
    • Minimizes risk despite single-bank Flash constraints

    Thanks again for your support and guidance.

    Best regards,
    Kamarudheen Md

  • 0 in reply to Md Kamarudheen
    TI__Mastermind 20380 points

    Hello,

    Md Kamarudheen said:

    Architecture Validation

    • Is this combination of:
      • Flash bootloader (for validation + decision)
      • GPIO-based boot switching (to force ROM bootloader)
      a recommended and safe approach for F2800157?

    Yes, this would be my recommendation for a single bank device.

    Md Kamarudheen said:

    GPIO-Based Boot Override

    • Instead of relying only on ROM fallback, is actively forcing SCI boot via GPIO (as in SPRACN1) considered reliable for production systems?

    Yes, that will cover the most common cases. You can also branch directly to the ROM bootloader from application code, which provides an alternative to the GPIO + reset approach if needed. However, when doing so, account for device state differences -- your bootloader may have changed PLL and Watchdog settings compared to a cold boot, and the ROM bootloader expects specific initialization states.

    My only concern is the event the flash bank itself is corrupted, then bootloader would not be able to execute and configure the device for SCI boot. I recommend having some kind of supervisor circuit to force SCI boot through the boot pins if the device hangs. 

    Md Kamarudheen said:

    Bootloader Location Safety

    • Since this custom bootloader resides in Flash (same bank):
      • What precautions should be taken to protect it from corruption during flash erase/write?
      • Is it recommended to:
        • Place it in a separate sector and never erase it?
        • Use any hardware/software protection mechanisms?

    Yes, generally we recommend placing the bootloader in its own a separate flash sector and isolate with software-enforced guards. There are write-erase protection (WEPROT) masks that will prevent certain flash sectors from being erased or written to. Please check out the F280015x Flash API User's Guide: https://www.ti.com/lit/ug/spruj96/spruj96.pdf

    Also, note that the Flash API needs to execute from RAM (which you already intend to do since you're using a flash kernel) since simultaneous read/writes are not permitted by the device's flash architecture.

    Md Kamarudheen said:

    Failure Edge Case

    • In the worst case where:
      • Bootloader itself is corrupted
    • I assume ROM bootloader is the only recovery path.
    • Is this understanding correct, and is there anything else recommended to handle this scenario?

    Yes, the ROM bootloaders would be the only path. See my advise for (2) above. 

    Best,
    Matt