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.

TMS320C6727B: Reg doubt Flash boot method change

Part Number: TMS320C6727B

Currently, our application successfully supports booting from parallel flash. The Flash .bin image contains the Configuration data + Secondary boot loader (comprises of the complete application).

We are changing the Flash boot method due to some Programming issues.

We want to achieve the following

1) Burn a (Tiny_Golden.)bin file containing Configuration data + secondary boot loader in to the Flash.

---- This is capable of receiving (Application.)bin file from host and burning into the Flash at a particular address.

---- Tiny_Golden.bin file and Application.bin file will have different non-overlapping memory map in the SDRAM (defined in their .cmd file).

2) Tiny_Golden.bin file will point to the start address of Application.bin, which then takes over till reset again. 

I want to verify if above method is feasible. Since I am a newbie, please let me know if any other details are required to understand the nature of change.

  • Hi Lak N,

    I've forwarded this to the experts. Their feedback should be posted here.

    BR
    Tsvetolin Shulev
  • Yes, this is feasible and is used by many of our application developers to perform field upgrades or pull application image from a host/FPGA or Microcontroller or any other master on the system.

    Regards,
    Rahul
  • Dear Rahul

    Thanks for the response.

    Is there a reference project or material to achieve such a method to pull up application image from host or flash ? 

    Thanks

    Lak

  • Lak,

    this is pretty mature device so I am not sure I can point you to a ready to use exaample that is created for this device but you can look at the secondary bootloader description here which is created for DA830/C6747 device that has a similar usage as you described in your post:
    processors.wiki.ti.com/.../DA8xx_Secondary_Boot_Loader_Customization_for_SPI_Master_Boot

    Regards,
    Rahul
  • I shall go through the same. 

    I also want to clarify about how to execute the Application.bin image from Golden_Tiny.bin image.

    1) we already have working code to burn the *.bin to Flash (with particular Offset - 0 offset for Golden.bin + 0xxx offset for Application.bin)

    2) the Golden_tiny.bin file will include the TiSecondaryBoot loader stage (App note SPRAA69D), that will communicate with host. It may or may not update Application.bin (with non overlapping memory map) 

    3) How does the transfer of program execution happen from Golden_Tiny.bin to Application.bin

    I am unable to visualize the same. If you can point me in the right direction, it will be helpful. 

    Thanks
    Lak

  • I read the technical document - SPRAA69D- Using the TMS320C672x Bootloader and have some basic understanding of the booting process.

    We use Parallel Flash booting, Non BIOS .

    Immediately after power ON, the following happens

    1) On-chip Boot loader copies the 1KB from Flash and executes the TiSecondaryBoot (provided by TI), which will call the Secondary Boot loader (perform HW init - configure PLL etc).

    2) After HW init,  the Secondary Boot loader will parse the AIS stream and load the code/data sections into different memory (as defined in the .cmd file). 

    3) In the end, it jumps to the execution of _c_int00 (setup C environment), which will call main function & our Application execution begins

    Can you please advise if my current understanding is correct? 

    If  yes, 

    a) Can a new_App.bin be loaded into code/data space by the existing application & transfer execution to new image?

    b) or is the loading possible only by the On-chip Boot loader?, which would mean I cannot have 2 separate .bin files (one fall back golden image and a latest Application image)

    in the end, I am trying to achieve a 2 stage boot process where,  if Flash burning of latest image fails, there should be golden fall back image (which will never be updated).

    So that it will not brick the entire system on failure..

    We cannot use any alternate boot method like SPI slave or HPI due to system limitations. Please advice on the correct approach.

    Lak