CCS/TMDSEMU110-U: XDS110 Debug not working with AM4377

Hi,

Unfortunately I lost access to my AM437x boards, but I have used this several times with the XDS110 Debug Probe (as well as the XDS200, etc.) and never experienced this phenomenon. 

Can you delete the Debug Configuration in CCS (menu Run --> Debug Configurations) and retry?

One additional aspect is that perhaps the XDS110 may be set to a higher TCLK speed that is causing its connection to become unstable. You can change this in the advanced tab of the target configuration (check this entry) 

Given that you do not seem to be having trouble with the XDS200, I think it is safe to rule out anything related to the running software or an external watchdog timer (usually tied to the PMIC device) that may be inadvertently resetting the device.

I will try to think about additional environments and report back if I find anything relevant. 

Hope this helps,

Rafael

I tried deleting my Debug configuration. It didn't fix the issue.

As a note im running on a windows 10 based pc, but when I saw it working last I was working on a linux based machine with windows 10 as a VM. I have verified that in hardware devices it correctly identified the xds110. I have also run the xdsdfu.exe to make sure my xds110 was in a working state and up to date. Loading flash works just fine, so my assumption is that the driver is working. 

Thank-you for taking time to try to solve my problem.

Hayden 

After some more testing I found that running the xds110 on a native windows 10 computer has problems. though if i go back to a native Linux computer with a windows 10 vm it seems to work correctly. Both windows instances show the exact same version of emu, xds driver, and ccs. Any suggestions about what else I could test would be greatly appreciated.

- Hayden

I did some more testing and I still haven't found the solution to this problem.  I have followed the trouble shooting guide 'debugging tag' (link below). Changing jtag speed is included in there. I have tried different versions of the EMUpack (8.3, 8.4, 9.1) . I have tried different versions of CCS(9.2, 9.3 , 10.0). I have tried different versions of the xds110 driver and different versions of the xds110’s firmware. I have tried a different xds110’s. I have tried using different usb cables, and ports on different pc’s. I have made sure I was well isolated and was using the same mains ac to power the board and the pc. I have also tried not using a laptop disconnected from the charging cable. I have tried quite a few different debug settings. None of them have been able to fix my problem.  

Just to reiterate the issue I am seeing, I will link a youtube video showing exactly my problem. 

Youtube Video:

https://youtu.be/ZNtdQf1UYrw

Debug JTAG:

https://software-dl.ti.com/ccs/esd/documents/ccs_debugging_jtag_connectivity_issues.html

Hayden,

Thanks for sending the information. I was in the middle of a new reply while you sent your last post. 

As I mentioned before, I have seen this issue when the target hardware goes to a self reset (caused by a watchdog timer or so) and obviously that does not seem to be your case due to the fact it works on a VM and on a XDS200. 

However, I found an old AM437x IDK board here and, very strangely, I can confirm the issue. It also connects and then automatically lets the target run again. No other side effects were observed and the target resumes normally as soon as I hit "Halt". 

I went back in versions and found out that both CCSv9.1 with a TI Emulation package version 8.3.0.00003 and CCSv9.2 with a TI Emulation package version 8.4.0.00006 work fine. It also does not happen with other Cortex A cores (A8, A15). 

In this case, I filed the bug report EXT_EP-9785 (check its status in the link SIR in my signature below).

Unfortunately I couldn't find a workaround other than simply halting the core after it starts running, but hopefully the root cause is simple. 

I apologize for the inconvenience, 

Rafael

Thanks for the response Rafael, 

I also have noticed a few other problems that seem to be related in some way. I say related only because if i use a different debug probe like the xds200 or use the vm with a xds110 i do not see these problems. Also loading the same bin file via sd card and booting off of the sd card works with no issues. 

These problems occur when using the xds110 to flash the program onto the board:

Certain i2c calls seem to never return. 

Long sleeps(over ~1000) cause the A9 to hang

UART TX works fine but RX never seems to respond. As a note im not referring to the xds110 UART, i'm using an external ftdi chip for convenience. 

Thank-you again for the help and i will keep watch on that ticket #.

Hayden McGaugh said:

Certain i2c calls seem to never return. 

Does having interrupts disabled when stepping explain any of the issues you are having when debugging?

I tried that solution just in case and no it didn't seem to make a difference. As noted before this is also happening when just using the xds110 to flash the bin file to the board. 

The oddity in all this for me is that using the xds110 on a vm works perfectly. My team have used it for months to develop with. And all the problems im mentioning just do not occur there with the exact same software. 

Hayden,

I suspect it may be a race condition of sorts on the device driver. When capturing data to file the bug report, I enabled the Debug Server Log to get the most information to send to the dev teams, but that suppressed the bug.

Since the log information delays the whole debugging process by a slight margin, this matches what you see by running the software on a VM - with all its layers, delays are inevitable and the bug does not manifest itself. 

Given the other symptoms seem to go away with the same environment and change of Debug Probe, I really think they are all related. 

At any rate, this seems to have been introduced with the newer versions - or was simply hiding in the older versions. 

Regards,

Rafael