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

_c_int00 hangs

Thomas W.
Prodigy 200 points

Hello!

 

I'm currently trying to expand some old project. The tools used are CCS 2.21 (CGT 4.32) for a C6713 on a custom board.

The old project works (compiling, running via emulator and booting of the flashed version). Now with the extensions, it is no more possible to put all things into IRAM. There is lots of space in some SDRAM on the board (EMIF CE0). I've thought, that it should not be a big problem to move some stuff to SDRAM: i've already "marked" non-time-critical variables with "far". After setting the options for .far and .cinit (in the cdb - the old version of the tcf-files) to be in SDRAM (System | MEM | Properties | Compiler Sections; also tried to set the load addresses under Load Address | Specify Sepearate Load Addresses and to set the sections using a user-cmd-file ("SECTION{ .far > SDRAM ...}").

Compiling and Linking now works - the map-file also looks reasonable, but running is not possible:

Reset ([Ctrl]+[R]) works

Restart ([Ctrl]+[Shift]+[F5]) works

Go Main ([Ctrl]+[M]) fails - something might go wrong with the autoinitialization of the c-variables, but what can I do, to find out what - there is no error or warning of the linker, which should be able to locate problems.

 

I've also tried to watch the whole procedure when booting (trapped by: "zero B1; loop: [!B1] B loop"): I initiallize the EMIF-regs in my bootloader and start to copy the sections from the boottable (the values coincide with the map-file of hex6x; and some buffers tested after loading the projects symbols are correctly initialized). Finally it reaches the branch to the "entry point", but it does not reach my main anymore?

Does anyone have some hints, what I could try/do?

 

Best regards,

Thomas

 

 

  • 0
    TI__Guru**** 173310 points

    Thomas,

    Sorry about the delayed reply. Maybe you've already been able to move past this issue. Debugging such runtime issues is always difficult as the root cause could lie in many different places. I would suggest a step-by-step check of the things that changed since the working project.

    You mentioned adding some code/variables to the project and allocating far variables and .cinit to SDRAM. Can you try moving the .cinit section to internal memory to see if that works? Since the .cinit section contains the tables for initialized global and static variables, I wonder if placing it in SDRAM is causing some issues during the startup intialization of these variables. 

    After clicking "Go Main", if you halt the code where is it halted? Are you able to step through the c_int00 boot routine? if so, that might give some clues as to where the code is getting locked up.

  • 0 in reply to AartiG
    Prodigy 200 points

    Hello!

     

    I've switched to another project meanwhile, but I'm pretty sure that I'll be able to make further tests this week.

    After "Go Main" it takes a little while (on early stopping the dsp ends up in some symbol-free assembly - I can only use breakpoints/run there; stepping is not possible unfortunately - there are several branches (b <somewhere>) and I just don't see through, what's happening), but then CCS tells me that it has lost connection. Simply reconnecting doesn't help - power down the board and resetting the emulator is the least I got to do to get my connection again.

    I guess some information about the initialization data is wrong and the initialization process even messes up the code sections or something - why else would the init-proc end up in some major crash. I a little puzzeld that I'm not able to find any conflicting information in the map-files.