How to change debug start address?

Annie,

When you launch the debug configuration and connect to the Cortex A8 and C674x, you have not yet loaded any program or symbols. So it is simply telling you that the Program Counter (PC) is pointing to address 0x00800000 and there is no source code loaded that corresponds to that address. I believe this address is in the boot space for C6748. You can open the disassembly window and confirm that is where the PC is. When you load your program by going to Run->Load->Load Program then the PC should be at the entry point for your program ( or halted at main - depending on your debugger settings) and the corresponding source code should also be visible.

AartiG,

Thanks for your reply. I should have added more details yesterday.

Loading the code causes it to start running straight away.

Under my Debug Configurations I have the following setting:

  Auto Run Options: Run to symbol "main"  On a program load or restart.

If I add a breakpoint in my main() function the breakpoint is not hit.

If I pause the program I see a trace showing many sysbios and xdc routines but none of my code.

When I had a small program and was loading it into internal memory (0x00800000) then the debugger would jump to main() but now that I'm loading my code into external memory (0x80000000) the debugger doesn't seem to find main(). Is there a restriction on where the .text section can be placed?

Thanks,
Annie

Annie,

Problems with code not reaching main could be due to many reasons and can be hard to troubleshoot.  Some of the reasons for such issues are hardware not properly configured, initialization hangs at some point or the initialization code has problems. In your case, since you mention changing the load address from internal to external memory, you may want to look closely at whether any initialization needs to be done for external memory and if that is getting done properly. Also check that you are using correct GEL files/DIP switch settings etc. as applicable.

Here is a related thread that might have some additional posts ideas for troubleshooting: http://e2e.ti.com/support/development_tools/code_composer_studio/f/81/t/136216.aspx

Hope this helps.

AartiG,

Thanks for your reply and the link which also contained several links.

I went back to a very simple project and changed its memory map and found that the debugger correctly jumped to main() which was at address 0x800013e0. So the memory is present and correctly configured. I also found out how to make the debugger jump to c_int00 instead of main and found the xdc source file boot.c which is needed. With similar debug settings I see that for my big project the debugger is jumping to c_int00 correctly which is at address 0x80064a40. It is doing some extra steps after c_int00 which the simple program doesn't do and I'll track down where it is getting stuck. I'll update this post when I find the issue.

Annie.

Stepping through with the debugger shows that it gets stuck in this while loop:

#else
    curStack = (UArg)(&curStack);

    while (curStack-- > (UArg)STACK_BASE) {
        *((UInt8 *)curStack) = 0xbe;
    }
#endif

in ti_sysbios_hal_Hwi_initStack() in bios_6_32_05_54\packages\ti\sysbios\hal\Hwi_stack.c. The value of curStack is huge. If I reset that value with the debugger to a value such as 1000 then step into the loop again, it gets set to a huge value once more.

This indicates a problem with the stack size, I assume? The generated Debug\configPkt\linker.cmd file has this in it:

/* Elf symbols */
--symbol_map ___TI_STACK_BASE=__stack
--symbol_map ___TI_STACK_SIZE=__STACK_SIZE
--symbol_map ___TI_STATIC_BASE=___bss__
--symbol_map __c_int00=_c_int00

--args 0x0
-heap  0x0
-stack 0x1000

MEMORY
{
    IRAM (RWX) : org = 0x10800000, len = 0x40000
    OCMC_0 (RWX) : org = 0x40300000, len = 0x40000
    OCMC_1 (RWX) : org = 0x40400000, len = 0x40000
    DDR3_RAM (RWX) : org = 0x80000000, len = 0x10000000
}

Are there other stack settings I should check? I have my own .cmd file but it does not change anything related to the stack.

The .map file shows this:

.stack     0    800ce840    00001000     UNINITIALIZED
                  800ce840    00000008     boot.a674 : boot.o674 (.stack)
                  800ce848    00000ff8     --HOLE--

Thanks,
Annie

There is no problem with the stack. Although the debugger disappeared (no single-step option was offered any more) when it went into the stack initialization function, this was misleading. I spent some time looking at what was going on in that code and eventually found that the debugger could get out of that loop and proceed.

I tried another approach and have now found that if I leave the debugger to run it consistently gets stuck in a sysbios function called deviceConfig() which is in a Timer.c file.

From bios_6_32_05_54\packages\ti\sysbios\timers\dmtimer\Timer.c, deviceConfig():

 /* if doing SOFTRESET: do it first before setting other flags */

    if (obj->tiocpCfg & TIMER_TIOCP_CFG_SOFTRESET_FLAG) {

        timer->tiocpCfg = TIMER_TIOCP_CFG_SOFTRESET_FLAG;

        while (timer->tiocpCfg & TIMER_TIOCP_CFG_SOFTRESET_FLAG)

                ;

    }

The while loop never ends (timer->tiocpCfg is always 0).

I did some searching on the forums. I found one entry which looked relevant.

I added a temporary change to the .cfg file based on advice in this thread (temporary workaround to fix simulation issue):

http://e2e.ti.com/support/embedded/bios/f/355/t/135119.aspx#485813

With the temporary change, the debugger successfully jumps to main() in my big project for the first time (after changing debug config settings to tell it to run to main instead of c_int00).

Without the temporary change the debugger consistently gets lost and it is stuck in the while loop above

The temporary change (commented out in the version below):

/* TEMP!!!!!!!!!!!!!!!!!!!

*

var Clock = xdc.useModule('ti.sysbios.knl.Clock');

Clock.tickSource = Clock.TickSource_NULL;

* TEMP END!!!!!!!!!!!!!!!!!!!

*/

Something to do with the timer setup in my project is the culprit now. 

Any ideas would be very welcome.
Annie

Annie,

Glad to hear you've made further progress in narrowing down the issue and have been able to find a workaround. At this point, I would suggest posting this to the BIOS forum as the experts there would be able to help better on moving forward with this. You can start a new thread and reference this for background information.