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.

CCS/AM5728: SPL/U-boot debug in CCSv7

Part Number: AM5728
Other Parts Discussed in Thread: CCSTUDIO

Tool/software: Code Composer Studio

Hello,

I'm writing to get information about SPL/Uboot debugging using CCSv7 on AM5728 evaluation board Rev A3. I'm using CCSv7.0.0.00043 (on Linux Ubuntu 16.04) and latest version of SDK (03.03.00.04). I've performed all steps in Sitara Linux Training - uboot_linux_debug_with_ccsv5 documentation http://processors.wiki.ti.com/index.php/Sitara_Linux_Training:_uboot_linux_debug_with_ccsv5 and firstly I'm trying to debug SPL code so I've performed following steps:

1- On CCSv7 as File->New->Project->C/C++->Makefile Project with Existing Code for Uboot source project

2- Build and Compile Uboot source by using CCSv7 Make File Target in detail https://training.ti.com/linux-board-porting-series-module-6-building-u-boot-ccs or using command 

export PATH=/home/alicanlinux/ti-processor-sdk-linux-am57xx-evm-03.03.00.04/linux-devkit/sysroots/x86_64-arago-linux/usr/bin:$PATH

make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- distclean

make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- am57xx_evm_config

make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf-

3- Setup target configuration with "Blackhawk XDS560v2-USB System Trace Emulator" and Board or Device: AM5728. 

4- Launch Configuration and connect to the CortexA15_0 target.

5- CPU Reset (SW) to CortexA15_0 target for changing the ARM core mode from THUMB-2 to ARM or Core Registers -> CPSR register list change the T register from 1 to 0

6- Load Memory with (Uboot source dir)/spl/u-boot-spl.bin, start address 0x40300000 (CONFIG_SPL_TEXT_BASE value in u-boot-spl.cfg) and type-size 32bits

7- Load symbols from (Uboot source dir)/spl/u-boot-spl (code and data offset left empty)

8- Set Program Counter Register(PC) to address 0x40300000

After performing these steps, I'm able to create breakpoints successfully (Breakpoint and Hardware Breakpoint) using Disassembly view or New Breakpoint button on Code Composer Studio. But when I define Hardware Breakpoint in s_init(), watchdog_init() or early_system_init() functions on /(Uboot source dir)/arch/arm/cpu/armv7/omap-common/hwinit-common.c or on another source files, hardware breakpoints seem not working (won't stop the CPU).  

Could you suggest any way to solve the problem?

Best regards

Alican

  • The software team have been notified. They will respond here.
  • Hi Biser et. al.

    Have there been any updates on this issue? I think I'm having the same/similar issue.

    I'm attempting to run the SPL built from ti-processor-sdk-linux-am57xx-04.00.00.04 relying on the procedure in the TI board porting series modules 6,7 (based on CCSv5), but using the TI572XEVM, the XDS100v2 emulator, and CCS7.2.

    I'm also not able to hit breakpoints in CCS7.2. The A15_0 core keeps running until I press the pause button on CCS7.2.

    I've attempted to set hardware breakpoints after the watchdog is disabled by clicking on the blue baloon and entering the expression, file_name, line # for the hardware breakpoint.

    **I'm not following the exact procedure in the module 7 video ((1)load the bin file at the load address in memory followed by loading the symbols) as **I don't see a load memory button in the Linux version of CCS 7.2, only load program or load symbols options**. When I load u-boot-spl into A15_0 using load program, I can see PC is pointing to _start().

    (1) I'm assuming that for the SPL, I only need to connect to and load the A15 core 0, and can leave core1 alone, correct?
    (2) Sometimes when I hit the pause button to halt execution I can see what appears to be a trace stack under the A15_0 core, and what appears to be a valid PC.
    (3) Other times the PC is reset back to 0, despite setting breakpoints after the watchdog is disabled.
  • One potentially interesting fact... After I hit the pause button (after waiting for the breakpoints which are never reached), I notice that the PC is back at 0x00000000C.

    This makes me suspicious that the 572xEVM was reset by something.

    I am not able to connect the A15_0 via JTAG until I run something on the target first (e.g. take the target out of RESET). I run a linux image first and hit the space bar to halt at the u-boot command prompt, and then connect CCS to the target via JTAG.

    I am now able to load u-boot-spl.bin via a memory load as shown in the TI boad board seriels, module 7 video. But when I load the SPL in this way, u-boot from the SD card has already initialized interrupts and peripherals in a certain way.

    Is there something you have to do to properly initialize the am572x prior to loading u-boot-spl.bin into memory, followed by loading the symbols, setting a HW breakpoint, and then pressing the resume button? Is there maybe a script file or GEL file script that is available to initialize the environment?

    Am I barking up the right tree here?

    Thanks!

    Jeff
  • Thanks! I'm afraid I haven't been looking at this document. Will give this a try..

    This wiki page calls out CCS version 6. Does it matter whether I use CCS version 6 or 7.2 (the latest)? I'm currently running the latest TI SDK..

    Thanks!

    Jeff
  • I downloaded the .zip install file for 6.1.1, but when I run the installer, it attempts to fetch products from the internet which I believe are getting blocked by our firewall (ti_dspack_ibsetup_6.1.0 ......)


    I was able to install CCS 6.2, but that doesn't appear to have the GEL files for the A15 cores referenced in the above wiki page.

    Is JTAG debug of the am572x currently only supported in CCS 6.1.1?

    Is there a self-contained installer for 6.1.1 or is there a work-around for the firewall issues for this if 6.1.1 is the only possibility for A15.

    If I successfully install CCS 6.1.1 at home, can I copy it on a thumb drive and just unpack it on my work computer or do I need the .bin file?

    Thanks!
  • According to the release notes for your SDK (processors.wiki.ti.com/index.php ), CCSv6 is the supported version. I have feedback from the factory team that the breakpoint issue is under investigation. They will come back here when they have more information.
  • Biser,

    Thanks Biser!!

    Ok, the SDK notes say CCSv6, but 6.??  I saw in another post where you called out 6.1.1 specifically..

    I tried installing 6.1.1 at work and at home but encountered errors during the installation (see below).

    I was able to install 6.2 just fine.  But per the JTAG wiki you linked to yesterday (above), I didn't see the GEL files for initializng the A15 cores referenced in your wiki when I looked through the directory tree for CCS 6.2 (but I just looked in the am572x directory).  I will try installing it again and looking everywhere for it.

    Regarding CCS 6.1.1, I'm not able to install the 32 bit library for libcrypt11, but was able to install libcrypt20.  The installer for 6.1.1 flags this, but then allows the user to continue the installation. 

    I pick the minimum configuration (just click on the Sitara processor group) and don't click on any optional features.  When CCS 6.1.1 installer reaches the point where it tries to install com.ti.ccstudio.debugserver.linux.feature.group, I get Unable to download ti_dspack_ibsetup_6.1.0.1349.bin.

    I tried this both at work and at home.

    My host system where I'm installing CCS is 64-bit Ubuntu 16.04 LTS.

    *** Is there another sub version of CCS 6 which is the best version for JTAG debugging of am572x EVM?

    Thanks!!

  • Note:

    I was able to successfully install CCS 6.1.3, but I'm still not able to find the GEL files called out in the above link ( processors.wiki.ti.com/.../AM572x_GP_EVM_Hardware_Setup),

    AM572x_cortexa15_cpu0_startup.gel
    AM572x_cortexa15_cpu1_startup.gel.

    When I do a find . -print|grep cortexa15 under the ~/ti/ccsv6/ccs_base folder, the only thing I see is:

    ./emulation/boards/am571x/gel/AM571x_cortexa15_cpu0_startup.gel.

    My understanding is I need to attach an intialization script to the startup of the A15 cores to send an I2C message to the PMIC so that it stays on all the time for JTAG debugging.

    Any assistance would be greatly appreciated!!

    Thanks!

    Jeff
  • Note: I was using the wrong target configuration type, AM572X_RevA instead of GPEVM_AM572x_SiRevA.

    When I switched to the correct target configuration file and increased to JTAG clock speed for the XDS100v2 to 15 MHz, CCS loaded the correct gel files when connecting to core A15_0, and was able to initialize the PMIC to keep it powered on so that the JTAG connection could be maintained to CCS.

    When I switched to the correct target configuration in the advanced settings, CCS 7.2 re-populated all of the initialization scripts for all of the cores to what I believe are the defaults.

    A15_0, A15_1 were both populated with gpevm_am572x.gel and not AM572x_cortexa15_cpu0_startup.gel and AM572x_cortexa15_cpu1_startup.gel as indicated in the above link.

    I'm still not able to hit breakpoints per the above. Not sure whether we should be using hardware vs. standard breakpoints and why. I am pretty sure that I'm able to "run until cursor" by right clicking on the disassembly window in the function I want..

    Please let us know when there are updates from the CCS group on breakpoints..

    Thanks!

    Jeff
  • Hi Biser,

    Any news for my debug/breakpoint issue?

    Best regards

    Alican
  • I have asked again, but the person involved is out of office until middle of next week, so I don't expect feedback before then.
  • While not able to set hardware breakpoints while debugging the SPL on the am572xEVM, I was able to use "run until" within the disassembly window. But that required correlating A15 assembly code with the source. When I get a chance, I could post some instructions if that would be useful to anyone??

    Also, has anyone had success setting hardware breakpoints within programs running from external, DDR3 RAM as opposed to internal, on-chip, SDRAM? The SPL runs in internal, on-chip RAM, but u-boot runs in external, DDR3, RAM. I haven't yet been able to get SPL to jump to u-boot from wtihin CCS/JTAG.
  • Hello,

    Any updates to the CCS software team's investigation of why we cannot set hardware breakpoints when debugging the SPL on the 5728?

    Also, I was hoping to have some more info. on whether you actually can use HW breakpoints when you're running from external, DDR3 memory as opposed to internal ?SD? RAM by loading and running u-boot at the completion of running the SPL.  I'm able to get to the same point as the TI Lecturer in the TI board porting series video - when I load the SPL bin file into memory, load the symbols, adjust the program counter to the entry point of the SPL, and hit run.  I get an SPL string to print on the console and error messages indicating no boot target, RESET the board.  I followed the instructions in the board porting series on how to load an run u-boot from this point forward, but thus far - no luck.  

    So I was hoping to try setting hardware breakpoints in u-boot when loaded via the XDS debugger and CCS to see if that made any difference in CCS's ability to set hardware breakpoints (e.g. CCS is maybe able to set breakpoints with code running from external RAM as opposed to internal RAM), but I'm afraid I first need to figure out whether u-boot is loaded correctly.  I suspect there's something going on with the relocation...

    Also please note that I'm running with CCS v 7.2 as I was advised by our last-technical support rep that that should work, and we're able to get pretty far with it in that we can load and run the SPL on our custom hardware..

    Thanks!!

    Jeff

  • Hi Jeff,
    Sorry for the delay. I'm still looking at setting hw breakpoints when running from DDR.

    Right before the boot ROM jumps to the SPL code, it loads r0 with a booting parameters block in which one field is what device it loaded from. It looks to that device to load u-boot.img. The "no target detected" is because you have random data in that field. So the EMIF registers should be set correctly so that you can load u-boot. I just loaded u-boot and it looks like it loaded correctly.

    By the way, I use the ELF versions of SPL and u-boot.

    Steve K.
  • On second thought, do not use the ELF version. Use the .bin version and load to address 0x40300000. The ELF does not have device-tree blobs in it while the .bin does. I was doing some simple tests in MLO that did not require the device-tree blobs.

    Steve K.
  • Thanks Steve!

    I'm afraid I haven't tried getting u-boot to run in CCS after the SPL reports the No boot target error on the serial console.  One question about your last comment though... Are you talking about the SPL bin file or the u-boot bin file?  I was able to load the SPL bin file to the SPL _start address (0x40300000), and run the SPL.  But I thought the "load address" for u-boot (once SPL has finished its target configuration steps) was 0x80000000, right?

    Thanks!!  jeff

  • Hi Jeff,
    I am still working on this. u-boot has changed significantly since the online workshop was done. We're in the process of updating the workshop. I'll get back with you on Monday with the load address.

    Steve K.
  • Thank you Steve!

    We damaged our board with the 5728 which boots from SD card. We have another board which doesn't read from uSD card, but you can load the SPL and run it from CCS. If u-boot running from CCS can be used to re-flash the eMMC, we may be back in business. So your timing might be fantastic..

    Have a good weekend..

    Jeff
  • Sorry for the long delay. It looks like the start address for u-boot is 0x80800000.

    Steve K.