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

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');
Startup.firstFxns.$add("&myFirst");
Startup.lastFxns.$add("&myLast");

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 http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/rtsc/3_20_04_68/exports/docs/rtscpedia/Using_xdc.runtime_Startup/Using_xdc.runtime_Startup.html#Boot_Sequence_and_Control_Points for more details.