CCS/TMS320F28069M: Daisy-chain of 3 C2000's is Failing on the Last Device in the Chain

Hi Tim,

Three times is a charm, heh? :)

I really can't explain why the procedure is consistently failing on the third time - unfortunately I haven't plugged three devices in the same scan chain and would need to spend some time creating the hardware to accomplish this. 

Does the procedure still fail three times if you try to connect only to the third device? Are there other combinations where the third device can't be connected at all? Also, how are the lengths and the HW on these connections? 

I am trying to get an idea if there are any additional scenarios that could contribute for this to manifest itself. I also wonder if other devices on the same scan chain could perhaps reduce noise margin or other details when they have firmware previously loaded to them.  

In the mean time, I will try to get hardware to try and reproduce this. 

Regards,

Rafael

Hey Rafael:

Very funny - ain't no charm though having to reconnect to these CPUs 3 times - it's getting really old after a couple hundred times!  :-( 

Yes, it still fails 3 times if I try to connect to the 3rd CPU first.  No issues with 1st and 2nd CPUs connecting the first time and haven't seen the 3rd CPU take more than 3 times to connect.  Although a few times, I have seen the 3rd CPU connect the first time, but it's rare.

There are no other devices on this JTAG scan chain - just these 3 C2000 CPUs.  The trace lengths are 3" to 5" and we have buffers driving the traces to the CPUs.  And once we connect to the 3rd CPU, no problem downloading and running the program. code.

I was flying from the West Coast to Atlanta today so a little late getting back with you - thanks for your quick response. 

I will send you the .ccxml file we are using in a separate email since this forum site won't let me send it.

Please let me know if you see any issues with what we are doing?

Thanks,
Tim

Tim,

Thanks for sending the .ccxml file - I really don't see any issues with it at all, neither with your procedure. 

As I mentioned, I am putting together a small JTAG splitter to see if I can find any intrinsic failure with the tools. 

Regards,

Rafael

Hey Rafael:

Thanks for doing this.  Just a few more points - I was going off my memory and was not totally correct on what happens if I try to connect to the 3rd (last) one in the chain first.  Upon further testing, if I try to connect to the 3rd one first, it never connects.  However if I connect to the 1st or 2nd one first, I then can connect to the 3rd one, but it still takes 3 times to connect to this last device in the chain.  In addition, I don't have to connect to both the 1st and 2nd one, I just have to connect to either one first and then if I try to connect to the 3rd one (i.e., last device in the chain), then this last device will connect, but it always takes 3 times to connect. 

Thanks,
Tim

Tim, 

I am still not able to connect to the three devices using the XDS110 or the XDS200, although I am using a non-buffered splitter, which complicates things. 

In your case with the buffered splitter, I am pretty sure there is a borderline condition for this issue to happen.

For example, I reproduced the same scenario as yours when I used the XDS100v2 running at 1.0MHz and three boards (two F28069 eXperimenter kits and one F2812 eZdsk) connected to the splitter using very short cables:

- trying to connect to the last DSP (F28069) in the chain always returned error -1015

C28xx_1: Error connecting to the target: (Error -1015 @ 0x0) Device is not responding to the request. Device may be locked, or the debug probe connection may be unreliable. Unlock the device if possible (e.g. use wait in reset mode, and power-cycle the board). If error persists, confirm configuration and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 8.2.0.00004)

- connecting first to either the first or the second DSP on the chain required three attempts to connect to the last F28069, returning the following two errors in sequence:

C28xx_1: Error connecting to the target: (Error -1015 @ 0x0) Device is not responding to the request. Device may be locked, or the debug probe connection may be unreliable. Unlock the device if possible (e.g. use wait in reset mode, and power-cycle the board). If error persists, confirm configuration and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 8.2.0.00004)
C28xx_1: Error connecting to the target: (Error -1140 @ 0x0) Lost debug connection to device. 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 8.2.0.00004)

Under the same conditions, the errors do not happen when I connect using the XDS560v2 Traveler using the standard 10.368MHz - any of the DSPs connect straightaway. 

Both the XDS110 and the XDS200 refuse to connect at any TCLK speed and usually report error -233 (scan-path broken) or at lower sppeds, error -235. This indicates the lower speeds are barely missing the goals for a reliable connection.  

When I was testing this setup with very long cables across my unbuffered splitter, none of the Debug probes was able to connect. As I was reducing the TCLK speed and changing cables, I was marginally able to connect using the XDS560v2 Traveler at 100kHz!

Therefore my preliminary conclusion is that prior connections to the devices earlier in the scan chain are "stabilizing" somehow the lines - perhaps the TMS or the TDI/TDO lines are being loaded with a proper impedance or even a running TCLK is capable of making the state machine in the last device to start picking up the pace of the other devices. All speculation, as I didn't attach an oscilloscope or logic analyzer to these lines. 

Also, it is known that the XDS110 and the XDS200 have slightly weaker line drivers when compared to the XDS560v2 and its buffer at the MIPI header. The XDS100 is a bit of a mystery, but perhaps its slower pace allows for a larger noise margin or group delays between the TDI/TDO and the TCLK.

I will keep investigating this, but there is a chance you will have to reduce even further the connections in your setup. That or get a XDS560v2 to validate your current design. 

Hope this helps,

Rafael 

Hey Rafael:

Thanks for your response and the time you have put into this so far.  That is interesting your conclusions.  When you say:

"reduce even further the connections in your setup"

are you referring to the line lengths on our board or what? 

BTW - we have tried this with an XDS100v2 and an XDS200v2 and we are experiencing the same problem.  In addition, on our board, we have an FTDI4232H device (i.e. serving as an on-board XDS100) along with an ISO7240 isolation/buffer device between the FTDI device and the C2000 and we are still experiencing the same problem.   We are able to connect, but every time, it takes 3 attempts on the third device.  And I mean like every time!  Weird that it takes 3 attempts to connect to the 3rd device, but perhaps it is as you say: 3 is the charm for these C2000 devices.  :-(  And BTW, I'm not laughing cause it's getting really really old and aggravating!

I have an old XDS560BP from Blackhawk.  I could try to use this and see if I can try to connect to it.   From what you have experienced though with your XDS560v2, you were able to connect to all 3 devices without having to reconnect to the 3rd device?

Thanks,
Tim

Tim,

Tim Simerly said:

are you referring to the line lengths on our board or what? 

Yes, the connection lengths. However, your additional comment:

Tim Simerly said:

along with an ISO7240 isolation/buffer device between the FTDI device and the C2000

That would complicate things as well. Isolation buffers can add a delay to the edges of the pulse transitions, thus requiring slower frequencies to properly acknowledge the data. 

Tim Simerly said:

I have an old XDS560BP from Blackhawk.  I could try to use this and see if I can try to connect to it.   From what you have experienced though with your XDS560v2, you were able to connect to all 3 devices without having to reconnect to the 3rd device?

I will try with my ancient Blackhawk XDS560 emulator as well, although I suspect it will be similar to the XDS560v2 that I am using. By the way, yes, it connects to the three devices at the first try - most probably due to the fact it has the buffers at the end of the target cable. 

Regards,

Rafael

Hi Rafael and Tim,

I have also confirmed Rafael's finding with the XDS560v2, that it works on the customer board with 3x F28069M MCUs in the scan chain. There are no issues connecting any of the MCUs at first try. Each MCU can be connected to without any particular order and code can be loaded. This is how JTAG should work.

I tested both 10MHz as well as 1MHz in this setup, both works with the XDS560v2 on the customer board.

Regards,

--Gunter

Hey Rafael:

This is interesting what Gunter has experienced.  I tried to use my XDS560BP, but I couldn't find it with the CCSv8.3 and CCSv9.1 that I am using.  I found a download from Blackhawk, but it was specific to CCSv3.3 which is way too old.  Do you know how to access my Blackhawk XDS560BP with my latest versions of CCS?

I don't think this is a trace issue being too long on the board since this is too reliable and repetitive.  It's always 2 retries on the 3rd device, but once connected all the downloads are working with no issues.   Once I get over this reconnect on the 3rd device, it works very reliably.  And now that Gunter has found that an XDS560 works with no issues, but an XDS100 and XDS200 exhibit the same result as the FTDI device with buffer/isolator that is on-board - this suggests we have an issue with using and XDS100 or XDS200 as a debugger for this board, correct?  Your thoughts?

Thanks,
Tim

Tim, Gunter,

I was able to connect using the standalone XDS110. In my particular setup (splitter without buffers), I was running into the problem of having three F28x boards with 2.2kΩ resistors in parallel to nTRST - something that causes the exact same issue as reported below:

https://e2e.ti.com/support/tools/ccs/f/81/p/628509/2333828#2333828 

In this case, I increased the value of the resistor in my setup (I added a bit more resistance to the nTRST path), but my unbuffered setup was still not working very well - the probe was detecting a valid path but was not being able to detect a valid IR/DR path length (most probably due to the added delay of the resistor and other issues in my splitter board). 

I then remembered having a Blackhawk XDS110 JTAG Isolation Protection (ISO110). Adding this to the scan path improved the entire signal chain due to the buffers in the isolation adapter. I am able to reliably connect to the three devices at frequencies of up to 5.5MHz.  

The issue with the three connections at the last device on the scan chain still stands, though. 

Your suspicion of a bug on the protocol scan may be warranted - the XDS100 and the XDS110 use the same drivers and they both exhibit the same behaviour: I am unable to connect directly to the third device using the XDS100 in any circumstance. 

The XDS200 and the XDS560v2 use the same SW drivers, but the weaker line drivers on the XDS200 are preventing me from reaching a definitive conclusion. 

At this point I can try to file a bug report, but the major issue is having a reproducible environment for the dev teams to start their investigation. I will try to get their opinion on the matter, but ideally I need to put together a buffered splitter to have this fully covered. 

Tim Simerly said:

but I couldn't find it with the CCSv8.3 and CCSv9.1 that I am using.

During CCS install, did you select Blackhawk support? If so, you should have entries for Blackhawk USB560-BP Emulator

Regards,

Rafael

Hey Rafael:

I appreciate your response and continuing to look into this.  I apologize for the delay.  I went on PTO no the day you sent this and just got back yesterday and catching up on emails and outstanding issues and this is one of them.  So are you thinking that this is an XDS100/XDS200 issue and this is more likely fixed in software or hardware? 

I did select the option for Blackhawk support when I installed CCS, but I don't see it come up with the available list of emulators.  Is there a way of rerunning the CCS install and only pulling in Blackhawk stuff?    However in the end, I recon it doesn't matter since we need to get this working on the board and the board is pretty much what is on the XDS100.  So hopefully we get this working with an XDS100 and we resolve the issue.

Your thoughts on next steps?

Thanks,
Tim

Hey Rafael:

Ok, this is the 2nd time I am posting this message - for some reason the prior one didn't come through.  So I was telling you in the 1st post that I went on PTO the day you sent your latest response and thanks for following up and making progress on this.  I just got back yesterday and catching up on emails and outstanding issues for which this this is one of them still outstanding and critical.

As for what you have found so far, are you thinking this is an XDS100/XDS200 issue?  And if so, is this fixable in hardware or software?  Since what we have on the board is a 4-channel version of the 2-channel version that is on the XDS100 and a slew of our launchpads, was hoping this was going to be a software fix vs hardware, but not a big deal if it is, just need to know so we fix this on the next rev of the board.   Interesting that the XDS560 does not have this problem when connected to our board.  So sounds like this is an XDS100 interface issue with connecting this to the F28069Ms that are on-board.

As for the XDS560BP that I am using, yes, I had chosen to use the Blackhawk emulators when I installed CCS.  Is there a way of reinstalling CCS and just having it pickup the Blackhawk emulators to make sure it didn't miss anything the 1st time I installed it?  Not a big issue since this sounds like more of an XDS100 issue, but I would like to confirm that I could use my XDS560BP without having to reinstall the complete CCS version.

Let me know your thoughts as to what you are thinking next steps would be to resolve this. 

Thanks,
Tim

Hey Rafael:

Testing 1, 2, 3.

Tim

For others following this thread: this is being discussed internally. I will post any relevant update. 

Rafael