AM335xEVM example project won’t build and run in CCSv5 with TMS470 compiler

Hi,

      I believe you have not installed all the packages while installing CCS. tiobj2bin is not installed in your machine. refer http://e2e.ti.com/support/development_tools/code_composer_studio/f/81/t/168266.aspx for more information.

Basically you need to install "Stellaris Cortex M MCU" package while installing CCS.

Regards

Baskaran

also "Then I unsuccessfully tried to load the buzzerBeep.out into the debugger. " can you explain what is the error you are getting.

1. What is the configuration in target configuration ccxml.

2. Are you able to connect MPU (cortex A8)?

Regards

Baskaran

Thank you for your advice to install the Stellaris Cortex M MCU package. I installed that and I am no longer getting the link error. However, I still can’t run the buzzerBeep application.

 I followed the instructions for TMS470 form CCS project and Debugging on EMV AM335x using CCSv5 on the AM335x StarterWare Environment Setup page

http://processors.wiki.ti.com/index.php/AM335X_StarterWare_Environment_Setup#Debugging_on_EVM_AM335x_using_CCSv5

 For the Target Configuration file, I selected AM335x with Blackhawk USB560-M Emulator.

I tested the connection to the debugger and that passes.

After launching the target and connecting to the Blackhawk USB560-M Eumlator_0/CortxA8, I successfully executed the AM335x_EVM_Initialization script. Then I loaded the buzzerBeep program. The program does not appear to run and when I suspend operation it appears to be at the trap instruction at 00020080 as shown:

00020080:   EAFFFFFE B               0x20080

00020084:   EAFFFFFE B               0x20084

00020088:   EAFFFFFE B               0x20088

0002008c:   EAFFFFFE B               0x2008C

00020090:   EAFFFFFE B               0x20090

00020094:   EAFFFFFE B               0x20094

00020098:   EAFFFFFE B               0x20098

0002009c:   EAFFFFFE B               0x2009C

000200a0:   EAFFFFFE B               0x200A0

000200a4:   EAFFFFFE B               0x200A4

000200a8:   EAFFFFFE B               0x200A8

000200ac:   EAFFFFFE B               0x200AC

000200b0:   EAFFFFFE B               0x200B0

000200b4:   EAFFFFFE B               0x200B4

000200b8:   EAFFFFFE B               0x200B8

000200bc:   EAFFFFFE B               0x200BC

000200c0:   E59F102C LDR             R1, 0x200F4

000200c4:   E5911000 LDR             R1, [R1]

000200c8:   E2011C07 AND             R1, R1, #1792

000200cc:   E1A01421 MOV             R1, R1, LSR #8

000200d0:   E3510003 CMP             R1, #3

000200d4:   1A000005 BNE             0x200F0

000200d8:   E59F1018 LDR             R1, 0x200F8

000200dc:   E5912000 LDR             R2, [R1]

 The buzzerBeep executable appears to have been loaded at address 0x80002940 per the map file, but it did not execute.

 If I manually set the PC to 0x80000000 (the platform lib entry point) and single step, it will go off into the weeds at init.asm line 162, because the start_boot address is pointing off in the weeds.

 Here is an excerpt from the map file:

SECTION ALLOCATION MAP

 output                                  attributes/
section   page    origin      length       input sections
--------  ----  ----------  ----------   ----------------
.init      0    80000000    000000b4    
                  80000000    000000ac     system.lib : init.obj (.text)
                  800000ac    00000008     rtsv7A8_A_le_eabi.lib : auto_init.obj (.tramp.__TI_auto_init.1)

.text      0    800000b4    000029d0    
                  800000b4    000005f4     platform.lib : gpio.obj (.text)
                  800006a8    00000570     drivers.lib : hsi2c.obj (.text)
                  80000c18    00000450     system.lib : cp15.obj (.text)
                  80001068    0000043c     platform.lib : dmtimer.obj (.text)
                  800014a4    00000428     drivers.lib : gpio_v2.obj (.text)
                  800018cc    00000324     platform.lib : hsi2c.obj (.text)
                  80001bf0    000002c0     system.lib : interrupt.obj (.text)
                  80001eb0    000002b8     drivers.lib : dmtimer.obj (.text)
                  80002168    000001e8     platform.lib : cpld.obj (.text)
                  80002350    00000180     rtsv7A8_A_le_eabi.lib : memcpy32.obj (.text)
                  800024d0    00000120     platform.lib : sysdelay.obj (.text)
                  800025f0    000000fc     system.lib : exceptionhandler.obj (.text)
                  800026ec    000000f4     rtsv7A8_A_le_eabi.lib : u_div32.obj (.text)
                  800027e0    000000d4                           : auto_init.obj (.text)
                  800028b4    0000008c                           : cpy_tbl.obj (.text)
                  80002940    00000070     buzzerBeep.obj (.text)
                  800029b0    00000060     system.lib : cpu.obj (.text)
                  80002a10    00000048                : startup.obj (.text)
                  80002a58    00000020     rtsv7A8_A_le_eabi.lib : icall32.obj (.text)
                  80002a78    0000000c     system.lib : cpu.obj (.text:CPUIntStatus)

.bss       0    80002a84    00000200     UNINITIALIZED
                  80002a84    00000200     system.lib : interrupt.obj (.bss:fnRAMVectors)

.const     0    80002c84    00000038    
                  80002c84    00000038     system.lib : startup.obj (.const:vecTbl)

.data      0    80002cbc    00000004    
                  80002cbc    00000004     platform.lib : sysdelay.obj (.data)

.stack     0    87fffff0    00000008     UNINITIALIZED
                  87fffff0    00000008     --HOLE--

MWagner,

                 Are you able to execute the prebuilt binary which is in the package. i dont see anything wrong in the steps you followed.

Regards

Baskaran

If I try to load a pre-built binary (eg. gpioLCDBacklight.out) with the ebugger and run, I get the same result.

The application does not run correctly. And if I suspend the debugger, execution is at a trap address (0x00020088:  EAFFFFFE B    0x20088)

Also, I verified that the compiler is building the buzzerBeep project properly, by putting buzzerBeep_ti.bin (renamed to app) onto the SD card.

Then I booted the EVM board off of the SD card and the beep program runs correctly.

I'm not certain what could be wrong with the debugger setup.

Here is the output after I run the AM335x_EVM_Initialization script. As far as I can tell it executed properly:

CortxA8: Output:      ****  AM335x 15x15 EVM Initialization is in progress ..........
CortxA8: Output:      ****  Subarctic ALL ADPLL Config for OPP == OPP100 is In Progress .........
CortxA8: Output:      Input Clock Read from SYSBOOT[15:14]:  24MHz
CortxA8: Output:      ****  Going to Bypass...
CortxA8: Output:      ****  Bypassed, changing values...
CortxA8: Output:      ****  Locking ARM PLL
CortxA8: Output:      ****  Core Bypassed
CortxA8: Output:      ****  Now locking Core...
CortxA8: Output:      ****  Core locked
CortxA8: Output:      ****  DDR DPLL Bypassed
CortxA8: Output:      ****  DDR DPLL Locked
CortxA8: Output:      ****  PER DPLL Bypassed
CortxA8: Output:      ****  PER DPLL Locked
CortxA8: Output:      ****  DISP PLL Config is in progress ..........
CortxA8: Output:      ****  DISP PLL Config is DONE ..........
CortxA8: Output:      ****  Subarctic ALL ADPLL Config for OPP == OPP100 is Done .........
CortxA8: Output:      ****  Subarctic OPP100 DDR2 EMIF and PHY configuration is in progress.........
CortxA8: Output: EMIF PRCM is in progress .......
CortxA8: Output: EMIF PRCM Done
CortxA8: Output: DDR PHY Configuration In progress
CortxA8: Output:  Waiting for VTP Ready .......
CortxA8: Output: DDR PHY CMD0 Register configuration is in progress .......
CortxA8: Output: DDR PHY CMD1 Register configuration is in progress .......
CortxA8: Output: DDR PHY CMD2 Register configuration is in progress .......
CortxA8: Output: DDR PHY DATA0 Register configuration is in progress .......
CortxA8: Output: DDR PHY DATA1 Register configuration is in progress .......
CortxA8: Output: emif Timing register configuration is in progress .......
CortxA8: Output: emif Timing register configuration is done .......
CortxA8: Output: DDR PHY Configuration done
CortxA8: Output:      ****  Polar Subarctic DDR2 EMIF and PHY configuration is DONE ****
CortxA8: Output:      ****  AM335x 15x15 EVM Initialization is Done ******************

MWanger,

                  Unfortunately nothing strikes in my mind for this issue. can you debug (step in) and see which routine causes it to crash. May be that will help us to narrow down the possibilities.

Regards

Baskaran

I'm getting very inconsistent behavior if I try to use breakpoints.
If I try to use them, the debugger always ends in the weeds and sometimes I'll get an error message similar to the following:

CortxA8: Trouble Setting Breakpoint with the Action "Continue or Finish Stepping" at 0x80000088: (Error -1066 @ 0x333C) Unable to set requested breakpoint in memory. Verify that the breakpoint address is in writable memory. (Emulation package 5.0.520.0)

So I have to single step from the entry point at 0x80000000.
When I single step, I must execute every instruction (ie. must use "Step Into" for every instruction).
"Step over" will result in the system going off in the weeds on a BL instruction.

When I use single stepping, I can single step through init.asm and into start_boot.

The program will always fail in CopyVectorTable at instruction 80002A28.


          CopyVectorTable:
80002a10:   E92D4010 STMFD           R13!, {R4, R14}
145           CP15VectorBaseAddrSet(AM335X_VECTOR_BASE);
80002a14:   E59F4034 LDR             R4, $C$CON1
80002a18:   E1A00004 MOV             R0, R4
80002a1c:   EBFFF961 BL              CP15VectorBaseAddrSet
147           for(count = 0; count < sizeof(vecTbl)/sizeof(vecTbl[0]); count++)
80002a20:   E59F002C LDR             R0, $C$CON2
80002a24:   E3A0C00E MOV             R12, #14
149               dest[count] = src[count];
          $C$DW$L$CopyVectorTable$3$B, $C$L1:
80002a28:   E4901004 LDR             R1, [R0], #4
          $C$DW$L$CopyVectorTable$4$B, $C$DW$L$CopyVectorTable$3$E:
80002a2c:   E4841004 STR             R1, [R4], #4
147           for(count = 0; count < sizeof(vecTbl)/sizeof(vecTbl[0]); count++)
80002a30:   E25CC001 SUBS            R12, R12, #1
80002a34:   1AFFFFFB BNE             $C$L1
151       }


Here are some core registers and their values before and after I execute LDR R1,[R0],#4 at 80002A28

PC           0x80002A28        0xFFFFFFF0
SP           0xA7FFFAC0        0xA7FFFFE8
LR           0x80002A20        0x80002A34
CPSR     0x60000193        0x60000197
R0           0x80002C84       0x80002C88
R1           0x80002C80       0xE59FF018

For some reason, the PC goes off into the weeds, and the program fails here every time.

One other thing that doesn't make sense to me is the SP.
The link file places it at 0x87FFFFF0.
I don't understand why it is being set to 0xA7FFFFxx when the program executes.

I am experiancing similar issues. I am not able to run the example programs in the debugger. However, I can run the NAND Flash writer program in the debugger. I am able to set break points and use the "step over" command. 

I've noticed that the linker file for the Flash Writer is very simple, and differs from the linker command files for the examples projects. I see an warning that "cint00" has been changed, i believe by the line "-e Entry" in the linker files. Also, the stack is only 8 bytes, which looks odd to me.

When I load any of the demo applications, the program just runs, it does not stop at main like the Flash Writer tool. If I suspend the target, it is at instruction"

 0002008c:   EAFFFFFE B               0x2008C

If I load any of the example applications and run, when I hit the suspend button,

the program is more often than not at an instruction similar to what Jon Young is seeing.

(ie. EAFFFFFE      B    0x200xx)

I modified the buzzerBeep and gpioLCDBacklight linker files to put code only in internal RAM, and had success. I was able to run to main, single step, and set break points.

I haven't had time to look into why code won't run from external DDR.

MEMORY
{
    RAM0        : org = 0x402F8000  len = 0x00017fff /* OCM RAM0 */
		DDR_MEM    	: org = 0x80000000  len = 0x7FFFFFF  /* RAM */
}

/* SPECIFY THE SECTIONS ALLOCATION INTO MEMORY */

SECTIONS
{
    .init 	 : { 
    			 system.lib<init.obj> (.text) 
    		   } load > RAM0
  			
    .text    : load > RAM0              /* CODE                          */
    .data    : load > RAM0              /* INITIALIZED GLOBAL AND STATIC VARIABLES */
    .bss     : load > RAM0              /* UNINITIALIZED OR ZERO INITIALIZED */
                                           /* GLOBAL & STATIC VARIABLES */
    				RUN_START(bss_start)
					RUN_END(bss_end) 
    .const   : load > RAM0              /* GLOBAL CONSTANTS              */
    .stack   : load > RAM0           /* SOFTWARE SYSTEM STACK         */
}

Changing the linker file to use internal RAM also works for me.

I am able to load, set breakpoints and run the app using the Blackhawk debugger.

Now the issue is to determine what's going on with running out of external DDR when using the debugger.

Using the debugger with external DDR fails every time.

If I disconnect the debugger and load my program onto an SD card and execute it out of external DDR, everything works fine.

In this case only possibility could be gel not executed properly. But the gel log you embedded in earlier reply doesn't indicate any possible issue. Can you try with different board or emulator.

Regards

Baskaran

There are 2 people experiancing the same issues, highly unlikely its a hardware issue.

I am experiancing the same issues with an XDS100v3 debugger. My AM335x EVM baseboard is rev 1.1A.

I'm not sure if the EVM initializes DDR for you before your download.  If not, then you may have to do that.

On the BeagleBone, with CCSv5.1, after loading the debugger ccxml file, I run a script which writes the registers to set up the DDR.

The script appears under the Scripts pulldown menu once the ccxml file is done initializing. Then I can download my app.

Hope this helps.

Gerry Belanger

I tried a different EVM board with the same Blackhawk debugger, and now everything is functioning properly.

I still don't understand why the original EVM board works just fine if I run the app from an SD card, copying it into DDR memory. and executing it from there.

How are the EVM boards different? Do they have different profile settings? 

in the problematic evm,

Can you take the dump of EMIF registers (0x4C00_0000) and compare them in the following 2 scenarios.

    1. boot the application with bootloader -> connect target with CCS -> get register dump

    2. Conmnect target with CCS -> load gel file -> get register dump

Regards

Baskaran

I made the same GEL file DDR setting changes that JayWhy suggested and now I can successfully use the debugger with both EVM boards.

This is awesome!

Thanks for you help.

Wanger, Jay,

         Thanks for the update. Can you share the updated gel file, so that we can evaluate and if needed include the changes in the next release.

Regards

Baskaran

3644.AM335x.gel

See attached. 

Hi!

I had a similar behavior while step-debugging. I found that at one point, the T bit of the CPSR register was switched to 1 when the initial task of the OS is called. This causes the CPU to interpret the ARM instructions in Thumb. Since this doesn't make sense, the PC quickly jumps to unmapped memory locations and finally ends up at  0002008c:   EAFFFFFE B               0x2008C.

I haven't been able to explain why the T bit of CPSR is set un the first place but I suspect that it requires Supervisor privileges to do the context switch and the CPU is already in user mode at this point.

Would anynone know how to prevent the CPU to go in User Mode in the _c_int0 boot code? I would like to stay in supervisor until my OS has started.

Same issue. Hardware and toolchain:

• Cpu AM3359 
• ICE demoboard rev. 1.0A;
• am335x_sysbios_ind_sdk_1.0.0.4
• Code Composer Studio Version: 5.2.0.00069