• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 54 subscribers
  • Views 632 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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: AM5728 IDK cannot be programmed - reset and PRSC errors

Danish Belal
Prodigy 20 points
Part Number: AM5728


Tool/software: Code Composer Studio

I am trying to continue development of an existing demo project running on the AM5728 Industrial Development Kit (PN: TMDXIDK5728).  However it is not possible to run (debug) the program.  It compiles just fine, however the debug tool complains the following:

Cortex_M4_IPU1_C0: GEL Output: --->>> AM572x Cortex M4 Startup Sequence In Progress... <<<---
Cortex_M4_IPU1_C0: GEL Output: --->>> AM572x Cortex M4 Startup Sequence DONE! <<<---
Cortex_M4_IPU1_C1: GEL Output: --->>> AM572x Cortex M4 Startup Sequence In Progress... <<<---
Cortex_M4_IPU1_C1: GEL Output: --->>> AM572x Cortex M4 Startup Sequence DONE! <<<---
C66xx_DSP1: GEL Output: --->>> AM572x C66x DSP Startup Sequence In Progress... <<<---
C66xx_DSP1: GEL Output: --->>> AM572x C66x DSP Startup Sequence DONE! <<<---
C66xx_DSP2: GEL Output: --->>> AM572x C66x DSP Startup Sequence In Progress... <<<---
C66xx_DSP2: GEL Output: --->>> AM572x C66x DSP Startup Sequence DONE! <<<---
CortexA15_0: GEL Output: --->>> AM572x Cortex A15 Startup Sequence In Progress... <<<---
CortexA15_0: GEL Output: --->>> AM572x Cortex A15 Startup Sequence DONE! <<<---
CortexA15_1: GEL Output: --->>> AM572x Cortex A15 Startup Sequence In Progress... <<<---
CortexA15_1: GEL Output: --->>> AM572x Cortex A15 Startup Sequence DONE! <<<---
IcePick_D: GEL Output: Ipu RTOS is released from Wait-In-Reset.
IcePick_D: GEL Output: Ipu SIMCOP is released from Wait-In-Reset.
IcePick_D: GEL Output: IVAHD C66 is released from Wait-In-Reset.
IcePick_D: GEL Output: IVAHD ICONT1 is released from Wait-In-Reset.
IcePick_D: GEL Output: IVAHD ICONT2 is released from Wait-In-Reset.
C66xx_DSP1: Error connecting to the target: (Error -1180 @ 0x0) Device is held in reset. Take the device out of reset, and retry the operation. (Emulation package 7.0.100.0)

 

After resetting the board using the Hard-Reset push button three times (see Errata i842) and retrying, the following output is shown:

C66xx_DSP1: Error connecting to the target: (Error -6305) PRSC module failed to write to a router register. (Emulation package 7.0.100.0)

At this point im lost and dont know what to do.  The board did work for a single time but didnt work anytime else.  I also swapped the boards to check if my board is faulty, however the behaviour was the same.

CCS Version: 7.4.0.00015

Best regards
Danish Belal

  • 0
    TI__Guru**** 171309 points

    Danish,

    Unfortunately I don't have the same board as you here with me, but it seems the C66x cores are not brought out of reset. Can you go to menu Scripts → AM572x MULTICORE Initialization → DSP1SSClkEnable_API and see if you are able to connect to the core afterwards? 

    If you are still unable to connect to the core, I wonder if there is a misconfiguration or perhaps a different boot mode on your board that may be preventing the DSPs from properly initializing. If you have code running previously on the device, try to prevent it from running and try to connect to the DSP again. 

    I did a brief test on my AM574x IDK and, despite a few GEL initialization errors coming from the differences between the AM572x and AM574x devices, I was able to connect to both C66x cores without a problem.  

    One last note: the AM572x devices had two core revisions with minor differences between them. Did you try connecting with both that are available on the Target Configuration Editor? They are very similar (if not identical) to the IDK configuration. 

    Hope this helps,

    Rafael

  • 0 in reply to desouza
    Prodigy 20 points

    desouza said:
    Can you go to menu Scripts → AM572x MULTICORE Initialization → DSP1SSClkEnable_API and see if you are able to connect to the core afterwards? 

    There are no scripts in the list.  Might this be the issue?

    desouza said:
    I wonder if there is a misconfiguration or perhaps a different boot mode on your board that may be preventing the DSPs from properly initializing. If you have code running previously on the device, try to prevent it from running and try to connect to the DSP again. 

    There is definetely some old software running on the board as the green LED of the Ethernetport J8 is constantly blinking. I believe that the boot configuration cannot be changed.  The IDK User Guide says that the config can be changed with pull-up/pull-down resistors, but doesnt show where they are located or what resistor is connected to what bit.  However it says "The AM572x IDK EVM is configured by default to 0x8106 to enable UBOOT/Linux boot from the SDCARD". The secondary boot device selected by this boot mode is QSPI1.

    There is no SD-Card plugged in so the program is probably coming from some on-board nonvolatile SPI-Memory.

    However, why does it matter? I thought that the debug tool writes the program to some (volatile) memory and starts executing it, thus "overwriting" the previous path of execution.

    desouza said:
    AM572x devices had two core revisions with minor differences between them.

    There is only one possible selection for the IDK, that is "IDK_AM572X".  I did not find a IDK Device with another device revision.

    I checked the device markings (AM5728BABCX[BE]A; not sure if the second to last is an E or a B).
    As such the Chip has the device revision B (= SR2.0), which is the newest model.

    The Test Connection feature indicates that the connection is ok. Note however, that the successful test was done with "XDS100v2 USB Debug Probe".
    Using "XDS100v3 USB Debug Probe" this will result in an error saying that the controller has detected a cable break.

    [Start: Texas Instruments XDS100v2 USB Debug Probe_0]

    Execute the command:

    %ccs_base%/common/uscif/dbgjtag -f %boarddatafile% -rv -o -F inform,logfile=yes -S pathlength -S integrity

    [Result]


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

    C:\Users\belal_d\AppData\Local\TEXASI~1\
        CCS\ti\0\0\BrdDat\testBoard.dat

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

    This utility has selected a 100- or 510-class product.
    This utility will load the adapter 'jioserdesusb.dll'.
    The library build date was 'Nov  6 2017'.
    The library build time was '10:36:36'.
    The library package version is '7.0.100.0'.
    The library component version is '35.35.0.0'.
    The controller does not use a programmable FPGA.
    The controller has a version number of '4' (0x00000004).
    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 FTDI FT2232 with USB interface.
    The link from controller to target is direct (without cable).
    The software is configured for FTDI FT2232 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).

    -----[The log-file for the JTAG TCLK output generated from the PLL]----------

    There is no hardware for programming the JTAG TCLK frequency.

    -----[Measure the source and frequency of the final JTAG TCLKR input]--------

    There is no hardware for measuring the JTAG TCLK frequency.

    -----[Perform the standard path-length test on the JTAG IR and DR]-----------

    This path-length test uses blocks of 64 32-bit words.

    The test for the JTAG IR instruction path-length succeeded.
    The JTAG IR instruction path-length is 6 bits.

    The test for the JTAG DR bypass path-length succeeded.
    The JTAG DR bypass path-length is 1 bits.

    -----[Perform the Integrity scan-test on the JTAG IR]------------------------

    This test will use blocks of 64 32-bit words.
    This test will be applied just once.

    Do a test using 0xFFFFFFFF.
    Scan tests: 1, skipped: 0, failed: 0
    Do a test using 0x00000000.
    Scan tests: 2, skipped: 0, failed: 0
    Do a test using 0xFE03E0E2.
    Scan tests: 3, skipped: 0, failed: 0
    Do a test using 0x01FC1F1D.
    Scan tests: 4, skipped: 0, failed: 0
    Do a test using 0x5533CCAA.
    Scan tests: 5, skipped: 0, failed: 0
    Do a test using 0xAACC3355.
    Scan tests: 6, skipped: 0, failed: 0
    All of the values were scanned correctly.

    The JTAG IR Integrity scan-test has succeeded.

    -----[Perform the Integrity scan-test on the JTAG DR]------------------------

    This test will use blocks of 64 32-bit words.
    This test will be applied just once.

    Do a test using 0xFFFFFFFF.
    Scan tests: 1, skipped: 0, failed: 0
    Do a test using 0x00000000.
    Scan tests: 2, skipped: 0, failed: 0
    Do a test using 0xFE03E0E2.
    Scan tests: 3, skipped: 0, failed: 0
    Do a test using 0x01FC1F1D.
    Scan tests: 4, skipped: 0, failed: 0
    Do a test using 0x5533CCAA.
    Scan tests: 5, skipped: 0, failed: 0
    Do a test using 0xAACC3355.
    Scan tests: 6, skipped: 0, failed: 0
    All of the values were scanned correctly.

    The JTAG DR Integrity scan-test has succeeded.

    [End: Texas Instruments XDS100v2 USB Debug Probe_0]

  • 0 in reply to Danish Belal
    TI__Guru**** 171309 points

    Danish,

    Danish Belal said:
    There are no scripts in the list.  Might this be the issue?

    This list is tied to the core being highlighted - in this case, these scripts would show if the Cortex A15 is highlighted. From your description, however, is that the messages you showed in your first post indicate the C66x DSP cores are released form Wait-in-reset (I missed that, sorry). 

    Danish Belal said:
    There is definetely some old software running on the board as the green LED of the Ethernetport J8 is constantly blinking.

    In general the Ethernet port LEDs blink even without a program loaded to the device.

    Danish Belal said:

    There is no SD-Card plugged in so the program is probably coming from some on-board nonvolatile SPI-Memory.

    Removing the SDCard would surely prevent any Linux/uboot from loading, unless there is something else on QSPI. You could try the details in the thread below to program or erase the QSPI.

    https://e2e.ti.com/support/processors/f/791/t/666342

    Danish Belal said:

    However, why does it matter? I thought that the debug tool writes the program to some (volatile) memory and starts executing it, thus "overwriting" the previous path of execution.

    Certain Linux or u-boot versions powered down the debug subsystem of the device, thus preventing the connection via JTAG. I am unsure if that is what is going on in this case. 

    At any rate, the configuration seems ok but I send the short clip below with the procedure and configuration I am using to connect to the DSPs of my AM574x IDK board. Perhaps a step may be missing. 

    Danish Belal said:
    The Test Connection feature indicates that the connection is ok. Note however, that the successful test was done with "XDS100v2 USB Debug Probe".
    Using "XDS100v3 USB Debug Probe" this will result in an error saying that the controller has detected a cable break.

    This is expected. The XDS100v3 is not present on the IDK board. 

    I will try to "break" my system here and report back in case I find anything relevant. 

    Hope this helps,

    Rafael