LP-XDS110: Debuge Programming Error -2131 @ 0x0

Hi Rohit6230,

We need to determine why the XDS110 cannot communicate with the RM48L540. From the log you provided, there is no connectivity between the probe and the device. A couple of easy places to start debugging this would be to validate the signal path between the XDS110 and the device, and to make sure you're using the appropriate CCXML configuration file.  Do you have a TMDSRM48HDK you could connect the XDS110 to to confirm at least everything behind that connection is working as expected?

Hi andyW,

Please find attachment for reference and please let me know if any changes. Or send me reference connection diagram with RM48 and xds110 CTI 20 PIN debugger.Sheet1, MCU SECTION-RM48L540-1.pdf

The "Design Files" download for the TMDSRM48HDK  may be a useful reference:  https://www.ti.com/tool/TMDSRM48HDK#tech-docs

The included schematic show how this board has been wired.

Hi Andy,

We had tried with TMDSRM48HDK REFERENCE.

Now its showing Error "Memory Map Setup for Flash @ Address 0x0CortexR4: File Loader: Failed to initialize flash programming: Reset Emulator error. The requested reset was aborted."

Test Connection

[Start: Texas Instruments XDS110 USB Debug Probe]

Execute the command:

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

[Result]

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

C:\Users\soft1\AppData\Local\TEXASI~1\CCS\
ccs1200\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 'Jun 17 2022'.
The library build time was '22:30:41'.
The library package version is '9.8.0.00235'.
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).

-----[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 XDS110 USB Debug Probe]

In your last test, it looks to me like you can successfully communicate with the device.  The Flash issue being reported is something different and may not be an error.  Please have a look at this thread: https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1158877/tms570ls3137-memory-map-set-up-for-flash-address-0x0-due-to-system-reset

Hi Andy,

Thanks for quick response.

Now I unchecked bypass DAP. and Receiving below error. and showing Load Failed.

CortexR4: Error: (Error -242 @ 0x0) A router subpath could not be accessed. The board configuration file is probably incorrect. (Emulation package 9.8.0.00235)
CortexR4: Trouble Halting Target CPU: (Error -2064 @ 0x0) Unable to read device status. 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.8.0.00235)
CortexR4: 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 9.8.0.00235)
CortexR4: Trouble Halting Target CPU: (Error -2064 @ 0x0) Unable to read device status. 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.8.0.00235).

Minor update: I'm asking around for further input on this issue.

Sorry Andy, but I didn't get it.

Hi Andy,

I can only complete the program loading successfully when I click 'Connect Target' immediately after manually releasing the nRST button. But I would like to achieve this without the need to press any keys. Please let me know how to do this.

It sounds like you are now able to connect to the CortexR4 core and load a program, but only if you manually assert and release nRST, and then immediately manually do a target connect from CCS.

In that case, the software running on the target is probably putting the target into a state where the debugger cannot connect to the R4 core. By resetting and then immediately connecting you gain control of the core before the target goes into a bad state. Now ... how to gain control of the core after it has gotten into this state is the question, and I don't have an immediate answer for you.

Hi Andy,

Yes, we are able to connect and load the program by using the manual Reset key (nRST). One more thing we observed is that when we connect an external MHz crystal to the RM48, at that time, the target goes into a bad state and sends the following error. To address this issue, we made two changes: one was to remove the external crystal, and the other was to add the reset key.

CortexR4: Error: (Error -242 @ 0x0) A router subpath could not be accessed. The board configuration file is probably incorrect. (Emulation package 9.8.0.00235)

CortexR4: Trouble Halting Target CPU: (Error -2064 @ 0x0) Unable to read device status. 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.8.0.00235)

CortexR4: 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 9.8.0.00235)

Hi Rohit,

Rohit6230 said:

Yes, we are able to connect and load the program by using the manual Reset key (nRST). One more thing we observed is that when we connect an external MHz crystal to the RM48, at that time, the target goes into a bad state and sends the following error. To address this issue, we made two changes: one was to remove the external crystal, and the other was to add the reset key.

Thank you for the additional details. I will bring this thread to the attention of the device experts who can assist further.

Thanks

ki