• Locked Locked
  • Replies 3 replies
  • Subscribers 99 subscribers
  • Views 512 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.

a question of CCS Tutorial

KevinWoo
Prodigy 70 points

The section below is excerpted from Code Composer Studio 3>Help> Tutorial>DSP/BIOS>Getting Started With DSP/BIOS>Creating a DSP/BIOS Program>Things to Try:


Run the program. At the first breakpoint, use View->CPU Registers->Core Registers to see a list of register values. Notice that GIE is 0, indicating that interrupts are disabled while the main function is executing. Run to the next breakpoint. Notice that GIE is now 1, indicating that interrupts are now enabled.

But I was wondering how come,or why's that?I hope you can explain it for me.

  • TI__Guru*** 125430 points

    Here's the high level overview of traditional program flow (non BIOS-based):

    Device Reset -> c_int00 -> main (stay in "forever loop", never return)

     

    Here's the high level overview of BIOS flow

    Device Reset -> c_int00 -> BIOS_init -> main -> BIOS_start (it handles the "forever loop")

     

    In the BIOS flow, the BIOS_start function enables interrupts since it relies on interrupts to get its timer tick.

    Brad

  • in reply to Brad Griffis
    Intellectual 555 points

    What tells the compiler/linker to use BIOS_init() and BIOS_start()?  My main executes, but none of my tasks ,so I'm wondering which version of _c_int00() is getting built into my application.

  • in reply to d200guy
    TI__Guru*** 125430 points

    Are you returning from main?  Maybe I wasn't clear before that you need to return from main in order for BIOS_start to execute.

    The linker command file generated by BIOS will having something like this in it:

    -llnkrtdx.a64P
    -ldrivers.a64P         /* device drivers support */
    -lsioboth.a64P         /* supports both SIO models */
    -lbiosDM420.a64P       /* BIOS clock specific library */
    -lbios.a64P            /* DSP/BIOS support */
    -lrtdx64xplus.lib      /* RTDX support */
    -lrts64plus.lib        /* C and C++ run-time library support */

    Without BIOS the linker would pick up the c_int00 function as part of rts64plus.lib.  However, BIOS also creates its own c_int00 function which is part of bios.a64P.  The fact that bios.a64P is linked before rts64plus.lib in the BIOS-generated command file will cause the linker to resolve c_int00 to the BIOS version.

    You can verify that you have the BIOS version by looking in your map file.  For example, here's a snippet:

    .sysinit   0    10805b20    00000580    
                      10805b20    00000360     bioscfg.obj (.sysinit)
                      10805e80    000000e0     biosDM420.a64P : clk_enable64LcTimer.o64P (.sysinit)
                      10805f60    000000c0     bios.a64P : boot.o64P (.sysinit)
                      10806020    00000060               : tsk_init.o64P (.sysinit)
                      10806080    00000020               : obj_init.o64P (.sysinit)

    Finally, if you're interested in seeing that code, the boot.c file is actually bundled in source code form inside BIOS.  In the BIOS that came with CCSv4 I find it here:

    ccsv4\bios_5_41_00_06\packages\ti\bios\src\aux62\boot.c