F29H85X-SOM-EVM: FOTA

Part Number: F29H85X-SOM-EVM

I have an application that runs on CPU 1 and CPU 3, the structure of the project is based on the blinky multi core code. When the application is built an elf file is generated for the CPU1 project and as far as can understand the post build steps include, in a section, the CPU3 flash contents. The flash areas for each core start at the base defaults for bank management mode 2. This elf file is selected for download in CSS for flash programming.

Assuming I can already transfer the said elf file to the target I would like to understand how I can program it using FOTA. I would like to know if there are any recent examples or documentation for the F29x which might help me to achieve this?

 

  • Seems like I need a binary file for each CPU, one to flash to offset 0x10000000 and the other to 0x10400000 or the FOTA addresses 0x10600000 and 0x10700000. Then some bank management trickery to switch banks?

  • Hi Simon,

    Please give this a read:

     [FAQ] F29x Flash Module & FOTA: Frequently Asked Questions 

    Let me know if you still have residual questions

  • Nilabh,

    Thank you for getting back to me. I have already looked at that and it really goes into no detail as to what and where to load the things.Sorry this document is a million miles away from the information I need. Specifically

    1, What output artifact do I need to send to the board. Assuming this is the bin file from CPU1?


    2. When It gets there I need to program areas for CPU1 and CPU3? How is it structured and how does it split?

    3. Do I have to program at off sets 0x10000000 for CPU 1 and 0x10400000 for CPU3 or the FOTA addresses 0x10600000 and 0x10700000?

    4. Using FOTA in this case would imply bank mode 3. If I set bank mode 3 CCS cannot program the device. How do I overcome this?

    5. When the data is programmed then I need to update BANK_UPDATE_CTR and restart, is that all?

    Regards

    Simon

     

  • Let me consolidate the info and get back to you by Monday.

  • Hi Simon,

    I think this example should serve as good starting point for your questions 

    1. Flash-based CAN SBL with FOTA Example

    Further more on your questions,

    You send the combined .bin file from the CPU1 project. The post-build steps in the SBL examples merge the bootloader + CPU1 application (and CPU3 content) into a single binary, with an X.509 certificate prepended 1. This is the same artifact your existing build already produces—the .bin generated from the CPU1 project's post-build steps that includes the CPU3 flash contents as an embedded section.


    2. Structure and Split

    The 4MB program flash is organized as 4 interleaved bank-pairs (each 1MB combined, two 512KB physical banks). In Bank Mode 3, the flash is split between CPU1 and CPU3 with FOTA enabled 2:

    Region Active (execution) Inactive (FOTA target)
    CPU1 FRI-1 (0x10000000) FRI-3 CPU1 portion (0x10600000)
    CPU3 FRI-2 (0x10400000) FRI-3 CPU3 portion (0x10700000)

    Your SBL receives the single .bin and programs the CPU1 and CPU3 portions to their respective inactive bank addresses. The SBL example code handles this split—it knows which portions go where based on the image structure.


    3. Which Addresses to Program

    For FOTA updates, program to the inactive/update addresses: 0x10600000 (CPU1) and 0x10700000 (CPU3) 3. These map to FRI-3, the firmware update region. The 0x10000000/0x10400000 addresses are the active execution regions—you don't write there while the application is running. After the bank swap, what you programmed at 0x10600000/0x10700000 becomes the new active code at 0x10000000/0x10400000.


    4. CCS Programming in Bank Mode 3

    Use the PROG_BANKMODE register (offset 0x70 in SSU_GEN_REGS) 4. This register overrides the active bank mode for programming logic only during SSUMODE1/SSUMODE2 (debug modes), without changing the actual runtime bank mode. The workflow:

    1. Set PROG_BANKMODE.MODE = 0x3 (CPU1/CPU3 split with FOTA) via the CCS Flash Plugin settings
    2. CCS can now program code destined for Bank Mode 3 memory regions
    3. Program your BANKMGMT sector to set the actual device BANKMODE to 3
    4. Issue XRSn reset—device boots in Bank Mode 3

    Alternatively, for initial device setup you can use the UART/CAN Flash Programmer tool from the SDK, which supports bank mode configuration commands directly 1.


    5. Completing the FOTA Update

    Yes, that's essentially the complete flow 5:

    1. Program new firmware to inactive banks (FRI-3 addresses)
    2. Erase the inactive BANKMGMT sector
    3. Program BANKMODE field in inactive BANKMGMT
    4. Program BANK_UPDATE_CTR to a value one less than the active region's counter (lower = newer)
    5. Trigger XRSn reset (via SIMRESET.XRSn register from CPU1, or hardware pin)

    Important ordering: Program BANKMODE before BANK_UPDATE_CTR to prevent boot failures on power loss mid-operation. After reset, bootROM detects the lower counter value and swaps banks automatically.


    1. Flash-based UART SBL with FOTA Example
    2. F29H85x Datasheet - Flash Bank Modes
    3. F29x Flash Module FOTA FAQ
    4. F29H85x TRM - PROG_BANKMODE Register
    5. F29H85x FOTA Application Note - Bank Management
  • Nilabh,

    Thank you so much for the update, it has helped a lot and think I have all the information I need,

     Do not intend to use the SBL and plan to just program the flash areas for both CPU's, switch banks and restart. Do you see any issue with that approach?

    Still a bit confused about the bin file. It makes sense that things are grouped like this. I have been reading and dumping flash areas to help me understand. It would seem that the CPU1out elf file contains all I need and I plan to use that. I cannot find a binary match for the start of the flash sections for either CPU in the bin file. Any idea why that would be, encrypted, compressed?

    Regards

    Simon 

  • Seems that I need a flat binary image file to flash the software. This does not seem to be what is in the .bin that gets created. Do I need use tiobj2bin or create my own program to generate the flat binary image?

  • Simon,

     Do not intend to use the SBL and plan to just program the flash areas for both CPU's, switch banks and restart. Do you see any issue with that approach?

    Yes it depends on how you design your system.

    Still a bit confused about the bin file. It makes sense that things are grouped like this. I have been reading and dumping flash areas to help me understand. It would seem that the CPU1out elf file contains all I need and I plan to use that. I cannot find a binary match for the start of the flash sections for either CPU in the bin file. Any idea why that would be, encrypted, compressed?

    We have been using .bin image for our examples. The bin file is signed so that HSM can validate teh autheticity of firmware.

  • To try and work out what goes where I have been dumping the start of certain flash locations. When CCS programs things using the .out file it writes flash by section. The first section in the certificate. The start of this you can see at 0x10000000 and 0x10400000 and it can be seen in the .out file. However this pattern is not in the .bin. As such I do not see how sending the bin will work. I need flat images which start at 0x10000000 and 0x10400000. The bin starts with different data.

    Flash data dump

    .out file matches flash contents

    bin file does not match

  • if the bin was good to go how would I know what I write to 0x10000000 and 0x10400000. It just does not look like a flat image.

  • Let me get back on this by friday.

  • So it would seem that the bin file does not include the certificates for CPU1 or CPU3. 

    Can I program the flash without the certificates? If so do I need to leave the certificate flash range empty? In the combined CPU1/CPU3 binary the images for the two CPU's are just sequential in the bin file. As such when the size of the CPU1 image changes, the start of the data for CPU3 will move. This means the embedded software will need to process the image in some way to understand what goes at flash offset 0x10000000 and 0x10400000. Is there any specific pattern in the data that the embedded software could look for to mark the start of the flash area for CPU3. I have noticed that the start of the CPU1 image, minus the certificate is 

    00 90 30 0C 7F 11 52 0B 7F 11 52 0B C0 10 68 00

    and CPU3

    02 90 31 0C 7F 11 52 0B 7F 11 52 0B FF 28 78 01

    This seems like some sort of pattern that I could match? How do you normally expect the embedded software to do this?