• State TI Thinks Resolved
  • Locked Locked
  • Replies 9 replies
  • Answers 4 answers
  • Subscribers 101 subscribers
  • Views 328 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

TMS320VC5509A: TMS320vc5509a bootloader

vikas negi1
Prodigy 50 points
Part Number: TMS320VC5509A
Other Parts Discussed in Thread: TMS320VC5503

i have build my application code in ccs 3v3 and using parallel flash for system Booting using command " hex55 test.out -o test.hex -boot -v5510:2 -parallel16 -i". This command integrates my application code with the bootloader and finally the generated output i.e .hex file is written to flash using customized utility.

My question is: Can we provide seperate address for bootloader and application code. bootloader address may be default but can application address be changed.

please help.

Thanking you & regards.

  • 0
    TI__Mastermind 28788 points

    Hi,

    I'm looking into this and will get back with you early next week.

    Regards,
    Frank

  • 0 in reply to Frank Livingston
    TI__Mastermind 28788 points

    Hi,

    Please see these sections in application report "Using the TMS320VC5503/C5506/C5507/C5509/C5509A Bootloader" (spra375):

    1.1 Bootloader Features

    The bootloader reads the boot table from the external memory interface (EMIF), configured for
    asynchronous memory. The boot table contains the code or data sections to be loaded, the destination
    addresses for each of the sections, the execution address once loading is completed, and other
    configuration information.

    Section 2.3.2 Parallel EMIF-Boot Mode

    Parallel EMIF mode begins reading the boot table at word address 200000h, which is located in CE1
    space. The external memory containing the boot table must start at this location. The execution entry point
    is contained in the boot table and is programmable.

    Hence it appears the boot table (containing the application data) starts at a fixed address. The application entry point (where the application starts execution after bootload completes) is configurable via the entry point.

    Regards,
    Frank

  • 0 in reply to Frank Livingston
    Prodigy 50 points

    Thank you Frank for the reply.

    I am a bit confused. As i have my application output file say abc.out. using command hex55 test.out -o test.hex -boot -v5510:2 -parallel16 -i". i am getting abc.hex file which is a combined boot+application code. now how to write boot loader at default address 0x200000 and add address entry 0x400000 for rest of appication code. i have only one output file but 2 writing location.

    please help.

  • 0 in reply to vikas negi1
    TI__Mastermind 28788 points

    Hi,

    spra375 does a good job describing the bootload processes. Please read through it if you haven't already done so.

    The on-chip ROM bootloader reads application sections (code & data) from the boot table, and places the sections at their destination addresses. When all sections have been loaded, the bootloader jumps to the execution address (where to start the code) contained in the boot table. The boot table is created using the hex format conversion utility.

    I'm not clear why you need another bootloader in your application code. Is this a secondary boot loader (SBL), i.e. a more powerful/capable bootloader than the on-chip ROM bootloader? If so, the SBL would be the application in the boot table. The on-chip ROM bootloader would boot your SBL, and it would be up to the SBL to load your application code. The address & format of the application data in non-volatile memory is up to the SBL. In this situation I don't see a reason to combine the SBL and application data in a single .out file since then all sections for the SBL & application will be contained in the boot table and will be booted by the on-chip ROM bootloader. The SBL would serve no purpose in this case since the application would already have been loaded by the on-chip bootloader.

    Regards,
    Frank

  • 0 in reply to Frank Livingston
    Prodigy 50 points

    In my application, i have to update the new release of application code remotely using processor serial interface and GUI running on PC and not through Emulator. To connect with serial port of processor, processor should be booted up. whenever processor receives new release over serial port, it should replace the existing application code in flash memory. Any interrupt/power failure during update should not effect the booting process. And in next power ON also fresh attempt can be taken up for update. Please suggest.     

  • 0 in reply to Frank Livingston
    Prodigy 50 points

    In my application, i have to update the new release of application code remotely using processor serial interface and GUI running on PC and not through Emulator. To connect with serial port of processor, processor should be booted up. whenever processor receives new release over serial port, it should replace the existing application code in flash memory. Any interrupt/power failure during update should not effect the booting process. And in next power ON also fresh attempt can be taken up for update. Please suggest.     

  • 0 in reply to vikas negi1
    TI__Mastermind 28788 points
    vikas negi1 said:
    Any interrupt/power failure during update should not effect the booting process.

    It's not possible for a power failuire to not affect boot or run-time behavior of the device.

    vikas negi1 said:
    And in next power ON also fresh attempt can be taken up for update. Please suggest.

    I'm not clear on what you're asking. The application you boot from the ROM bootloader can consult external hardware and decide whether to switch to "firmware update" mode. This can be done for every power up. In this case, the application in "firmware update" mode will receive the new firmware over the serial port and write it to flash memory. The development of this application is up to you.

    Regards,
    Frank

  • 0 in reply to Frank Livingston
    Prodigy 50 points

    Any interrupt/power failure during update should not effect the booting process.

    With this i meant that if power failure occur, new release will not be written on ROM but in next power cycle processor should boot from the previous release. and a fresh attempt for the new release can be taken up. 

    My only concern is that whenever new release is written in ROM and is say half written then if any power failure happens, then in next cycle half written flash will neither allow booting from old nor from new release. In this situation, new release updation won't be possible.

    How to resolve this kind of issue. Please suggest if any alternate is available.

  • 0 in reply to vikas negi1
    TI__Mastermind 28788 points

    I don't see a general solution to this problem. It seems like there should be a successful boot feedback (like a GPIO) from your application which can be checked, and the boot table can be reflashed if the feedback isn't observed.