• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 84 subscribers
  • Views 1339 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.

TMS320F28388D: What documentation resources are there that show how to perform a firmware update?

Howard Li 2
Intellectual 871 points
Part Number: TMS320F28388D
Other Parts Discussed in Thread: C2000WARE

Hi,

I currently know of the following documents and webpages that provide information on performing a "firmware update":

I have found the Flash kernels projects mentioned in those documents inside my C2000Ware installation. Although, the projects were made with F2837x MCUs in mind, they should still work with a F28388D MCU (as least for re-programming the Flash memory for CPU1 and CPU2). However, because they were made for that set of MCUs, I am unable find documentation regarding how to reprogram the Flash memory of the Connectivity Manager.

Sincerely,

Howard Li

P.S.: I only have one controlCARD with me, so any instructions that involve OTP memory is out of the question.

EDIT: Given what I have read, the C2Prog tool suppose to serve the same purpose as the serial_flash_programmer while automatically providing a Flash kernel/"secondary bootloader", is that correct?

  • 0
    TI__Mastermind 25970 points

    Howard, an expert will get back to you on your queries.

    Thanks,

    Sira

  • 0
    TI__Guru* 87145 points

    Hi Howard,

    We have CM Flash API library available at \C2000Ware_3_02_00_00\libraries\flash_api\f2838x\cm\lib.

    We have a CM flash programming example at C2000Ware_3_02_00_00\driverlib\f2838x\examples\cm\flash\flashapi_cm_ex1_programming.c.

    We don't have flash kernels developed for CM yet.  But, we worked with Codeskin (3rd party) on this and their C2Prog flash programmer supports CM firmware update mechanism: https://www.codeskin.com/programmer.  Please check out.  CM Flash API and CM flash image are streamed via CPU1 and loaded to shared RAM so that CM can take over from there to program it's application image in its bank.     

    If you need more details on this, you can contact Codeskin at info@codeskin.com

    Thanks and regards,

    Vamsi

        

  • 0 in reply to Vamsi Gudivada
    Intellectual 871 points

    After some practice, I am confident in implementing a secondary bootloader for CPU1.

    However, I am still not confident in implementing a secondary bootloader for CPU2/CM.

    I know that CPU2 and CM can copy the data in their respective IPC Message RAMs into processor appropriate main RAMs and then boot from that RAM. The issue is that one can only provide an application that has a hex-ed form uses 2000 bytes or less of memory as that is the maximum capacity of the MSGRAMs.

    A secondary bootloader that uses IPC and the Flash API would most likely exceed that copy length capacity. The way I see it, I would need to use the Copy IPC Message RAMs boot mode to load a smaller application that would then load the actual bootloader into memory which would then finish the firmware upgrade process for CPU2/CM.

    EDIT: Resetting the other processor to boot from RAM suffers from the fact that its entry point is identical to the entry point used by the IPC Message Ram Copy boot mode. It seems the only way to have a bootloader for CPU2/CM is to use Flash memory.

  • 0 in reply to Howard Li 2
    TI__Guru* 87145 points

    Hi Howard,

    CPU1 and CPU2 share 128KB RAM (shown in GS0 to GS15 in Table 6-1. C28x Memory Map of the datasheet). Please check.

    Thanks and regards,
    Vamsi

     

  • 0 in reply to Vamsi Gudivada
    Intellectual 871 points

    Vamsi Gudivada said:

    Hi Howard,

    CPU1 and CPU2 share 128KB RAM (shown in GS0 to GS15 in Table 6-1. C28x Memory Map of the datasheet). Please check.

    Thanks and regards,
    Vamsi

     

    That is true, but what about getting the bootloader into CM RAM? The CPU1_TO_CM_MSGRAM is too small to hold a bootloader, unless there is some way to make a bootloader to fit within ~1900 bytes. 

  • 0 in reply to Howard Li 2
    TI__Guru* 87145 points

    Howard,

    I saw that you opened a new post on this last question on creating a basic loader.  You can continue the discussion on that thread.  I am closing this post. 

    Thanks and regards,

    Vamsi