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.

Program appears hung in the auto_init() function (VC5505)

Recently on a medium sized project (ie, a lot of stuff works already), a problem has recently cropped up where it seems like adding a constant anywhere in the program causes the auto_init() function to never exit; and so the software never runs.

If I remove the constant declarations, the problem disappears. Since the code that I changed does not actually get executed, it seems to be a memory issue. I'm not sure past that what could cause it.

Has anyone seen this issue before? Is it caused by a known bug?

Below is the cmd file associated with the project. Any assistance is appreciated.



-c
-stack 0x2000                   /* PRIMARY STACK SIZE               */
-sysstack 0x2000                /* SECONDARY STACK SIZE             */
-heap  0x1000                   /* HEAP AREA SIZE  */ 

/*_RTDX_interrupt_mask = ~0x06000010; */

/* Set entry point to Reset vector                                  */
/* - Allows Reset ISR to force IVPD/IVPH to point to vector table.  */
/*-e reset_isr */

MEMORY
{
    MMR     (RW) : origin = 0000000h length = 0000c0h /* MMRs */

    DARAM (RW)    : origin = 00000c0h length = 00ff40h  /* on-chip DARAM */
    SARAM   (RW)  : origin = 0030000h length = 01e000h /* on-chip SARAM */

    SAROM_0 (RX)  : origin = 0fe0000h length = 008000h     /* on-chip ROM 0 */
    SAROM_1 (RX)  : origin = 0fe8000h length = 008000h     /* on-chip ROM 1 */
    SAROM_2 (RX)  : origin = 0ff0000h length = 008000h     /* on-chip ROM 2 */
    SAROM_3 (RX)  : origin = 0ff8000h length = 008000h     /* on-chip ROM 3 */
   
}


SECTIONS
{
    vectors (NOLOAD)
    .bss        : > DARAM , fill = 0
    vector      : > DARAM      ALIGN = 256
    .stack      : > DARAM 
    .sysstack   : > DARAM 
    .sysmem     : > DARAM
    .text       : > SARAM 
    .dbuffer    : > DARAM
    .data       : > DARAM
    .cinit         : > DARAM
    .const         : > DARAM, fill = 0
    .cio        : > DARAM, fill = 0
    .usect       : > DARAM
    .switch     : > DARAM
}

 

  • It appears that changing the auto-init mode to load-time (Changing the '-c' to '-cr') fixes the problem and, so far, seems issue free.

    I'm still curious as to what caused the underlying issue, as this feels like I'm sidestepping a bug as opposed to fixing it.

  • I am having the same issue. The auto_init function of the CCS doesn't work in case you have some FAR arrays to initialize. I suggest to write your own autonitialization function which takes care of initialization. Unfortunately, that is not the only problem of the TI run time library. I had found another problem regarding the far_near functions and corrected by reassembling the module. I'm working wit CCS 3.3 and VC5502. Also, far_poke_l doesn't work as expected because it assumes even addresses only.

  • I doubt tha chaning to ROM auto initialization model solves the problem. Because then you need to write your own code that initializes the variables from the .cinit section.

    I had the same problem and saw that it occured when the initialized variables were placed in external memory  (EMIF). 

    I solved the problem by explictly placing all the initialized varibles in internal memory.