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.

MCU-PLUS-SDK-AM243X: Am243X launchpad Project setup and Debug

Part Number: MCU-PLUS-SDK-AM243X

Hi,

I am tying to setup a PRU to output to in the most basic sense, and I am running into some issues.   I have a system project setup and I am using that to configure all the peripherals, and then I have a project on an ARM R Core and a project on RPU1.  Everything builds and seems to be configured correctly, but when I try to debug I get: 

Error connecting to the target:
(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 9.13.0.00201)v

When I try to connect the JTAG with the ccXML file I generated I get: 

[Start: Texas Instruments XDS110 USB Debug Probe_0]

Execute the command:

%ccs_base%/common/uscif/dbgjtag -f %boarddatafile% -rv -o -S integrity

[Result]


-----[Print the board config pathname(s)]------------------------------------

C:\Users\GriffiEV\AppData\Local\TEXASI~1\
    CCS\ccs1230\0\0\BrdDat\testBoard.dat

-----[Print the reset-command software log-file]-----------------------------

This utility has selected a 100/110/510 class product.
This utility will load the adapter 'jioxds110.dll'.
The library build date was 'Sep  6 2023'.
The library build time was '09:57:39'.
The library package version is '9.13.0.00201'.
The library component version is '35.35.0.0'.
The controller does not use a programmable FPGA.
The controller has a version number of '5' (0x00000005).
The controller has an insertion length of '0' (0x00000000).
This utility will attempt to reset the controller.
This utility has successfully reset the controller.

-----[Print the reset-command hardware log-file]-----------------------------

The scan-path will be reset by toggling the JTAG TRST signal.
The controller is the XDS110 with USB interface.
The link from controller to target is direct (without cable).
The software is configured for XDS110 features.
The controller cannot monitor the value on the EMU[0] pin.
The controller cannot monitor the value on the EMU[1] pin.
The controller cannot control the timing on output pins.
The controller cannot control the timing on input pins.
The scan-path link-delay has been set to exactly '0' (0x0000).

-----[An error has occurred and this utility has aborted]--------------------

This error is generated by TI's USCIF driver or utilities.

The value is '-233' (0xffffff17).
The title is 'SC_ERR_PATH_BROKEN'.

The explanation is:
The JTAG IR and DR scan-paths cannot circulate bits, they may be broken.
An attempt to scan the JTAG scan-path has failed.
The target's JTAG scan-path appears to be broken
with a stuck-at-ones or stuck-at-zero fault.

[End: Texas Instruments XDS110 USB Debug Probe_0]

The ccXML looks like this:

I tried lowering the speed and tinkering with the boot mode, but nothing seems to work.  I inherited a disjointed project that was working yesterday so I don't think its hardware related. 

I also googled around and found talk of gel scripts and other things, but those don't appear to have resoled the issue, but that does not mean they are not the issue, more likely my newness to CCS is part of the problem.

What should I check?

  • Hi Griffin, 

    How do you initialize the SoC? Are you using the GEL file or the SBL_NULL? Refer to the following links for details:

    1. SoC Initialization with SBL_NULL

    2. SoC Initialization with GEL

    We recommend users to use the SBL_NULL.

    Best regards,

    Ming

  • Hi Ming,

    So I tried to simply things to the bare minimum to get things going and had no luck. I am just trying to run hello world on the R5, and seeing the same issue.  This is with the CPU_reset.gel file. 

    I also read through the EVM setup portion of the SDK and I do not see anything in the UART terminal in either boot modes.  I assume data should just show in the terminal without me doing anything except changing the bootmode dip switches, is that correct?  If this was flashed with other software since it was opened, could that cause this, or are the bootmode switches loading of memory on the unit?

    Thanks!

  • Hi again!

    I tested another board, and it did fine with hello world.  Maybe it is a hardware issue.  Is there an easy way to verify this?

    Thanks!

  • Hi Griffin,

    If you set the boot mode to OSPI boot mode, you should see the following display on UART terminal, if the SBL_NULL has been flashed in the AM243x LP:

    Starting NULL Bootloader ...
    DMSC Firmware Version 21.1.1--v2021.01a (Terrific Lla
    DMSC Firmware revision 0x15
    DMSC ABI revision 3.1
    INFO: Bootloader_runCpu:151: CPU r5f1-0 is initialized to 800000000 Hz !!!
    INFO: Bootloader_runCpu:151: CPU r5f1-1 is initialized to 800000000 Hz !!!
    INFO: Bootloader_runCpu:151: CPU m4f0-0 is initialized to 400000000 Hz !!!
    INFO: Bootloader_loadSelfCpu:214: CPU r5f0-0 is initialized to 800000000 Hz !!!
    INFO: Bootloader_loadSelfCpu:214: CPU r5f0-1 is initialized to 800000000 Hz !!!
    INFO: Bootloader_runSelfCpu:235: All done, reseting self ...
    Keep in mind there two UART ports on J20, one for JTAG, one for Main UART0. The display will be on the MAIN UART0.
    If you set the boot mode to UART boot mode, you should see the following display on UART terminal:
    You should see character "C" getting printed on the UART terminal every 2-3 seconds as shown below:
    Best regards,
    Ming

  • Hi Ming,

    I am going to look into this a bit more later, but as this was inherited, I am going to assume there is an issue with the board.  Basic example code does not appear to be outputting on the UART or console as I would expect.  The board I have that is fresh out of the box is working as I would expect and I have moved onto getting debug to run on the non ARM cores.  The ARM cores are running great.

    Thanks for your help.