• State TI Thinks Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 82 subscribers
  • Views 1386 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.

Original question:

Setting a entry point in CCS4.1 assembly source file

CCS/TMS320F28062: Setting a entry point in assembly source file

Olovskos
Intellectual 420 points
Part Number: TMS320F28062


Tool/software: Code Composer Studio

Hello again,

I have a problem again with my custom bootloader that sits in FLashA. At the moment I just do a LongBranch to my main application when the bootloader finishes but that means, that I don`t deallocate the stack etc. so I try to use the .Init_boot section from the f28069_flash_kernel example. 

What do I have to do to make my bootloader always start at .Init_Boot? Right now I have set the --entry_point in CCS to _Init_Boot. This is working when I debug from within CCS. But when I reset the F28062 the Bootloader does not run...

.Init_Boot also resists in FlashA.

So the question is, if I set the entry point in Code Composer Studio and build my project and generate the ASCII hex file with the hex Utility, is the entry point also compiled into the Output File?

If not, how do I modify the .cmd file to always jump to the .Init_Boot? I tried to set .InitBoot to BEGIN but this was completely ignored by CCS....

Thanks

  • 0
    TI__Mastermind 30255 points
    Hello

    When you generate the ASCII hex file, you can use the command argument --entrypoint to specify the entrypoint that will be extracted from your bootloader and then be branched to at the end of the execution.

    Also refer to the TRM to be familiar with the difference in boot up behavior when JTAG is connected vs when it's not.

    Best regards
    Chris
  • 0 in reply to Christopher Chiarella
    Intellectual 420 points
    Ok, then it must be something different...
    I will try to explain the behavior of the Upgrade.
    1. The Flash and RAM is locked with the CSM so before I do a Firmware upgrade, I download a Flash eraser to the unsecured RAM to erase Flash A to unlock all Areas.
    2. Then I download a custom RAM Bootloader that is capable of downloading a static custom Bootloader that sits in FlashA.
    3. With this Bootloader I am able to do a Firmwareupgrade.

    The Steps 1. and 2. are only done if I need to change the static Bootloader.

    If I do all the steps above, the static bootloader is able to jump to the Firmware when it finished the flash routine and the Firmware is running. So my generated Output Files seem to be correc in some way.

    But if I power off the device and turn it back on, the static bootloader does not jump to the main Firmware.

    So to put everything together: When I upload a fresh static Bootloader to FlashA, the .InitBoot is executed fine and the jump to the main app works. If I disconnect Vcc and connect it again, the bootloader is not able to jump to the main app anymore.
  • 0 in reply to Olovskos
    Intellectual 420 points
    The question is, do I really have to de-initialize the stack etc? When a new program starts, the codestart section initializes the stack so there is no need for de-initialization right?
  • 0 in reply to Olovskos
    TI__Mastermind 30255 points
    Hello

    Yes, calling into code_start will then call _c_init00 which does that stack initialization and eventually calls the main().
    When it can't jump to main anymore, what behavior are you seeing? Are you able to trace what address it's going to? Is it getting to the bootloader at all?

    Best regards
    Chris
  • 0 in reply to Christopher Chiarella
    Intellectual 420 points
    Yes the bootloader is booting, I can See the different stages via LEDs. It is not easy to debug because if i use the Debugger, it is working. If I Do all the steps I explained before (unlock and erase the Flash, load a bootloader to the RAM that is capable of burning a static bootloader to Flash A, and finally use the bootloader that is in Flash A to load the Main App) it is working and the Bootloader in Flash A jumps to the Main application. But when I unplug the device and apply Vcc again, the bootloader does not jump to the Main App.
    In this "non-working" Version, I use the. Initboot section like in the "f28069_flash_kernel" example. In this Version I can return the address (where I want to jump afterwards) from the Main and the Exitboot will handle the rest.
    I have a Version that is working, where i Do a simple "longbranch" to the address where the Main App starts. This works every time and I have nö Problems. But I thought, there must be a reason why TI does all this Stack de-init stuff in their bootloader.

    BUT if you Tell me, that it is absolutely finde to Do a manual jump to the Main App because _c_init will Do the re-init anyways, I will use this working solution.

    Thank you for your help
  • 0 in reply to Olovskos
    TI__Mastermind 30255 points
    Hello

    Exitboot shouldn't be causing your application not to start. Although you are fine to skip exitboot and branch to your main app (which should be the address of c_init), the fact something is going wrong here is concerning. I suggest putting a blocking call (infinite loop) in your "non-working" case right after it enters exitboot and then you can connect with JTAG (edit your target configuration file under the advanced tab, remove the reference to the GEL file). Without GEL, you won't alter anything about the state of the device and you can further debug what is going on there.

    Best regards
    Chris