Will CCS5 do source level debug of u-boot via JTAG on a C6A816x?

I'm following the "Stop Mode" debugging instructions found here:

http://processors.wiki.ti.com/index.php/Linux_Debug_in_CCSv5#Stop_Mode_Debug

... but using u-boot files instead of the Linux kernel.  When I load symbols (the u-boot ELF file) CCS5 can't find the source even though it has been given the path to where all the source is and I made a "Makefile" project as the instructions suggest.

Is there some kind of trick that I need to do to have the source code show up or am I stuck looking at disassembly???

Regards,

Brian

Hmm, I guess there aren't many trying this from the number of responses I've received ;)

I'm using my Spectrum Digital EVM as a test bed to try and understand how I may debug board bring up with CCS5.  I've noticed that when I connect to the target and load the u-boot ELF file ... while CCS is trying to connect to the target ... it is running out of NOR (I have IODC) and I see that sometimes it makes it all the way into booting the Kernel before the connection is made.  The reset control in CCS5 appears broke or maybe I'm just ignorant in setting it up right.

One would think you could make CCS halt the target when it connects but this is not happening.  When I finally do get it to halt, doing a "restart" resets the PC but when I say resume I do not get u-boot startup messages ... I get kernel crash messages.  I'd like to be able to "restart" and then "resume" and have the target start running as if it were power cycled or reset.

As it is now, I'm setting hardware breakpoints and they never get hit because the target has passed them by the time CCS connects.  I guess I can do the infinite loop thing but I'd like to not have to modify the code to use JTAG ... that is what JTAG is for.

Regards,

Brian

Brian,

I am having a crack at this now. The way I have had it working previously is to turn the board on and then immediately connect to the Cortex A8 which causes the ARM to pause. I can then load the U-Boot symbols and do some step through debugging.

Ideally I'd be able to use the "load program" feature of CCS but so far this hasn't worked. I'm now going to have a go at what I've seen in your post and also in this one:

http://e2e.ti.com/support/development_tools/code_composer_studio/f/81/p/94214/336605.aspx#336605

How are you running out of NOR? I am using the NAND version of the binary to boot from.

Ralph

Hey Ralph,

I've been meaning to update this post but it keeps slipping my mind.  I've learned a few things in the mean time.

When I posted this I was using a XDS100v2 and was trying to debug our custom board.  All I could determine at the time while I was trying to debug u-boot startup from NOR is that the board ran a few instructions and then appeared to go into some type of loop and I never saw any debug symbols.

Since then I've learned that the loops I was getting into were called "Dead Loops" (which are talked about in the TRM) and were part of the TI parts internal ROM code.  Turned out that our board was messed up and the BTMODE bits were not being latched right and so the board went straight into the weeds (dead loop on a data-prefetch error).

The XDS100 doesn't control the hardware very well and is a little maddening to try to do startup debugging with.  We have since obtained XDS560's and life is better.

We have been able to do some source level debugging with the 560's.  It used to be that u-boot was difficult to debug as it relocated itself (at least once) which means you need to change your symbols mid stream and CCS doesn't appear to have a way to do that.  I think BDI-3000 type devices are still better at doing this but you can get by with CCS & 560's.

Our FAE put me on to this but you can actually download (yes, I mean Run->Load Program in CCS) the ELF u-boot (the file named u-boot, not u-boot.bin) to the target and then single step right from the first instruction.  This version of u-boot is smart enough to check the PC to see if it is running out of RAM or NOR and do the right thing so that makes it a lot easier to tell what u-boot is doing.   Being able to download u-boot to RAM was nice as our flash was hosed up and the board wasn't starting from NOR but if you downloaded u-boot to RAM it would run that way.

I have both EVM's (DDR2 & DDR3) and am currently running 100% out of NOR flash (u-boot, kernel, and rootfilesystem - tried jffs2 and squashfs ).

Hope that helps.

Regards,

Brian

Ralph,

I checked out that link in your post and to my knowledge it is correct.  I mostly use CCS5 in Linux (Ubuntu machine) but I have used CCS on windows too and I have to use Samba to share the source with the Windows machine.  I've had bad experiences where breakpoints don't activate right and sometimes it can't unwind where the source is and you have to help it along and locate the source file.  It appears to only have trouble knowing the path to a source file if there are several files of the same name.

Oh, and when CCS says it can't find source and asks if you want to locate it ... you better pick the right file because if you don't I can't figure out a way to "undo" and pick the right file other than to rename the file which will make CCS say it can't find the file again and give you another opportunity to then point it to the right file.

This same kind of thing can happen on CCS if you run it from Linux but it happens to a lesser extent.  To me, CCS generates less static trying to debug u-boot/kernel on Linux than Windows. 

Regards,

Brian

Of course, it's all to do with the right BTMODE settings. That's a start. I've set my BTMODE to 11111 which apparently is "GP Fast External Boot".

Still, when I try and run my program, "u-boot.bin" CCS gives me this error:

The "u-boot" file sort of does better in that this dialog box doesn't come up but instead I get:

CortexA8: GEL: Encountered a problem loading file: S:\ezsdk\ti-ezsdk_dm816x-evm_5_01_01_80\psp\u-boot-2010.06-psp04.00.00.10\u-boot.bin Could not determine target type of file
CortexA8: File Loader: Data verification failed at address 0x80700000 Please verify target memory and memory map.
CortexA8: Unable to terminate memory download: NULL buffer pointer at 0x3a9f
CortexA8: GEL: File: S:\ezsdk\ti-ezsdk_dm816x-evm_5_01_01_80\psp\u-boot-2010.06-psp04.00.00.10\u-boot: a data verification error occurred, file load failed.

So maybe I should be running a GEL file first or something. How did you get the .bin file running?

Many thanks,

Ralph

Brian and Ralph,

I've had many interruptions before being able to answer this post, but I managed to finally get a similar procedure as the Stop Mode debug in the Linux page above. The method shown by Brian above also works, it is just an additional way of doing things.

Turn on the board. Halt the Autoboot (if it is not booting, then it doesn't matter).

Open the Debug Configurations (similarly to the Stop Mode debug) and in the tab Program assign the u-boot project and the "u-boot" file with debug symbols (not u-boot.bin, as mentioned by Brian above) - make sure the Cortex A8 is selected in the drop-down menu.

Launch the debugger. Go to menu Run --> Advanced  --> Enable Halt on Reset. After that, go to menu Run --> Resets --> CPU Reset (HW) - the CPU should halt in the beginning of the bootloader code.

Simply doing "Run" allowed me to see the u-boot run and go through autoboot, etc. from the SD card (I didn't yet have time to test the NOR/NAND, but it should work as well).

All this was done with CCSv5.1M6 and C6A816x EVM.

I still need to fool proof this, but this should also help you get going.

Regards,

Rafael

Hey Ralph,

I edited my post to be more clear.  The ELF file is the file just named plain u-boot, not the u-boot.bin.  You should be able to download that file to RAM with Run->Load Program.

If you are just tracking along with what is going on in the NOR when you boot out of it ... use Run->Load Symbols and use the same ELF file.

We normally do use a GEL file.  We have been using the one from Spectrum Digital's support site and it has the "On Connect" feature so it will automatically run as soon as the target is connected.

Regards,

Brian

Hi Rafael,

I tried what you said using CCS5.1M6, DM8168 EVM and XDS560v2. I am loading the whole program, not just symbols.

1.

I have the board setup to boot from SD card with a valid SD card inserted. I have no GEL files specified. I turn the board on and stop the autoboot. I launch the target configuration and enable "Halt on reset". I connect to the target. I do HW reset. I resume and U-Boot boots in the console and I can pause and resume with F8. The disassembly appears but no source code despite me specifying the source lookup path as the entire of the current workspace (a "Makefile" project with all the U-Boot source code in). If I add the directory for the U-Boot source this doesn't help. The source code window just says "No source available".

2.

I also tried to boot without an SD card in the slot. No GEL files specified. I turn the board on and there is no console output due to lack of SD card to boot from (as expected). I launch the target configuration and enable "Halt on reset". I connect to the target. I do HW reset. Then this error appears in the console window in CCS:

CortexA8: Warning: (Error -2063 @ 0x0) Unable to reset device. Power-cycle the board. If error persists, confirm configuration and/or try more reliable JTAG settings (e.g. lower TCLK). (Release 5.0.429.0)

I ignore the error message and try to resume. Nothing happens at my console window indicating that UBoot is not running.

3.

Method 2. but with the DDR3 EVM GEL file. I tried both one I found on the TI forums and the Spectrum Digital one. Neither had any improvement.

Any tips? I don't mind doing method 1. if it's the only way but how do I get my source code lookup working and why does it think that there is no source code at all?

Basically I don't think the "load then execute from RAM" option works. I think all the F8 key in option 1 is doing is to pause and resume the processor; I don't think it's actually loading the binary from JTAG. The "load symbols" method seems to work but only once U-Boot has started running. Has this something to do with memory offsets as mentioned in the post I linked to previously?

Thanks,
Ralph

Ralph,

#1: The procedure looks fine, but the one thing I think is missing is load the file that contains the debug symbols - the u-boot file (no extension) mentioned before. When you build u-boot this file is located inside the u-boot sources project. With the debugger open, you can load the symbols by going to menu Run --> Load --> Load Symbols.

#2 and #3: Not sure of one thing: did you load u-boot file (as mentioned by Brian) to memory? In order to do this you must have a GEL preloaded (as the u-boot file has a fixed address of 0x80000000 - external RAM) and load it just as Brian mentioned. You can then simply

You are right: F8 simply runs the code, and does not load anything. However the Load Symbols and Add Symbols can be used with or without code running on the target - they only perform the correlation between the address and the source code symbols (function names, variables, etc.)

Tomorrow I will post a video that shows the process I used for #1 above.

Regards,

Rafael

Hi Rafael,

I look forward to the video. In all the above I had already configured the Debug Configuration to "load the program" "u-boot". I thought this would automatically load the specified program to the EVM via JTAG and run it once connected to the target and then HW reset? Am I mistaken? My mention of loading symbols at the end of my post was based on experience previous to this.

Thanks,
Ralph

P.S.

While I am here, I think it is a bug that in order to edit a Debug Configuration you need to have launched a Target Configuration. This shouldn't be necessary in my opinion.

That works really well. A video speaks a million words! It has ironed out several issues I had. I would still like to know how to do the "load program" method, but I now have a method I can develop and debug U-Boot with so cheers.

Ralph

Brian, can I give you an equally big thank you. The method you described works for NAND and NOR U-Boot images. I selected "u-boot" and away I was. The bit that really helped was your description of the use of the GEL file. I'm going to have to read up on them as they've caught me out before (but for the DSP).

Regards,

Ralph

hi hutchman,

I can't find source when using the CCS5 debug u-boot on windows.

I did that as the file 1680.CCS5 debug uboot on AM3358 EVM.pdf

Can you give me some advice,  thanks.