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.

TMS320F28377D: TMS28F28377D how to make firmware updates core 2 vs core 1

Part Number: TMS320F28377D
Other Parts Discussed in Thread: CONTROLSUITE, C2000WARE

Hi champs,

customer is builing application with following assignment:

Core 1 is responsible for control algorithm, core 2 for communication.

They have to perform a firmware update of core 1 by core 2 and ask for an appnote or example how to implement it.

I only can find basic flash programming examples in ControlSuite.

For a firmware update initiated by opposite cores, things as flash pump assignment, IPC and bootloader FW are to discuss.

 

Q: Do we have examples / appnote how to perform this fw update ?

  • Hi DJ,

    We have a good App note and example with source code for this type of flash programming.

    Please the serial flash programmer and the SCI flash kernels in controlSUITE or the new and improved C2000Ware.

    Here is the App note.
    www.ti.com/lit/sprabv4

    Please let me know if you have any further questions.

    Regards,
    sal
  • Hi Sal,

    here some progress and new questions.

    To be on latest tool chains, customer uses CCS7 now and investigates app note you mentioned (Serial Flash Programming).

    As mentioned, CPU-1 FW needs to be updated by CPU-2 (communication tasks).

    What is not 100% clear:

    Q1: Can we confirm, that during running CPU-1 application (control algorithm), CPU-1 can be

    - stopped

    - reprogrammed

    - restarted by CPU-2 ?

    Q2: In documentation "Serial Flash Programming..." is written, that FW is written into RAM.

    What kind of RAM is it (shared memory) and what is execution RAM for CPU-1?

    Q3: Not 100% clear: do we recommend to use Flash Kernel B (better as Kernel A)  over Kernel A?

    Q4: Which is example, that works with Kernel B ?

    Thanks!

  • A1:
    CPU1 will have to program its own flash. CPU2 cannot program CPU1 flash. What I suggest is for CPU2 to do the communicating externally, and have CPU2 pass the data to CPU1 via IPC or Message RAM. In this case, CPU1 would halt its execution of its control algorithm to execute its "bootloader" or DFU operation of receiving data from CPU2 via IPC or Message RAM and update its flash via the flash API.

    If CPU1 had enough room in flash to store the bootloader and two copies of the application, then it is possible for CPU1 to not have to halt its execution of the control algorithm, but could continue to execute it while the bootloader would be responding to IPC interrupts to update the second copy of the application. After finishing the DFU, the bootloader could jump to the updated control algorithm in flash. This would be a more advanced solution.

    A2:
    The FW application is loaded via SCI or the communication peripheral into RAM, and then programmed into flash using the flash API. This can be any RAM as long as it is writable and reading form the CPU doing the FW update.

    A3:
    You will need to use Flash Kernel B which is for F2837x.

    A4:
    In controlSUITE and C2000Ware, you will need to use the sci flash kernel examples.

    Hope this helps!

    sal
  • Hi Sal,

    meanwhile I got some explaining document, which I will send privately via email.