Problems reaching main function and if statements condition checking failing

Jorge Justiniano said:

When building and loading the software the debugger does not stop at main and remains in an infinite loop within the boot28.inc.

Is this with one of your own projects or one of the TI examples? As you may be aware, TI has many peripheral example projects that generally most people use as a starting point to develop their own code. Have you tried one of the examples to see if that works well?

Jorge Justiniano said:

When debugging I have come across several if statements were the condition is not met but the code is entering the if statement.

It sounds like the behavior you are observing is similar to the issue discussed in these threads.
http://e2e.ti.com/support/development_tools/compiler/f/343/p/69946/253629.aspx#253629
http://e2e.ti.com/support/development_tools/code_composer_studio/f/81/p/3431/12177.aspx#12177

Although from a debug perspective it may look like you are executing code within the "if" statement, the outcome of the instruction may be dependent on a condition. Try setting a variable for instance within the "if" condition and confirm if it is really getting updated or not. 

This is one of my own projects. I started with TI examples and started to build up from there. I extracted the boot files from the rtssrc.zip file and added them to my project with the right linker order. I've tried to put a breakpoint in the asm code to see what's going on in the initialization table routine and see why is it remaining there but CC does not let place the breakpoint at the beginning of the routine. I was able to get to the main and run the debugger by selecting the -ram_model option in the linker settings but not quite sure the effects that this may have on my code.

The difference between --ram_model and --rom_model is that initialization of variables is done at load time (by the loader, in this case CCS) for ram_model, while it is done at runtime (for rom_model). It almost sounds like the watchdog timer is not getting disabled and may be getting triggered in the boot routine during auto initialization. I would double check to make sure that the watchdog is indeed being disabled and prior to the jump to _c_int00 in the boot code. The TI examples are all set up to do this.

I'm using TI's DSP281x_CodeStartBranch.asm which should be disabling the Watchdog. Shouldn't this be enough?

***********************************************************************

WD_DISABLE

.set 1 ;set to 1 to disable WD, else set to 0

.ref _c_int00

***********************************************************************

* Function: codestart section

*

* Description: Branch to code starting point

***********************************************************************

.sect "codestart"

code_start:

.if WD_DISABLE == 1

LB wd_disable ;Branch to watchdog disable code

.else

LB _c_int00 ;Branch to start of boot.asm in RTS library

.endif

;end codestart section

***********************************************************************

* Function: wd_disable

*

* Description: Disables the watchdog timer

***********************************************************************
.if WD_DISABLE == 1

.text

wd_disable:

SETC OBJMODE ;Set OBJMODE for 28x object code

EALLOW ;Enable EALLOW protected register access

MOVZ DP, #7029h>>6 ;Set data page for WDCR register

MOV @7029h, #0068h ;Set WDDIS bit in WDCR to disable WD

EDIS ;Disable EALLOW protected register access

LB _c_int00 ;Branch to start of boot.asm in RTS library

.endif

;end wd_disable

That looks like it should be enough. You mentioned extracting the boot files from the runtime library sources and adding them directly to your project. Is there a specific reason you are doing this? Are you customizing the boot routine?  Can you try your project by linking in the default runtime library?

You could also ry viewing the WDCR in the CCS register view to check/verify if watchdog is being disabled and then when stepping through the boot code see if it is getting enabled at some point.