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.

[FAQ] Can you explain the boot sequence for TI-RTOS (SYS/BIOS) based application?

Sometimes when I run my TI-RTOS based application, I don't get to main(). Can you please explain what happens with a TI-RTOS based application before main() and how to debug the issue?

  • Standard boot for non-TI-RTOS applications

    Here is the standard boot sequence without TI-RTOS:

    When the device is released from reset, the reset vector initiates C runtime initialization at the _c_int00() entry point. One of the first steps is to initialize the system stack pointer. This same stack is used during initial booting, as well as in and after main(). 

    Once the .cinit and table of .pinit functions has been processed, the main() function is called. If there are arguments to pass to main() (depending upon the application build options), the args_main() function is used to call main(). At this point, the C runtime environment has been fully initialized, and the application can begin its intended purpose.

    Boot for TI-RTOS applications

    The kernel has several points where it adds items into the boot sequence.

    Reset Function

    The application can plug-in the “user” reset function as follows in the .cfg file.

    var Startup = xdc.useModule('xdc.runtime.Startup');
    Startup.resetFxn = "&foo";

    Note: the application must supply the reset function in their code (e.g. “foo”).

    You can look in ROV->Startup and see the user reset function.

    Note: it’s best to assume nothing has happened before your reset function is called. So no cinit, heap, etc. For some devices, the stack may not have been setup either (so no local variables).

    First and Last Startup Functions

    These are not used often, but for completeness here are examples of plugging the first and last functions in the .cfg file:

    var Startup = xdc.useModule('xdc.runtime.Startup');

    You can see the new first and last functions in ROV also. Note: you may have to hover over the fields to see the full list.

    Debugging not getting to main()

    If you are having problems getting to main here are some pointers

    • Make sure a watchdog is not resetting the device. CCS generally disables the watchdog, so you'll need to make sure it is disables when you boot without CCS.
    • Disable the "run to main" feature in CCS. This will allow you to start at _c_int00 and single step from the beginning.
    • Add a reset, first and last functions that lights an LED or toggles a GPIO to make sure you are getting to these key points. A common problem is for the bootloader to not jump to the correct entry point. So adding a reset function can help detect this.
    • Look at the ROV Startup State to see if you are getting blocked in one of the kernels module's startup (this is rare):

    Please refer to for more details.