• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 52 subscribers
  • Views 856 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.

Initialization questions

Anonymous
Anonymous


Hi All,

 

I would like to ask some questions on GEL files and related initialization issues.

                      

                    

I have noticed that when in debugging mode there is a "Reset" button, which provide three types of reset:

  1. CPU Reset
  2. System Reset
  3. Emulator

A natural question is that: How can CCS properly "reset" the system? By properly, I mean that in addition to reset a CPU, all devices and peripherals on the EVM board needs to be re-initialized. CCS won't know of course, since there are many different EVM providers for TI chips, what devices are placed on a particular EVM, what are their memory mapped address (which part of the whole memory mapped address space is used, which part are not), and how to set the registers on them.

Therefore, if CCS needs to perform a "meaningful" reset in the forgoing regard, information on the details of these clear-and-reinitialization steps (and addresses, waiting time, etc., which can all be found in a typical .GEL file) must be provided to it. Is this the purpose for the creation of .GEL files?


Another question is on EVM board. In a snap of time after power on, it will be able to work and compiled instructions can be downloaded to the board via the emulator. But just as we have discussed previously, in order to properly initialize the whole board with a host of devices and peripherals connected to the DSP chip, information on their configurations must be given. Do we require .GEL file here?

What I have actually found is that even without a .GEL file in the directory the EVM would still be able to work. However, most examples provided with the EVM has in its main() function a call to a specific initialization function:

Initialization in the main() function said:

    /* Initialize BSL */
    EVMDM6437_init( );

Does this EVMDM6437_init( ) do all the initialization? What is the relationship between

  1. EVMDM6437_init( )
  2. BSL
  3. .GEL file

?

                  

             

And since the DSP chip has its internal ROM,

  1. In developing tool such as EVM, is ROM used to store any initialization information?
  2. In real product, it should be that ROM can be used to store all data and executable code, and only when there is not enough space within the ROM are additional storage module such as Flash needed. Since the electronic device (chip and all other components and electronic elements connected with it) must be initialized, initialization code must be present, and will be stored in either the ROM or other storage devices.
    But what is the role of boot ROM here? Is it possible for all code, including initialization part, to be stored entirely in an external storage? How could the CPU know the address of these code? Therefore, I think in case we do wish to put most of the code on an external storage rather than the ROM, at least the starting memory-mapped address of the initialization code needs to be stored in the ROM, which would inform the CPU on where to fetch the initialization code sequence. Therefore, visiting ROM by CPU is always the first (in the most literal sense) step in initialization, regardless of where the majority of initialization code are actually stored. Is this correct?


Could anyone explain these details to me?

                  

                           
Sincerely,
Zheng

  • 0
    TI__Guru**** 474561 points

    Zheng Zhao said:

    I have noticed that when in debugging mode there is a "Reset" button, which provide three types of reset:

    1. CPU Reset
    2. System Reset
    3. Emulator

    A natural question is that: How can CCS properly "reset" the system? By properly, I mean that in addition to reset a CPU, all devices and peripherals on the EVM board needs to be re-initialized. CCS won't know of course, since there are many different EVM providers for TI chips, what devices are placed on a particular EVM, what are their memory mapped address (which part of the whole memory mapped address space is used, which part are not), and how to set the registers on them.

    Therefore, if CCS needs to perform a "meaningful" reset in the forgoing regard, information on the details of these clear-and-reinitialization steps (and addresses, waiting time, etc., which can all be found in a typical .GEL file) must be provided to it. Is this the purpose for the creation of .GEL files?


    Another question is on EVM board. In a snap of time after power on, it will be able to work and compiled instructions can be downloaded to the board via the emulator. But just as we have discussed previously, in order to properly initialize the whole board with a host of devices and peripherals connected to the DSP chip, information on their configurations must be given. Do we require .GEL file here?

    A CPU Reset would reset the CPU only. A System Reset (I believe) would reset the CPU and other on-chip peripherals. Things external initialization of external memory or PLLs would not be done. As you mentioned, GEL can be used to initialize these peripherals. I would agree that one of the main uses of the startup GEL files is for such initialization. There is a GEL callback function called 'OnReset()' that gets automatically called when a CPU or system reset is done. You can add any other initialization you'd like to have happen when you do a reset.

    Zheng Zhao said:

    What I have actually found is that even without a .GEL file in the directory the EVM would still be able to work. However, most examples provided with the EVM has in its main() function a call to a specific initialization function:


        /* Initialize BSL */
        EVMDM6437_init( );

    Does this EVMDM6437_init( ) do all the initialization? What is the relationship between

    1. EVMDM6437_init( )
    2. BSL
    3. .GEL file

    ?

    [/quote]

    Of course, initializing external memory, clocks, etc can also be done in your code instead of using GEL. I assume that is what EVMDM6437_init( ) does when it is called from main. That function most likely replaces what you might do with GEL. The reason why you'd want it in your code is in case you want to run your code outside of CCS (from ROM) so there would be no startup GEL file that can execute and do that initialization.

    BSL = Board Support Library. BSL provides some APIs used to use board peripherals (initialization, usage, etc). Similar to how CSL is at the device level.

    I would recommend reading this app note. It discusses how to use GEL for target initialization and goes into more details on some of the information I mentioned:.

    Zheng Zhao said:

    And since the DSP chip has its internal ROM,

     Your next questions on proper usage of  internal ROM is a bit beyond the scope of this tools forum. You may want to post in the C6000 forum where there is more expertise.

    Thanks

    ki

  • Anonymous
    0 Anonymous in reply to Ki

    Dear Ki-Soo,

                        

    3.5   OnReset() Function said:

    This callback function is called after the target processor has been reset.

    1. It says here "after processor" has been reset
    2. You said "'OnReset()' that gets automatically called when a CPU or system reset is done".

    These two expressions are consistent just because "system reset" include "CPU reset", so if when "CPU reset" OnReset() will be called, when "System reset" OnReset() will also be called because of the triggering by the included CPU reset action. Is this correct?

                                

                

    Ki-Soo Lee said:

    BSL = Board Support Library. BSL provides some APIs used to use board peripherals (initialization, usage, etc). Similar to how CSL is at the device level.

    After all, are they essentially just drivers? Drivers that can be directly used without an OS as in contrast with our familiar "drivers" (Nvidia GeForce 7800, Creative sound card, etc.) used by common Operating Systems? Because although the communication and configuration between the CPU and many on-board or in-chip devices can be accomplished by memory mapped register read/write, there are many cases that are different from this. For example, I2C has only two wires connecting the chip and a number of (can be many) peripherals and the communication cannot be done in the way of ordinary register read/write, so for this reason CSL provides I2C module to handle this sophistication?


    Now I have realized the importance of CSL and BSL in development. But ARM chips (ARM alone, NOT OMAP), do we have both? I am asking this because I have noticed that these BSL and CSL APIs seems to be particularly built to suit the common DSP environment that runs without an operating system, and that function routines can be directly called from the library. For ARM chips that is typically (I heard) used with Linux, which is a full-fledged operating system,

    1. Does TI still provide BSL and CSL?
    2. What are BSL and CSL's counterpart in Linux?

     

     

    Sincerely,
    Zheng