• State
  • Replies 3 replies
  • Subscribers 85 subscribers
  • Views 89 views
  • Users 0 members are here
Support feedback
Options
Options
Related

TMS320F28P650DH: Questions to Dual Core Program

Shengyue Zhong
Intellectual 1480 points

Part Number: TMS320F28P650DH
Other Parts Discussed in Thread: UNIFLASH, C2000WARE

Hi Team,

One of my customers is using F28P65, there are some confusion want to clarify, could you take a look and explain? Thanks a lot.

When program dual core

  1. In CCS, before programming CPU2’s flash, must we always execute Configure Clock in the On‑Chip Flash Plugin for CPU1 firstly?
  2. For the dual‑core F28P65 device, is there an officially recommended, streamlined flash‑programming flow?
  3. When moving to mass production, can the programming steps for CPU1 and CPU2 be automated (e.g., with scripts or a command‑line tool) so we don’t have to manually configure the bank map and perform step‑by‑step flashing each time?
Regarding dual‑core firmware communication and upgrade, I’d like to confirm the recommended implementation approach:
  1. When upgrading CPU2’s firmware, must CPU2 stay in reset or stopped state, or running?
  2. Is it recommended that CPU1 write directly to the flash bank assigned to CPU2, then hand over those banks to CPU2 and ask CPU1 to start CPU2 afterwards?
  3. During the upgrade, are there official guidelines on where Flash API calls should execute, RAM‑usage restrictions, and the appropriate timing for switching bank ownership?
  4. Are there any official examples or reference documents for dual‑core upgrades on the F28P65?
We have also observed that dual‑core flashing is highly sensitive to the flash‑bank map and erase ranges. I would like to confirm the following:
  1. Must the flash‑bank ownership for CPU1 and CPU2 exactly match the linker/map files of their respective projects?
  2. When flashing CPU2, should we always use the “Necessary Sectors Only (for Program Load)” erase mode instead of a broader erase range?
  3. For dual‑core F28P65 projects, is there an officially recommended flash‑bank allocation example?
  • 0
    TI__Mastermind 26730 points

    Hello,

    This expert is currently out of office. Please expect a delay in response until next week.

    Thanks & Regards,

    Allison

  • 0
    TI__Mastermind 26810 points

    Hi Shengyue,

    Shengyue Zhong said:
    In CCS, before programming CPU2’s flash, must we always execute Configure Clock in the On‑Chip Flash Plugin for CPU1 firstly?

    No, this is not required

    Shengyue Zhong said:
    For the dual‑core F28P65 device, is there an officially recommended, streamlined flash‑programming flow?

    Is this for development or for production? Different 3rd part flash programming solutions might have different implementations. From TI side, we provide Uniflash tool where users can load .out/.bin and a batch file can be created to execute a series of steps.

    Shengyue Zhong said:
    When moving to mass production, can the programming steps for CPU1 and CPU2 be automated (e.g., with scripts or a command‑line tool) so we don’t have to manually configure the bank map and perform step‑by‑step flashing each time?

    From TI side, Uniflash is provided and CLI can be used. More information can be found here: CCStudio UniFlash Quick Start Guide

    Best Regards,

    Marlyn

  • 0 in reply to Marlyn Rosales Castaneda20
    TI__Expert 4270 points

    Hello,

    Regarding dual‑core firmware communication and upgrade, I’d like to confirm the recommended implementation approach:

    Shengyue Zhong said:
    When upgrading CPU2’s firmware, must CPU2 stay in reset or stopped state, or running?

    CPU2 can keep running as long as it is not executing code from a flash bank that is being modified.

    Shengyue Zhong said:
    Is it recommended that CPU1 write directly to the flash bank assigned to CPU2, then hand over those banks to CPU2 and ask CPU1 to start CPU2 afterwards?

    This is an implementation choice. In our reference example, CPU2 handles the FWU and owns all the inactive banks + its own active bank. The approach you have described would work as well. Whichever CPU is programming the FWU data must own the flash bank it is programming to.

    Shengyue Zhong said:
    During the upgrade, are there official guidelines on where Flash API calls should execute, RAM‑usage restrictions, and the appropriate timing for switching bank ownership?

    There isn't anything official other than the restrictions documented in the Flash API guide (Flash operations should execute either from a separate flash bank than the one being erased/programmed or from RAM). Switching bank ownership can be done at any point after programming has completed.

    Shengyue Zhong said:
    Are there any official examples or reference documents for dual‑core upgrades on the F28P65?

    See the can_flash_lfu_sbl_f28p65x example under C2000Ware/driverlib/f28p65x/examples/c28x_dual/flash_kernel

    Shengyue Zhong said:
    Must the flash‑bank ownership for CPU1 and CPU2 exactly match the linker/map files of their respective projects?

    Yes. If a CPU does not own a flash bank it cannot access it.

    Shengyue Zhong said:
    When flashing CPU2, should we always use the “Necessary Sectors Only (for Program Load)” erase mode instead of a broader erase range?

    This is up to you. As long as your linker file does not include any region assigned to CPU1 it will work. You can also just pick the banks you are using for each CPU.

    Shengyue Zhong said:
    For dual‑core F28P65 projects, is there an officially recommended flash‑bank allocation example?

    Any multicore project (e.g. LED blinky or the CAN Dual-Core LFU example I mentioned above) should work. The important part is to make sure the flash plugin is configured properly.

    Best,

    Alex