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.

Cannot connect to any ARM cores!

I'm embarrassed to say it but I cannot connect to any ARM9 cores using CCS!  I've unfortunately spent over a full day trying many combinations of CCS 3.3 SR12, CCS 4.1.2, BH USB510L, BH USB560, with/without SD adaptive clocking boards, with/without gel file, DM6467, DM6467T, DM365, and on and on.  No success!  If I stick an "old faithful" board like the 6713 in there I can connect immediately with all combinations listed.

What on earth has happened?

Let's focus on a specific setup:  DM365 EVM, BH USB560 (original version, not the 'm' or the 'bp'), SD 14-to-14 pin converter with SW1.1=ON and SW1.2=OFF (i.e. "XDS560 mode").

Step 1: with board powered off I attach the adapter and emulator.

Step 2:  Power on board.

Step 3:  Run BH diagnostic BHreset_560.bat.  

Step 4: Run BHprobe_560.bat

Step 5:  Configure CCS 4.1.2 for this setup.

Step 6: Launch Debug session and connect.  Two error boxes appear:

Step 7:  Disconnect and terminate debug session.

Step 8:  Try BHreset_560.bat again:

BHreset_USB560.log said:

 

************************************************** 

  BHProbe 5.01: Blackhawk USB560 JTAG Emulator   

************************************************** 

Wed 05/12/2010-15:21:17.45

bin\XDSProbe.exe -v -F BH560USB.out -p0x0 -r -o log\BHreset_USB560.log 

 

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

 

This utility has selected an XDS560 class product.

This utility will load the program 'BH560USB.out'.

This utility will operate on port address '0'.

The controller does use a programmable FPGA.

The old VHDL code has a version number of '1544' (0x0608).

The new VHDL code has a version number of '1544' (0x0608).

 

An error occurred while hard opening the controller.

 

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

 

This error is generated by TI's USCIF driver.

 

The value is '-181' (0xffffff4b).

The title is 'SC_ERR_CTL_NO_TRG_CLOCK'.

 

The explanation is:

The controller has detected a dead JTAG clock.

The user must turn-on or connect the JTAG clock for the target.

Done.

Step 9:  Try BHprobe_560.bat again:

BHprobe_USB560.log said:

 

Wed 05/12/2010-15:22:29.73 

**************************************************************************************************** 

TEST 1 - RESET 

**************************************************************************************************** 

************************************************** 

  BHProbe 5.01: Blackhawk USB560 JTAG Emulator   

************************************************** 

Wed 05/12/2010-15:22:29.82

bin\XDSProbe.exe -v -F BH560USB.out -p0x0 -r -o log\BHprobe_USB560.log 

 

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

 

This utility has selected an XDS560 class product.

This utility will load the program 'BH560USB.out'.

This utility will operate on port address '0'.

The controller does use a programmable FPGA.

The old VHDL code has a version number of '1544' (0x0608).

The new VHDL code has a version number of '1544' (0x0608).

 

An error occurred while hard opening the controller.

 

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

 

This error is generated by TI's USCIF driver.

 

The value is '-181' (0xffffff4b).

The title is 'SC_ERR_CTL_NO_TRG_CLOCK'.

 

The explanation is:

The controller has detected a dead JTAG clock.

The user must turn-on or connect the JTAG clock for the target.

Done.

**************************************************************************************************** 

TEST 2 - SCAN  

**************************************************************************************************** 

************************************************** 

  BHProbe 5.01: Blackhawk USB560 JTAG Emulator   

************************************************** 

Wed 05/12/2010-15:22:31.76

bin\XDSProbe.exe -v -F BH560USB.out -p0x0 -i -o log\BHprobe_USB560.log 

 

-----[Print the controller-open software log-file]---------------------------

 

This utility has selected an XDS560 class product.

This utility will load the program 'BH560USB.out'.

This utility will operate on port address '0'.

The controller does use a programmable FPGA.

 

An error occurred while hard opening the controller.

 

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

 

This error is generated by TI's USCIF driver.

 

The value is '-181' (0xffffff4b).

The title is 'SC_ERR_CTL_NO_TRG_CLOCK'.

 

The explanation is:

The controller has detected a dead JTAG clock.

The user must turn-on or connect the JTAG clock for the target.

Done.

**************************************************************************************************** 

TEST 3 - SCAN2 

**************************************************************************************************** 

************************************************** 

  BHProbe 5.01: Blackhawk USB560 JTAG Emulator   

************************************************** 

Wed 05/12/2010-15:22:33.68

bin\XDSProbe.exe -v -f bin\bh-noscantest.cfg -F BH560USB.out -p0x0 -i -o log\BHprobe_USB560.log 

 

-----[Print the controller-open software log-file]---------------------------

 

This utility has selected an XDS560 class product.

This utility will load the program 'BH560USB.out'.

This utility will operate on port address '0'.

The controller does use a programmable FPGA.

 

An error occurred while hard opening the controller.

 

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

 

This error is generated by TI's USCIF driver.

 

The value is '-181' (0xffffff4b).

The title is 'SC_ERR_CTL_NO_TRG_CLOCK'.

 

The explanation is:

The controller has detected a dead JTAG clock.

The user must turn-on or connect the JTAG clock for the target.

Done.

**************************************************************************************************** 

TEST 4 - DATA 

**************************************************************************************************** 

************************************************** 

  BHProbe 5.01: Blackhawk USB560 JTAG Emulator   

************************************************** 

Wed 05/12/2010-15:22:35.76

bin\XDSProbe.exe -v -F BH560USB.out -p0x0 -g -o log\BHprobe_USB560.log 

 

-----[Print the controller-open software log-file]---------------------------

 

This utility has selected an XDS560 class product.

This utility will load the program 'BH560USB.out'.

This utility will operate on port address '0'.

The controller does use a programmable FPGA.

 

An error occurred while hard opening the controller.

 

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

 

This error is generated by TI's USCIF driver.

 

The value is '-181' (0xffffff4b).

The title is 'SC_ERR_CTL_NO_TRG_CLOCK'.

 

The explanation is:

The controller has detected a dead JTAG clock.

The user must turn-on or connect the JTAG clock for the target.

Done.

Step 10:  Power cycling the board (not the emulator) puts the emulation back in a state where I can successfully repeat this whole process over again.

 


 

 

If I try doing the same procedure without the SD adapter I have related but different results.  For example CCS only gives one error:

 

In this scenario BHreset_560.bat and BHprobe_560.bat continue working after I disconnect from CCS.  FYI, I have already RMA'd FOUR of these adapter boards to Spectrum Digital under the suspicion they were causing the problem.  On some of the previous boards I could not ever get BHreset_560.bat to work so it seems like these boards are "better" but I still can't get a fully working solution!!!!

 

 

  • Hi Brad,

    Have you tried observing the status of JTAG clock TCK on CRO with and without emulator on the working and non-working boards?

    A broken link on a particular board or a faulty resistor might be a problem. Is there a series termination for TCK on board?

    Also, about the 2nd case, w/o adapter, does this happen each time (after repetitive iterations), maybe 2-3 times the chain did manage to get the JTAG clock.

    Can a small split in the TCK link of the emulator cable be a possible reason?

    Regards,

    Sid

  • I'm working from home today so I haven't been able to try this out yet.   Quick question though:  What is CRO?

    I think you're right though -- I probably need to get a scope on their to see what some of these signals look like.  That should hopefully give some clue as to what the heck is going on.

    I don't think I have a board/EVM issue as I have tried on 4 different EVMs without success.  It could be the adaptive clocking board though. 

    I'll report more info hopefully tomorrow.  In the mean time if anyone else has any ideas/experience/etc please chime in!

    Thanks,
    Brad 

  • CRO stands for Cathode Ray Oscilloscope (a Scope in short ) :P

    rather an old-fashioned name :)

    Good luck with your experiments.

    -- Sid

  • I've been traveling so I'm back in the office now stuck again!  I really need to get past this as I have several urgent issues to work on that I'm unable to do anything!

    Ok, here's what I see...

    Setup

    • DM6467T board
    • USB560 emulator (not  a Rev D cable)
    • Spectrum Digital 14-to-14 pin adaptive clocking adapter
    • Oscilloscope channel 2 connected to JTAG pin 9 (RTCK) on the EVM itself, i.e. processor side of the adaptor
    • Oscilloscope channel 3 connected to JTAG pin 9 (TCK) on top of the adapter board, i.e. emulator side of the adapter

    What I see is the following:

    • I run the BHprobe_USB560.bat
    • I see a 500 kHz signal on TCK
    • I see a ~18 MHz signal on RTCK

    I found it quite odd that RTCK was faster than TCK.  I thought RTCK should be the same or slower?!  I've done another test without the adapter board and in that case both TCK and RTCK are ~18 MHz, with RTCK offset a few ns from TCK (more reasonable).

    Furthermore, I tried connecting in CCS.  I see a rising edge on TCK and that's it!  No clock, nothing.  So I'm not surprised that I get the error message related to no target clock.   However, it seems to be our own fault, i.e. we are not generating a clock!

    What more should I look at?

    Brad 

  • Brad,

    Could you trying clocking down the TCLK setting for your emulator? I had problems connecting to the ARM9 cores of my DM6467 with my Blackhawk 560m until I clocked down (try legacy 10.368 or lower).

    ki

  • I tried a "user specified frequency" of 750 kHz (i.e. 0.75 in the dialog).  When I launch the debugger I still see TCK=500kHz and RTCK=18MHz.  As soon as I click "connect to target" then RTCK goes low and I get an error.  (I don't know what happened on TMS, TDI, etc. as I don't have enough probes!)

  • Brad,

    Could there be a problem with your adaptive clocking adapter? 

    I was looking at this page...http://processors.wiki.ti.com/index.php/Adaptive_Clocking

    It indicates that if you're using a very low TCK rate, which you are, that in itself is a solution to adaptive clocking.  Can you try this setup without your adaptive clocking adapter? 

    I believe from reading the description in this article http://www.blackhawk-dsp.com/downloads/docs/appnotes/BHadaptiveClocking-TA-01.pdf that RTCK should typically be at the same frequency as TCK, but can never be slower than TCK since we must wait for an RTCK edge before the emulator generates a TCK edge,

     

    Regards,
    Dan

     

     

     

  • Dan,

    Cripes almighty -- now why didn't I think of that myself?!  :)  I think you've nailed the issue.  It's the adaptive clocking board from Spectrum Digital.

    Running without the adaptive clocking board I can see the 750 kHz TCK and RTCK.  The emulator connects no problem.

    I just ordered an adaptive clocking board from Blackhawk/Corelis.  I'm going to give it a "test drive" to see if it's any better than Spectrum Digital.  Let's hope...

    I'm going to mark this one as verified.  Once I get the new adapter I'll try to remember to give an update.

    Brad

  • Ok, I have an update to share.  I ordered a Rev D cable (part #TMDSCBL560) for my 7 year old Blackhawk USB560 emulator.  It took a little experimentation to figure out how to get it working.  The key was to select my emulator as being the version with "20 pin cable" and to then change the properties to utilize the adaptive clocking mode.  Here's a screenshot:

    With the above configuration I can now connect to my DM6467 EVM.  Great!!!

    However, I still cannot connect to the EVM when using a USB510L emulator plus adaptive clocking board.  I ordered the "JACK" from Blackhawk and cannot connect with that one either!  I'm going to dig into that a little more, but if anyone has any suggestions please send them my way!

    Thanks,
    Brad

  • Doh -- looks like my trick above is already on the wiki: http://processors.wiki.ti.com/index.php/XDS560#Q:_Does_the_XDS560_support_ARM_Adaptive_clocking.3F

    Now I'm looking to see if there's some other trick for using a 510 emulator with the adaptive clocking board.

  • Ok, I think this is more or less resolved now.  For the 510 emulators the best solution was simply to NOT use the adaptive clocking board!  I'll try to summarize a few of the high points.

    Our newer devices (I think everything that followed DM6446) we have built additional capabilities into the emulation logic (ICEPICK_C).  These additional capabilities remove the need for the external adaptive clocking board.  Perhaps going further, trying to use both the external adaptive clocking board and the integrated capability actually resulted in a configuration that won't work at all!  I could not connect regardless of TCK speed, etc.

    There is a way to turn off the integrated capability.  I do not recommend turning off the integrated capability.  However, if you really need to do it for one reason or another, here's a quick summary:

    Spectrum Digital XDS510USB

    • Close CCS and unplug emulator.
    • Open the file C:\Windows\system32\sdopts.cfg
    • Find the line that has:  EmuIcePickFtck=YES
    • Change "YES" to "NO"
    • Save the file.
    • Plug in emulator and launch CCS.
    • You should now be able to connect, but in my experience with these newer devices it was less stable than just using a straight connection.

    Blackhawk USB510L

    • Blackhawk was going to add an option in CCS to allow this.
    • The test patch they gave me added an option on the "Advanced" page of the target configuration ccxml file.
    • Clicking on the emulator under there is a checkbox for "Using BH-EMU-JACK with TI ARM device".
    • Checking that box will allow you to use the JACK instead of the onboard adaptive clocking.
    • Again, my experience (on DM6467 specifically) was that using this option was less stable than simply using a straight hookup at the 10.368 MHz legacy speed.

    Here's a screenshot of the new option for the Blackhawk.  I'm not positive yet this will be broadly released, but this is what it looked like:

     

    I made some updates to this wiki page:

    http://processors.wiki.ti.com/index.php?title=Adaptive_Clocking#Solutions

    Hopefully I got most of the details right.  I'm told one of the TI emulation experts will review next week.

    Best regards,

    Brad