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.

RTOS/AM3359: CCS debug issue

Part Number: AM3359
Other Parts Discussed in Thread: TMDSICE3359, SYSBIOS,

Tool/software: TI-RTOS

EVM HW:  TMDSICE3359

Host Env:  Windows

BIOS Version:  6.53.2.00

XDCTOOLS:  3.50.03.33

CCS Version:  7.2

As instructed in the SysBIOS User's Guide, I navigated to TI Resource Explorer-->SYS/BIOS-->AM33x - Cortex A8 --> ICE_AM3359 -->Cortex A --> GNU Target Examples --> Generic Examples and Imported the "Static Example" project and the "Swi Example" Project.  Both projects build with no Errors but both produce the following Warning:

Description Resource Path Location Type
Invalid project path: Include path not found (C:\Users\celyj\Embedded\ICE_am335x\static_ICE_AM3359_CortexA\.config\xconfig_static\Debug\C::\ti\bios_6_53_02_00\packages\gnu\targets\arm\libs\install-native\arm-none-eabi\include\newlib-nano). static_ICE_AM3359_CortexA  pathentry Path Entry Problem

After the project is built, it is programmed into the Hardware target using the Debugger.  As with both projects, when the debugger starts, both enter at main() as expected.  In both projects, there is some initialization before the BIOS_start() operation.  This initialization code appears to be working correctly in both projects.  (i.e. I have been able to set a breakpoint before BIOS_start() and hit the breakpoint consistently).  When the program is Resumed and steps into BIOS_start(), this is where I think I'm having issues.

The program will immediately go into Suspend and open the file C:\ti\bios_6_53_02_00\packages\gnu\targets\arm\rtsv7A\syscalls.c  The point that the program Suspends is at the very bottom of the code snippet shown below.  It actually Suspends on the line with the closing "  */ ".  I can select the Resume button but the program(s) land on this same location in Suspend Mode.

/*

* ======== syscalls.c ========

* Minimal implementation of newlib syscall stub functions.

*

*/

/*

* ======== _exit ========

*/

void _exit(int code)

{

asm(" .global C$$EXIT");

asm("C$$EXIT:");

while(1){};

}

/*

* @(#) gnu.targets.arm.rtsv7A; 1, 0, 0,0; 11-8-2017 17:59:48; /db/ztree/library/trees/xdctargets/xdctargets-p04/src/ xlibrary

*/  ***HERE IS THE SUSPEND POINT***

  • Hi Joe,

    Something looks fishy with that warning. Can you do a clean of one of the projects and then build? Please copy/paste the entire build output into a file and attach that file. I want to make sure the env. is correct.

    btw: please make sure there no spaces in any of the directories, Additionally make sure there are no other shells in your path (e.g. MKS or cygwin).

    Todd

  • Hi Todd,

    I cleaned and rebuilt the swi_ICE_AM3359_CortexA project.  The attached file is the build log.  I was playing around with this project yesterday and have more to report on this error.

    The problem actually occurs anytime this program is Restarted, CPU Reset(SW), CPU Reset(HW) or System Reset is executed.  If I rebuild and select "Resume", I can see where it enters the different tasks and swis properly.  If I try one of the Reset/Restart operations, the program hangs in the syscall routine.  Also after the program runs, it calls the routine BIOS_exit().  Once this routine is called the program enters the syscall routine as well.

    I haven't changed the Boot process on my ICE board so it still boot from the SPI flash.  I believe if we could figure out how to properly RESET the board while in debugger, this problem would be resolved.

    Thanks,

    JC

    P.S.  One helpful thing that could be added in this example and some of the others is some information about using the System_printf() operation.  I personally was expecting to see messages on the CCS console.  I just happened to set a breakpoint in a swi and found that the program actually hits the breakpoint correctly when the debugger first starts.  After some digging I figured out how to use the System_printf() operation. 

  • **** Build of configuration Debug for project swi_ICE_AM3359_CortexA ****
    
    "C:\\ti\\ccsv7\\utils\\bin\\gmake" -k -j 8 all -O 
    gmake[1]: Entering directory 'C:/Users/celyj/Embedded/ICE_am335x/swi_ICE_AM3359_CortexA/Debug'
    'Building file: ../swi.cfg'
    'Invoking: XDCtools'
    "C:/ti/xdctools_3_50_03_33_core/xs" --xdcpath="C:/ti/bios_6_53_02_00/packages;C:/ti/pdk_am335x_1_0_9/packages;C:/ti/ccsv7/ccs_base;" xdc.tools.configuro -o configPkg -t gnu.targets.arm.A8F -p ti.platforms.evmAM3359 -r release -c "C:/ti/gcc-arm-none-eabi-6-2017-q1-update" "../swi.cfg"
    making package.mak (because of package.bld) ...
    generating interfaces for package configPkg (because package/package.xdc.inc is older than package.xdc) ...
    configuring swi.xa8fg from package/cfg/swi_pa8fg.cfg ...
    generating custom ti.sysbios library makefile ... 
    Starting build of library sources ...
    making C:/Users/celyj/Embedded/ICE_am335x/swi_ICE_AM3359_CortexA/src/sysbios/sysbios.aa8fg ...
    gmake[1]: Entering directory `C:/Users/celyj/Embedded/ICE_am335x/swi_ICE_AM3359_CortexA/src/sysbios'
    asma8fg C:/ti/bios_6_53_02_00/packages/ti/sysbios/family/arm/IntrinsicsSupport_asm_gnu.asm ...
    asma8fg C:/ti/bios_6_53_02_00/packages/ti/sysbios/family/arm/TaskSupport_asm_gnu.asm ...
    asma8fg C:/ti/bios_6_53_02_00/packages/ti/sysbios/family/arm/a8/intcps/Hwi_asm_gnu.sv7A ...
    asma8fg C:/ti/bios_6_53_02_00/packages/ti/sysbios/family/arm/exc/Exception_asm_gnu.asm ...
    asma8fg C:/ti/bios_6_53_02_00/packages/ti/sysbios/family/arm/a8/Cache_asm_gnu.sv7A ...
    asma8fg C:/ti/bios_6_53_02_00/packages/ti/sysbios/family/arm/a8/Mmu_asm_gnu.sv7A ...
    asma8fg C:/ti/bios_6_53_02_00/packages/ti/sysbios/family/arm/a8/TimestampProvider_asm_gnu.sv7A ...
    asma8fg C:/ti/bios_6_53_02_00/packages/ti/sysbios/timers/dmtimer/Timer_asm_gnu.sv7A ...
    cla8fg C:/ti/bios_6_53_02_00/packages/ti/sysbios/BIOS.c ...
    cla8fg C:/ti/bios_6_53_02_00/packages/ti/sysbios/family/arm/IntrinsicsSupport.c ...
    cla8fg C:/ti/bios_6_53_02_00/packages/ti/sysbios/family/arm/TaskSupport.c ...
    cla8fg C:/ti/bios_6_53_02_00/packages/ti/sysbios/knl/Clock.c ...
    cla8fg C:/ti/bios_6_53_02_00/packages/ti/sysbios/knl/Idle.c ...
    cla8fg C:/ti/bios_6_53_02_00/packages/ti/sysbios/knl/Intrinsics.c ...
    cla8fg C:/ti/bios_6_53_02_00/packages/ti/sysbios/knl/Queue.c ...
    cla8fg C:/ti/bios_6_53_02_00/packages/ti/sysbios/knl/Semaphore.c ...
    cla8fg C:/ti/bios_6_53_02_00/packages/ti/sysbios/knl/Swi.c ...
    cla8fg C:/ti/bios_6_53_02_00/packages/ti/sysbios/knl/Task.c ...
    cla8fg C:/ti/bios_6_53_02_00/packages/ti/sysbios/hal/Cache.c ...
    cla8fg C:/ti/bios_6_53_02_00/packages/ti/sysbios/hal/Core.c ...
    cla8fg C:/ti/bios_6_53_02_00/packages/ti/sysbios/hal/CoreNull.c ...
    cla8fg C:/ti/bios_6_53_02_00/packages/ti/sysbios/hal/Hwi.c ...
    cla8fg C:/ti/bios_6_53_02_00/packages/ti/sysbios/hal/Hwi_stack.c ...
    cla8fg C:/ti/bios_6_53_02_00/packages/ti/sysbios/hal/Hwi_startup.c ...
    cla8fg C:/ti/bios_6_53_02_00/packages/ti/sysbios/family/arm/a8/intcps/Hwi.c ...
    cla8fg C:/ti/bios_6_53_02_00/packages/ti/sysbios/family/arm/exc/Exception.c ...
    cla8fg C:/ti/bios_6_53_02_00/packages/ti/sysbios/family/arm/a8/Cache.c ...
    cla8fg C:/ti/bios_6_53_02_00/packages/ti/sysbios/family/arm/a8/Mmu.c ...
    cla8fg C:/ti/bios_6_53_02_00/packages/ti/sysbios/family/arm/a8/TimestampProvider.c ...
    cla8fg C:/ti/bios_6_53_02_00/packages/ti/sysbios/rts/gnu/ReentSupport.c ...
    cla8fg C:/ti/bios_6_53_02_00/packages/ti/sysbios/gates/GateHwi.c ...
    cla8fg C:/ti/bios_6_53_02_00/packages/ti/sysbios/gates/GateMutex.c ...
    cla8fg C:/ti/bios_6_53_02_00/packages/ti/sysbios/heaps/HeapMem.c ...
    cla8fg C:/ti/bios_6_53_02_00/packages/ti/sysbios/timers/dmtimer/Timer.c ...
    cla8fg C:/ti/bios_6_53_02_00/packages/ti/sysbios/family/arm/a8/ti81xx/TimerSupport.c ...
    ara8fg arm_IntrinsicsSupport_asm_gnu.o arm_TaskSupport_asm_gnu.o intcps_Hwi_asm_gnu.o exc_Exception_asm_gnu.o a8_Cache_asm_gnu.o a8_Mmu_asm_gnu.o a8_TimestampProvider_asm_gnu.o dmtimer_Timer_asm_gnu.o _BIOS.o arm_IntrinsicsSupport.o arm_TaskSupport.o knl_Clock.o knl_Idle.o knl_Intrinsics.o knl_Queue.o knl_Semaphore.o knl_Swi.o knl_Task.o hal_Cache.o hal_Core.o hal_CoreNull.o hal_Hwi.o hal_Hwi_stack.o hal_Hwi_startup.o intcps_Hwi.o exc_Exception.o a8_Cache.o a8_Mmu.o a8_TimestampProvider.o gnu_ReentSupport.o gates_GateHwi.o gates_GateMutex.o heaps_HeapMem.o dmtimer_Timer.o ti81xx_TimerSupport.o ...
    gmake[1]: Leaving directory `C:/Users/celyj/Embedded/ICE_am335x/swi_ICE_AM3359_CortexA/src/sysbios'
    Build of libraries done.
    cla8fg package/cfg/swi_pa8fg.c ...
    'Finished building: ../swi.cfg'
    ' '
    gmake[1]: Leaving directory 'C:/Users/celyj/Embedded/ICE_am335x/swi_ICE_AM3359_CortexA/Debug'
            1 file(s) copied.
    making ../src/sysbios/sysbios.aa8fg ...
    gmake[1]: Nothing to be done for 'all'.
    'Building file: ../swi.c'
    'Invoking: GNU Compiler'
    "C:/ti/gcc-arm-none-eabi-6-2017-q1-update/bin/arm-none-eabi-gcc.exe" -c -mcpu=cortex-a8 -mtune=cortex-a8 -march=armv7-a -marm -mfloat-abi=hard -Dam3359 -I"C:/Users/celyj/Embedded/ICE_am335x/static_ICE_AM3359_CortexA/.config/xconfig_static" -I"C:/ti/xdctools_3_50_03_33_core/packages" -I"C:/Users/celyj/Embedded/ICE_am335x/swi_ICE_AM3359_CortexA" -I"C:/ti/bios_6_53_02_00/packages/gnu/targets/arm/libs/install-native/arm-none-eabi/include/newlib-nano" -I"C:/ti/gcc-arm-none-eabi-6-2017-q1-update/arm-none-eabi/include" -g -gdwarf-3 -gstrict-dwarf -Wall -MMD -MP -MF"swi.d" -MT"swi.o" -o"swi.o" @"configPkg/compiler.opt" "../swi.c"
    'Finished building: ../swi.c'
    ' '
    making ../src/sysbios/sysbios.aa8fg ...
    gmake[2]: Nothing to be done for 'all'.
    'Building target: swi_ICE_AM3359_CortexA.out'
    'Invoking: GNU Linker'
    "C:/ti/gcc-arm-none-eabi-6-2017-q1-update/bin/arm-none-eabi-gcc.exe" -mtune=cortex-a8 -marm -Dam3359 -g -gdwarf-3 -gstrict-dwarf -Wall -mfloat-abi=hard -Wl,-Map,"swi_ICE_AM3359_CortexA.map" -nostartfiles -static -Wl,--gc-sections -L"C:/ti/bios_6_53_02_00/packages/gnu/targets/arm/libs/install-native/arm-none-eabi/lib/hard" -Wl,--defsym,STACKSIZE=0x1C000 -Wl,--defsym,HEAPSIZE=0x400 --specs=nano.specs -o"swi_ICE_AM3359_CortexA.out" "./swi.o" -Wl,-T"configPkg/linker.cmd" -Wl,--start-group -lgcc -lm -lnosys -lc -Wl,--end-group 
    'Finished building target: swi_ICE_AM3359_CortexA.out'
    ' '
    
    **** Build Finished ****
    
    Build Log.

  • Hi Todd,

    Any updates on this task?

    Thanks.

  • Hi Joe,

    Sorry for the delay.

    There are no build warnings in the build log file. How did you get rid of the warning? Did you try running this image afterwards?

    Todd
  • Hi Todd,

    I'm really not sure what happened to the warnings.  I did however get this project running, somewhat.  I think I have boiled the problem down to one specific action.  Reset.  Take a look at my post on April, 12th.  I have more information from that post.

    Thanks for your help,

  • Resets are tricky. There is a system reset and chip reset in CCS. What each does depends on the chip and the gel files (and for multi-core devices, the startup order). I generally play around with it until I get a solid procedure. I know, not the highest tech and I probably should ping the device teams (I'm in TI-RTOS, so we work with lots of devices), but sometimes it's just faster/easier to experiment a bit.

    Can you mark this as resolved or let me you want it moved to the device team for a concrete answer on the CCS reset.

    Todd

  • Hi Todd,

    That would be great if you could forward this to the Device Team.  Do I need to wait until you move the issue over before marking this as Resolved?

    Thanks,

    Joe

  • They have been notified, let's hold off on the Resolved until we hear from them.
  • I'd like to go ahead and get this resolved as it is causing me development delays. Thanks again for your help Todd.
  • Joe,

    I was trying to come up to speed on the thread. So, you are looking for clarification on the various CCS reset mechanisms as dicussed here?
    e2e.ti.com/.../399484

    Lali
  • Hi Lali,

    No I understand the differences between the different RESETs. What I'm asking is why don't these project behave properly when at least one of the 3 types of RESETs are applied and how can I fix them. 

    As it stands, both the projects referenced in this thread run and are halted somewhere in the syscall.c file.  The only way I can re-run these examples is to Stop the Debugger and then re-enter..

    JC

  • JC,

    I was asked to comment on this thread.

    Unfortunately I don't have the same board as you to try and run the same example code, but as general statements:

    Any time a reset is issued on the core or device, it will bring most or all internal registers to their reset values. If the code you are running expects a GEL file to perform some pre-initialization (EMIF, PLL, ec.), you will have to run it again before re-loading your code. Usually the menu Run --> Scripts has a default system initialization routine.

    The closest scenario for a complete reset is simply externally reset the core processor (usually the boards have a reset button). In order to do this without throwing an error message (as the Debug Probe will see an unexpected communications failure) nor terminating the debug session (quite a tedious task), you can simply disconnect the A8 core (on the Debug view, right-click on the A8 core to see this option), push the reset button and then reconnect and reload the code. This will also automatically run the GEL initialization script.

    If you have external devices (PHY, ADC, etc.) that were initialized with a previous code run, the core processor reset will not bring those external devices to their power up values. In this case the ideal reset scenario is to power cycle every time, disconnecting and reconnecting the debugger as mentioned before.

    One pitfall to the power cycle is that, if you are using an onboard USB Debug Probe, you will have to terminate the debug session completely (by clicking on the red button) before power cycling it. The reason is that a power cycle on the board will also power down the onboard Debug Probe, which does not happen if using an external one.

    Overall these are the general rules I use to chase the correct level of Reset required by the systems I run.

    Hope this helps,
    Rafael
  • HI Rafael and thank you for your response.  It doesn't necessarily solve my problem but this definitely gives me more insight and you showed me a few new tricks.

    All of the processors I've worked on, with the exception of the AM335x,  provide an Interrupt Vector Table that is extremely useful for issues like this as well as other trouble shooting techniques.  As I mentioned in the earlier post, the Debugger ends up in the syscall.c file.  Is this file the equivalent of a Vector table?  It's almost like this file needs to be updated with a jump to RESET or some other startup instructions.

    Thanks again for the feedback.

    Joe

  • Joe,

    You should be able to look at Tools->ROV->Hwi and see the interrupts that the kernel manages. ROV will show you the vector table location also. I'd also look at ROV->BIOS->Scan for errors and ROV->SysMin to see if there is anything useful there.

    Todd