Debugging OMAP3530 EVM with CCS & JTAG

Bernie,

What about JTAG debugging the x-loader? Do you might have any suggestions on this topic? CCS could be an option, but it doesn't have to be. OpenOCD and Eclipse can also work. I've been looking around for the past two weeks, and couldn't find anything on the subject. The TRM doesn't ellaborate much on the subject. Is it possible to JTAG debug the x-loader?

Thanks,

Dan.

Hi Dan,

This is definitely possible - What I normally do is creating a while(1) loop in assembly being one of the first items in the x-loader code. Then I build and flash the x-loader. Hereby the OMAP3 is stuck in the while(1) loop after a reboot and you can easily connect using CCS and continue debugging from here as you would normally do. No real magic needed - It's pretty straight forward :-)

CCS, Lauterbach or similar professional equipment would be recommended. OpenOCD support for Cortex-A8 and OMAP3 is still very limited (you can connect, but I'm not sure you can single step yet) AFAIR...

I hope this helped you forward?
 Søren

Hello Søren,

Thank you very much for your reply. It does help me to get forward, unfortunately, not a lot.

I lack an understanding of the CCS environment, and my searches for a description of specific actions which I want to do - yielded nothing.

Do you perhaps know of a tutorial which will explains how to do the following in CCS v4.0:

• Change the program counter (in order to skip the while (1) loop )
• When starting 'Debug' under CCS, to disable the loading on an image. (Is it possible? To connect to the target and just 'step' through existing code)

Thanks,

Dan.

Dan Jordan said:

Change the program counter (in order to skip the while (1) loop )

You should be able to place the cursor on the line of code you want the PC to point at, click on the right mouse button and select "Set PC to Cursor".

Dan Jordan said:

When starting 'Debug' under CCS, to disable the loading on an image. (Is it possible? To connect to the target and just 'step' through existing code)

You should be able to simply use the "Launch TI Debugger" option.  However, you can also select Target->Debug... to configure CCS to only load symbols rather than load the program.

Thank you very much Brandon.

Dan.

Hello,

I've tried to do as you suggested, but I could get the "Set PC Cursor" command to be available. After I write my simple C program and press "debug", the image is loaded and I can step through the assembly code, but I cannot step through the C code. I can put breakpoints there, but they won't have any effect. It's like the C code has nothing to do with the assembly code I step through.

This is what I did: created a new project, added a C file containing a main() that defines two variables, created a new Blackhawk USB-560-M connection to an OMAP3530, removed the Cortex A8 GEL file, got the target to U-boot, and pressed "debug".

Another piece of information that might help: When I try to use printf, the image cannot be loaded. (I get a connection error)

Regarding the setting of the program counter - what am I doing wrong? why can't I step through the C code? I'm probably missing something... Also, how can I guarantee that the code which is running on the target is my C code? I've tried to play a little with the linker command file, but it didn't help much. (I didn't see an OMAP linker command file. Is there one?).

Regarding the x-loader: I want to be able to load a x-loader image which was compiled with my toolchain (runs on Linux). Does CCS know how to associate the code with an image even if the image was compiled with an external toolchain?

Thank you in advance,

Dan.

Hello Søren,

Thank you so much! It works!

For future references - I did the following:

Since I wanted to debug the x-loader from assembly (which eventually calls the C code) I had to make the loop in the assembly. I did something like this (added code is marked in red, and was added in the cpu/omap3/start.S file in my x-loader git tree):

reset:
inf_loop:
    b inf_loop
... [rest of reset code]

Then, I compiled it using my own toolchain (and not CCS's) loaded it through serial using pserial, and let it run.

Afterwards, I connected to the target using CCS, using the default connection for the Blackhawk USB560-m and the OMAP 3530 (I kept all the GEL files in place. Didn't touch them).  When connecting, I got two error messages, I ignored them and kept running - and then, finally I was able to step through the assembly code in the disassembly window in CCS, watching the infinite loop - and then, when adding the registers window - I could change the Program counter (as you suggested), and kept stepping through the x-loader assembly. Success!

However, another question arose: That's great for the assembly code, but what about the C code? How can I JTAG debug it? My problem is connecting my x-loader git tree to CCS, supplying the map file, so CCS could step through the C functions. Do you might have any suggestions?

Thank you,

Dan.

Hi Dan,

I'm happy that you got one step further at getting it working. For debugging C-code with CCS you need to select something like "Load Symbols" (I don't have my CCS setup right in front of me right now. Here you select to load the ELF file for x-loader (filename: x-load in your build path) In case this is build with debug-information/symbols by your GCC toolchain CCS will automatically ask you for a path to your C-files when you get into debugging something which origins from a C-file...

I hope this was clear?
  Søren

PS: I'm 99% sure that CCS connect should work as well without GEL files and without errors...

Hello Søren,

That has also worked!

Again, for future references, this is what I did:

While CCS was connected to the target (which was stuck in an infinite loop) I loaded the symbols: Target -> Load Symbols. I loaded the ELF file (The x-load file, which contains the debugging information, and not x-load.bin file which is actually loaded to the target) The Code and Data offsets were taken from the x-load.map file (the code under .text and the data was under .data). After that, I had to locate the source files, and that's it. Stepping through C code was accomplished!

Thanks a lot!

Dan.

Søren Steen Christensen said:

volatile int i=0; while (i==0);

Excellent! Thanks much, Søren. I'd assumed that there is a more customary/established way for breaking into xloader, so that's what I looked for, unsuccessfully. Your solution is clean and simple.Within minutes, I broke into xloader.

For the benefit of other readers, here is my particular procedure, using ccsv5 on a linux host:

1. File > New > Project > C/C++ > Makefile Project with Existing Code, and I gave it the xloader source directory. This was then built with your infinite-loop, and requisite debug symbols.

2. File > New > Target Configuration File, and then specified the JTAG emulator, and target board.

3. This Target Configuration was pointed at the xloader ELF executable. One way of doing so is as follows:

Run > Debug Configurations > xloader141.ccxml > Program > Device  > Cortex_A8_0 > Project  > x-load-1.41

where xloader141.ccxml was my target cfg, Cortex_A8_0 is my board, and x-load-1.41/ is the src code directory. (Yes, I know it's an old version of xloader!) Note that

Run > Debug Configurations > xloader141.ccxml > Program > Device  > Cortex_A8_0 > Program > x-load

is how the xloader executable was picked up. However, the dialogue box does not list all the files in the directory, even if you choose to display All Files! This is a minor bug; I simply typed the file name into the Location text-box.

4. xloader was appropriately written to the flash card;

5. The JTAG pod was connected to a USB port on the host, and the target board was booted from the flash card. It came up, and looped in the xloader src code. I'd put the loop deep inside the C code;

6. I started ccsv5, and did a Launch Selected Configuration on my xloader141.ccxml. Within moments, it connected, and halted at the infinite loop, showing the source code and all the variables, etc. Then I stepped through the code. (Right-click on the line after the loop, and select Move to Line, or some such thing, thereby skipping the loop.)

Thanks again,

Ali

Hi all,

I'm trying to debug U-boot for TI EVM 816X using BlackHawk XDS560V2.  I follow the directions found here and was able to break and step through the xloader code.  When the xloader code jump to the c code in board.c, my CCSv5.0.3 load the board.c file from arch/mips/lib/board.c instead of arch/arm/lib/board.c

I did rebuild U-boot and boot successfully, so I think the make file is set up correctly.  Why does CCSv5 pick up the wrong board.c and what can I do to correct this?

My target configuration in CCSv5 is for TI816x(no STM, ETB only)

Thank you,

Trip

I created a new workspace and redo all the steps. I did not tell CCSv5 where to find the source file. When CCSv5 cannot find the source file and asked me to locate the file, I pointed it to the correct board.c and it picked up the right file.

Hi All,

We're tying to bring up a DM3730 which uses embedded MMC as its storage and had expected to be abel to downlaod the XLoader/RBL through the JTAG interface and then debug it. Our board is based on the Beagle XM with most compoents removed and both and XM and our bard appear to get to the same stae in CCS v4, the output in console windw is here, first  line repeats many times..... so I guess i'm wonmdering how one is suppoed to get an XLoader debug going in this situation and also has anmyone got a good set of GEL files for a Beagle XM or do I just not need any of them (docs for them woudl be good of course!)

Cortex_A8_0: GEL: Warning loading file 'C:\Program Files\Texas Instruments\ccsv4\emulation\gel\cortexA8_util.gel', line 473: the function 'GEL_WatchAdd' is not supported.

Cortex_A8_0: GEL Output: OMAP 32K Watchdog Timer is disable

Cortex_A8_0: GEL Output:  Putting DPLL into bypass before proceeding 

Cortex_A8_0: GEL Output:  Putting CORE DPLL into bypass before proceeding 

Cortex_A8_0: GEL Output:  Locking CORE DPLL 

Cortex_A8_0: GEL Output:  PRCM clock configuration IIA setup has been completed 

Cortex_A8_0: GEL Output:  SystemClock = 19.2 MHz 

Cortex_A8_0: GEL Output:  DPLL_MULT_VALUE = 242 

Cortex_A8_0: GEL Output:  DPLL_DIV_VALUE = 13 

Cortex_A8_0: GEL Output:  CORE_DPLL_CLK = 663.771 MHz 

Cortex_A8_0: GEL Output:  CORE_CLK = 331.8855 MHz 

Cortex_A8_0: GEL Output:  L3_CLK = 165.9427 MHz 

Cortex_A8_0: GEL Output: MM01: mDDR Samsung K4X51323PC - 512 Mbit(64MB) on CS0, 4M x 32bit x 4Banks

Cortex_A8_0: GEL Output: common_sdram_init() completed 

Cortex_A8_0: GEL Output: SDRC initilization for mDDR_Samsung_K4X51323PC completed 

Cortex_A8_0: GEL Output: 19.2MHz clock configuration IIa 

Cortex_A8_0: GEL Output:   CORTEXA8_CORE_VERSION = 0x413FC082

Cortex_A8_0: GEL Output: Target contains version r3p2 of the CortexA8...

Cortex_A8_0: GEL Output: Read the ETM_POWER_DOWN_STATUS register...

Cortex_A8_0: GEL Output:   ETM_POWER_DOWN_STATUS = 0x00000001

Cortex_A8_0: GEL Output: ETM Access is enabled!

Cortex_A8_0: GEL Output: ETM_ID = 0x410CF236

Cortex_A8_0: GEL Output: OMAP 32K Watchdog Timer is disable

Cortex_A8_0: GEL Output:  Putting DPLL into bypass before proceeding 

Cortex_A8_0: GEL Output:  Putting CORE DPLL into bypass before proceeding 

Cortex_A8_0: GEL Output:  Locking CORE DPLL 

Cortex_A8_0: GEL Output:  PRCM clock configuration IIA setup has been completed 

Cortex_A8_0: GEL Output:  SystemClock = 19.2 MHz 

Cortex_A8_0: GEL Output:  DPLL_MULT_VALUE = 242 

Cortex_A8_0: GEL Output:  DPLL_DIV_VALUE = 13 

Cortex_A8_0: GEL Output:  CORE_DPLL_CLK = 663.771 MHz 

Cortex_A8_0: GEL Output:  CORE_CLK = 331.8855 MHz 

Cortex_A8_0: GEL Output:  L3_CLK = 165.9427 MHz 

Cortex_A8_0: GEL Output: System Reset has occured.

Cortex_A8_0: Loader: One or more sections of your program falls into a memory region that is not writable.  These regions will not actually be written to the target.  Check your linker configuration and/or memory map.

Cortex_A8_0: File Loader: Data verification failed at address 0x00000020 Please verify target memory and memory map.

Cortex_A8_0: Unable to terminate memory download: NULL buffer pointer at 0x3a9f

Error found during data verification.