• State TI Thinks Resolved
  • Replies 3 replies
  • Answers 2 answers
  • Subscribers 82 subscribers
  • Views 84 views
  • Users 0 members are here
Support feedback
Options
Options
Related

F29H859TU-Q1: [F29H85x] Single-Image Boot Sequence for CPU1 and CPU3

ky pham
Prodigy 20 points

Part Number: F29H859TU-Q1
Other Parts Discussed in Thread: F29-SDK

Currently, we are developing software for the F29H85x target.

As I understand, the TI SDK multicore example uses separate applications for CPU1 and CPU3. CPU1 boots first, releases CPU3 from reset, loads the CPU3 code to RAM, and configures the CPU3 reset vector.

However, our design uses one application image for both CPU1 and CPU3. After CPU1 releases CPU3 from reset, we expect CPU3 to start from the same application entry/reset vector as CPU1 and execute the same application code.

Is this architecture supported on F29H85x? If yes, could you provide an example or guidance on the required startup code, reset-vector configuration, and linker script to support this approach?

  • 0
    TI__Mastermind 20336 points

    Hi,

    Yes CPU1 releases reset for CPU3 and CPU3 starts executing from the reset vector programmed.

    Note that there are different build configurations Flash and RAM build configurations. For CPU3 and CPU1 running out of RAM stored Code it is possible to keep same address for both CPU's and execute same code although there will be arbitration for two CPU's accessing the RAM blocks at same time.

    For Flash based config, CPU3 can access flash program only in Bank mode 2 and 3 with addresses shown below.

    Thanks

  • 0 in reply to Prarthan Bhatt
    Prodigy 20 points

    Thank you very much for the useful information.

    We would like to clarify our CPU1/CPU3 software architecture before finalizing the design.

    1. CPU3 boot and execution

    Currently, CPU1 starts from Flash FR-1 and executes the application code directly from Flash. The application code is not copied to SRAM.

    When CPU1 releases CPU3 from reset and configures the CPU3 reset vector to the same address as CPU1 (Flash FR-1 Address), CPU3 comes out of reset. However, CCS shows CPU3 as Running, and we cannot halt CPU3 or determine its current execution address.

    Could you please clarify:

    • How can we verify that CPU3 has started correctly?

    • How can we check the current CPU3 PC/execution address?

    • Is there any recommended register, CCS command, or script for checking the CPU3 status?

    2. Flash and SRAM execution

    Based on your previous explanation, our understanding is that CPU3 cannot directly execute application code from Flash FR-1.

    Therefore, our understanding is that:

    1. The application image is stored in Flash FR-1.

    2. CPU1 starts from Flash FR-1.

    3. CPU1 copies the required application code/image from Flash to shared SRAM (SRAM_CPA / SRAM_SDA).

    4. CPU1 executes the application from SRAM.

    5. CPU1 configures the CPU3 reset vector to the SRAM address and releases CPU3 from reset.

    6. CPU3 starts executing the application from SRAM.

    Could you please confirm whether this understanding is correct?

    In other words, after the startup process, can CPU1 and CPU3 execute the application entirely from shared SRAM without CPU3 directly accessing or executing application code from Flash?

    3. FOTA A/B swap

    For FOTA, our intended architecture is that CPU1 handles the FOTA process, including receiving the new image and managing the A/B images in Flash.

    After startup, CPU1 selects the appropriate image from Flash, copies it to shared SRAM, and then releases CPU3. CPU3 only executes the application from SRAM.

    Could you please confirm:

    • Can CPU1 handle the FOTA A/B image update and swap using BANKMODE = 1?

    • Is it correct that CPU3 only needs to execute the application from SRAM and does not need to directly access the Flash application image?

    • How should the Flash images and SRAM image be organized to support this FOTA architecture?

    4. CPU3 debugging

    For development, we also need to debug CPU3 after CPU1 releases it from reset.

    What is the recommended CCS procedure to:

    • Halt CPU3 immediately after it is released from reset.

    • Attach the debugger to CPU3.

    • Read the CPU3 PC/current execution address.

    • Load the CPU3 symbols.

    • Perform source-level debugging of the CPU3 application.

    If there are any recommended registers, CCS commands, GEL scripts, or other debugging procedures, please provide them.

    We would appreciate your clarification on these points, as they are important for finalizing our CPU1/CPU3 boot, memory, and FOTA architecture.

  • 0 in reply to ky pham
    TI__Mastermind 20336 points

    Hi,

    You cannot run CPU3 with same flash addr as CPU1 from FRI-1, it needs to be mapped to FRI-2 address as shown in the above table I shared. Refer to the F29-SDK multicore examples.

    ky pham said:

    1. The application image is stored in Flash FR-1.

    2. CPU1 starts from Flash FR-1.

    3. CPU1 copies the required application code/image from Flash to shared SRAM (SRAM_CPA / SRAM_SDA).

    4. CPU1 executes the application from SRAM.

    5. CPU1 configures the CPU3 reset vector to the SRAM address and releases CPU3 from reset.

    6. CPU3 starts executing the application from SRAM.

    Could you please confirm whether this understanding is correct?

    Yes, this would work.

    ky pham said:
    In other words, after the startup process, can CPU1 and CPU3 execute the application entirely from shared SRAM without CPU3 directly accessing or executing application code from Flash?

    CPU3 can access its code on FRI-2 address as shown in above table. Would highly recommend checking F29 sdk multicore examples and instructions.

    ky pham said:

    For FOTA, our intended architecture is that CPU1 handles the FOTA process, including receiving the new image and managing the A/B images in Flash.

    After startup, CPU1 selects the appropriate image from Flash, copies it to shared SRAM, and then releases CPU3. CPU3 only executes the application from SRAM.

    Could you please confirm:

    • Can CPU1 handle the FOTA A/B image update and swap using BANKMODE = 1?

    • Is it correct that CPU3 only needs to execute the application from SRAM and does not need to directly access the Flash application image?

    • How should the Flash images and SRAM image be organized to support this FOTA architecture?

    The way your software architecture is executing same code from SRAM not sure how the FOTA would work. You would need to partition CPU1 flash space and then handle FOTA in software as per your needs. Normally the FOTA in hardware is handled by Bankmode 3, please read the FLASH TRM chapter for FOTA implementation details in F29x device hardware.

    ky pham said:

    hat is the recommended CCS procedure to:

    • Halt CPU3 immediately after it is released from reset.

    • Attach the debugger to CPU3.

    • Read the CPU3 PC/current execution address.

    • Load the CPU3 symbols.

    • Perform source-level debugging of the CPU3 application.

    Yes load symbols for CPU3 .out and then you can debug code put breakpoints like CPU1.

    Thanks