Tool/software: Code Composer Studio
I am trying to find a reliable way to debug the u-boot SPL running on my DRA752.
I have CodeComposerStudio v7 installed on Windows 7 with a XDS200 USB JTAG adapter.
I don't really care whether I need to flash the ".bin" file and point the debugger at the ELF for debug symbols or if I can directly load the ELF into SRAM. Either way would be fine but neither approach is giving me what I want at the moment.
All I'm trying to achieve is to catch the CPU halted / reset so I can step through the early initialization code. The only way I've managed to get the debugger working at all is to manually halt after the connect, and at that point the code is too far along and the problem I'm trying to debug has already occurred. I've checked all the boxes in the CCSv7 UI to tell it to halt on reset, program load, etc, etc, but not of it seems to work. CPU is always running when I connect.
Also doing run -> system reset sometimes produces this error:
CortexA15_0: JTAG Communication Error: (Error -1170 @ 0x0) Unable to access the DAP. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 6.0.579.0)
Changing the TCLK causes my attempts to connect/test the connection fail every time.
For what it's worth, my uboot-spl image is built using Linux in a Win7 hosted VM. CCSv7 on will not connect to my target board at all (yes it can see the XDS200 when I share the USB device), so there are some complications getting source-level debugging to work at all.
An *IDEAL* setup would be to just debug using the GDB supplied with our cross-compile chain in Linux and just run a gdb server on the windows side. It looks like gdb_agent_console.exe should do what I want. I was able to get gdb_agent_console to connect to the target board using CCSv7 created ".dat" file. GDB can then connect to the appropriate port for the A15 core, but then there's no "monitor" commands, and it won't respond to "run", etc.
Any suggestions that would help me get back to debugging the problem as opposed to debugging my debugger would be greatly appreciated.
