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.

C5515 Upgrading the firmware

Other Parts Discussed in Thread: TMS320C5515

Hello,

I'm designing a device where in I have used TMS320C5515 DSP with 24-Bit SPI Flash to store my application program and a 64 Mb mSDRAM. My question is, to add Over The Air firmware upgrade feature to this device, is it possible to have a secondary Bootloader which will be able to boot my device and upgrade the firmware by over writing the application in the SPI flash.

If the above method is not a solution, can you tell me how can this be done?


Regards,

Supreeth

  • Hi, 

    Secondary boot-loading is very much possible, but can you provide more details on your scenario.

    Also, refer to the below forum posts which discuss on the same topic.

    https://e2e.ti.com/support/dsp/c5000/f/109/p/236318/828190#828190

     

    https://e2e.ti.com/support/dsp/c5000/f/109/t/283005

    Regards

     Vasanth

  • Hi Vasanth,

    I have a Wifi module with a Cortex-M3 32-bit microcontroller connected to the DSP on SPI. I want to be able to upgrade the firmware on DSP C5515 over the air using cloud.

    I want to know if having a secondary bootloader is the right method to upgrade the firmware or can I directly overwrite the application on SPI flash

    Regards,

    Supreeth

  • Supreeth,

    As I understand it, you always plan to boot from the SPI Flash.  What you are asking is what would be required to update that firmware, correct?

    How do you intend to write to the SPI Flash? Will this be done with the Cortex-M3?

    Vasanth,

    How have you seen firmware updates for systems using a C5515 be done in the past?

    Best Regards,

    Ben

  • Ben,

    Yes that is correct.
    The cortex M3 is connected to C5515 on SPI and yes I'm planning to overwrite the old firmware with new the new one from Cortex M3 via the C5515 DSP.
    I was wondering whether this will work ?

    Regards,
    Supreeth
  • Hi Supreeth,

    If I understand correctly,  you do not have direct path from Cortex to flash to update right ? 

    In this case I think you need secondary boot-loader & looks no other option isn't it . Your primary boot will check for any updates from cortex, if it is, then it will copy the image to flash & then execute secondary boot else it would direct execute the secondary boot.

    Hope this information helps..

    Regards

     Vasanth

  • Hi Vasanth,

    Your understanding is correct.

    When you say "Your primary boot will check for any updates " can the primary bootloader (assuming you are talking about the bootloader in DSP ROM) be modified to check for updates?

    Below is my understanding of your solution.
    During DSP boot, the primary boot in ROM will load the secondary boot to RAM which intern will check for Firmware update from Cortex M3. If there is an update available, the secondary boot shall overwrite the older version and transfer control to the new application code else the secondary boot shall transfer control to the already existing code

    How do I transfer the code control from secondary bootloader to the application code ?

    Have you come across any one who has implemented a secondary bootloader on DSP C5515?

    Regards,
    Supreeth
  • Hi Supreeth,

    Based on information provided, where only DSP been used for flash update, then secondary boot will become more feasible option..

    Below is what could be done as part of secondary bootloader

    1. The primary bootloader executes,  which basically copies the image from SPI flash to local memory.
    2. The copied program begin execution and checks for any new firmware upgrade exists, if the new firmware upgrade exists then this needs to copied to SPI (need to check the application size).
    3. Let’s take scenario of firmware upgrade exists . If I understand correctly, SPI with different chip select is used to interface both flash and DSP,  in this case copy of new firmware will be 2 step process first to copy to DSP internal memory and then to transfer the same to SPI flash. Once the new application image transfer to the  SPI is complete, then jump to the ROM start address.  
    4. If there is no upgrade then start the application from the location where it is supposed execute (that is from already copied user application code section in internal RAM).

    I had previously shared few E2E post related to secondary bootloader for your reference, below is additional link FYR.

    https://e2e.ti.com/support/dsp/c5000/f/109/p/276205/963891#963891

    Hope this helps.

    Regards

    Vasanth

  • Vasanth,

    As an alternative to having the secondary bootloader force a jump to the ROM start address, couldn't a hardware reset be triggered to get the same result?

    I don't see an issue with this as long as the hardware reset can be reliably triggered at the right time because a HW reset will cause the DSP to boot via the primary bootloader. (Mentioned on pg. 53 of the C5515 datasheet)

    Best Regards,
    Ben
  • Yes, this is possible as long as you have support for applying a reset (after firmware upgrade) in your system.

    Regards

     Vasanth