• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 99 subscribers
  • Views 318 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.

Migration from RAM image to flash image on C6455

Shawn12883
Prodigy 40 points

Hi, Everyone,

We have been using C6455 DSK, CCS 3.3, and DSP/BIOS 5.33.04 to develop our application. Now we would like to boot from flash. With spra999a as a guideline, we wrote a secondary bootloader that (1) Disables L1 and L2 caches, (2) Copies our application from flash to L2, (3) Zeros out uninitialized sections in L2 and DDR, and (4) Jumps to _c_init00.

Our application runs, but only partially. Certain portions cause a system hang, which does not happen if we use CCS to load the RAM counterpart of the image directly into L2 and DDR. The effort of trying to zoom in on the hang points to DSP/BIOS.

As http://e2e.ti.com/forums/t/3883.aspx points out, we believe it is related to initialization. We would greatly appreciate if someone can send us a check list of things we need to do when we migrate from RAM image to flash image, or send us a pointer where we can find the information.

  • 0
    TI__Mastermind 24340 points

    Hi Shawn,

    The initializations needed are extremely dependent on your application, so it is not possible to make a check list. On the other hand, if your program works without a problem with CCS, then it means that all the necessary initializations are in the GEL file you are using to connect to the board. Please take a look at the GEL file and put the initializations that it makes in main.

  • 0 in reply to Mariana
    Prodigy 40 points

    Thank you so much for your prompt reply, Mariana.

    We carefully studied our .gel file, which is adapted from DSK6455.gel. We believe we have put everything into our main function, except GEL_Reset(). But based on our testing, this function can make the hang go away!

    But we do have questions: (1) This is a "built-in" GEL function. How does it work? As far as we know, there are no SW means to trigger a reset, such as setting a register bit or issuing an instruction. Please correct us if we are wrong on this one; (2) What's the impact of this function on the chip state? For example, which registers are written with what values? which cache is flushed or invalidated? which memory is initialized to 0? and so on.