• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 82 subscribers
  • Views 581 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.

320F28069 CCS6 Active Release Mode Debug Problem

AHMET YORUKOGLU
Prodigy 100 points

I am using CCS6 in active release mode for debugging. When we start to debug, code is locked at this point;

* PROCESS CINIT INITIALIZATION TABLE. TABLE IS IN PROGRAM MEMORY IN THE *
* FOLLOWING FORMAT: *
* *
* .word <length of init data in words> *
* .word or .long <address of variable to initialize> *
* .word <init data> *
* .word ... *
* *
* If the variable's address is greater than 65535 (located in 'far' *
* memory), then the address field of the cinit record will be 32-bits *
* instead of the default 16-bits. The length value is negated to tag *
* cinit records for those variables located in far memory. *
* *
* The init table is terminated with a zero length


However, If we are using active flash mode, there is no problem.

Is there any suggestion or comment about this problem?

 

  • 0
    TI__Expert 4595 points
    Ahmet,

    The .cinit section is an initialized linker section that contains the values for initializing RAM variables. Typically, for the FLASH build this would be located in FLASH and in the RAM build it is located in RAM (with CCS loading this initialized section).

    1. Are you getting this issue with your own code or TI example code?
    2. Have you had success with TI example code going back and forth between RAM and FLASH builds?
    3. Are you using (2) different linker command files for the FLASH and RAM builds? If so, have you compared how the .cinit section is used between the (2) builds?

    I have not seen this particular error. I expect this error occurs when you build your code prior to loading your code, or does this occur after loading the code and when ASM code executes before main()?

    Do you have a large amount of variables that require initialization? What is the size of your .cinit section (see MAP file).

    Jeff
  • 0 in reply to Jeff Stafford
    Prodigy 100 points
    Jeff,

    Thank you for your quick reply.

    1. Are you getting this issue with your own code or TI example code?
    No
    2. Have you had success with TI example code going back and forth between RAM and FLASH builds?
    Yes
    3. Are you using (2) different linker command files for the FLASH and RAM builds? If so, have you compared how the .cinit section is used between the (2) builds?
    .cinit files are the same, .cinit part is the below;
    .cinit 0 00000050 000001a0
    00000050 00000186 proj_lab12b.obj (.cinit)
    000001d6 0000000a rts2800_ml.lib : _lock.obj (.cinit)
    000001e0 0000000a : exit.obj (.cinit)
    000001ea 00000004 : errno.obj (.cinit)
    000001ee 00000002 --HOLE-- [fill = 0]
  • 0 in reply to AHMET YORUKOGLU
    TI__Expert 4595 points

    Okay Ahmet, so you are not having this issue with the TI example code.  If this is true, then this confirms that your code-generation tools installed with CCS are working fine, as configured by the TI example projects.

    Now you need to understand how your project is either configuring the code-gen tools differently or how your .cinit section is being defined with your code.  You shared the size of components of your .cinit section and I do not see any size issue and only default sections are listed.

    My suggestion is to copy a TI example project to a new directory and replace the TI files/code with your code.  Do this incrementally, building the code at each step to figure out where the issue comes in.

    Jeff

  • 0 in reply to Jeff Stafford
    Prodigy 100 points

    Jeff,

    Thank you for the suggestions, I will check.