• Resolved

CCS/TMS570LC4357: JTAG daisy-chain with 1 board, 2 MCUs and 1 JTAG. How to use/setup CCS?

Part Number: TMS570LC4357

Tool/software: Code Composer Studio

Hi ki,
we had this discussion last fall:

https://e2e.ti.com/support/development_tools/code_composer_studio/f/81/p/631986/2331289#2331289

Now I've got the board. I'm trying to launch the debug session but then I get this failure:

This is the target configuration:


Note! The Test Connection works.

You said in the dialogue we had:
> Assuming you are using a more recent version of CCS than the one in the above link (which is for the old CCSv3.3) and you have created a custom target configuration file that matches your multicore...

I am using CCS 7.1.0. But how do I "create a custom target configuration file that matches the multicore"?

If I add another core:

I get another type of failure:


The message contains: "Make sure your device is unlocked". How do I make sure it's unlocked?


I am of course aware that it could be a HW error. The HW designers will make more checks but at least the MCUs have the correct voltage and are not in reset mode.

If you have any ideas I would be very greatful.

Kind regards,
Lars von Wachenfeldt
Bombardier Transportation
Rail Control Solutions

  • Hi again,
    my pictures disapperared when I saved the post. :(
    I use IE as a browser. In Chrome you are not able to save the image at all.
    Which web browser should I use?

    Anyway, I've attached/inserted a Word document with the message in this post instead. Hope it works.

    Kind regards,
    Lars

    CCS_TMS570LC4357 - JTAG daisy-chain with 1 board 2 MCUs and 1 JTAG. How to use_setup CCS.docx

     

  • Guru 124030 points

    In reply to Lars von Wachenfeldt:

    Lars,

    The second target configuration picture in the word document shows a correct target configuration for this system. As you suspect, the error message indicates an error with the HW. The fact the message mentions the device is "locked" or there are security errors is a consequence of the fact the Debug Probe has a limited ability to know what is the exact status of the device.

    At this point I would suggest that you double-check your design with the reference below:

    software-dl.ti.com/.../emu_xds_target_connection_guide.html

    If you wouldn't mind sharing the portion of the schematics that you are using, perhaps I could spot if there is something out of the ordinary.

    It seems you are already using the correct link to attach images, format text, etc to the thread. However, I really suspect there is something else happening with your browser - I haven't used IE for quite some time, but Chrome, Firefox and Safari work very well.

    Hope this helps,
    Rafael

    When posting, click on the link Insert Code, Attach Files and more... to attach images, files or use nice formatting.

    If my reply answers your question please click on the green button "This resolved my issue".

    Search the wiki or go to useful pages for SDOWP, Compilers, CCSv3, CCSv4, CCSv5, CCSv6, CCSv7
  • In reply to desouza:

    Rafael,

    I would like to start and say that you and your colleagues give the best service among all manufacturers we use. Since my department started using your products ten+ years ago you have always been so helpful. Top notch! Thumbs up!

    > If you wouldn't mind sharing the portion of the schematics...
    I do not think that portion of the schematics is highly classified but we have a holiday today and the office is closed tomorrow (I am Swedish and work in Stockholm) but I will check that on Monday. Thank you very much for the help!

    > It seems you are already using the correct link...
    Thank you. Next time I will have a newly started computer and try again with Chrome.

    Kind regards,
    Lars

  • In reply to Lars von Wachenfeldt:

    And I will of course tell the designers to have a look at the Target Connection Design provided in the link.
    Lars
  • In reply to Lars von Wachenfeldt:

    Hi Rafael,
    the HW designers have had a look at the target configuration home page and they say they have followed the guide lines basically. The exception is that we have isolators (safety reasons) and buffers between the MCUs. They have measured all the JTAG signals and they look good. 

    Here is the Test Connection result:

    [Start: Blackhawk XDS560v2-USB System Trace Emulator_0]

    Execute the command:

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

    [Result]


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

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

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

    This utility has selected a 560/2xx-class product.
    This utility will load the program 'bh560v2u.out'.
    Loaded FPGA Image: C:\ti\ccsv7\ccs_base\common\uscif\dtc_top.jbc
    The library build date was 'Jul 21 2017'.
    The library build time was '18:30:42'.
    The library package version is '7.0.48.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 '6' (0x00000006).
    The controller has an insertion length of '0' (0x00000000).
    The cable+pod has a version number of '8' (0x00000008).
    The cable+pod has a capability number of '7423' (0x00001cff).
    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 Nano-TBC VHDL.
    The link is a 560-class second-generation-560 cable.
    The software is configured for Nano-TBC VHDL features.
    The controller will be software reset via its registers.
    The controller has a logic ZERO on its EMU[0] input pin.
    The controller has a logic ZERO on its EMU[1] input pin.
    The controller will use falling-edge timing on output pins.
    The controller cannot control the timing on input pins.
    The scan-path link-delay has been set to exactly '2' (0x0002).
    The utility logic has not previously detected a power-loss.
    The utility logic is not currently detecting a power-loss.
    Loaded FPGA Image: C:\ti\ccsv7\ccs_base\common\uscif\dtc_top.jbc

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

    Test Size Coord MHz Flag Result Description
    ~~~~ ~~~~ ~~~~~~~ ~~~~~~~~ ~~~~ ~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~
    1 none - 01 00 500.0kHz - similar isit internal clock
    2 none - 01 09 570.3kHz - similar isit internal clock
    3 64 - 01 00 500.0kHz O good value measure path length
    4 16 - 01 00 500.0kHz O good value auto step initial
    5 16 - 01 0D 601.6kHz O good value auto step delta
    6 16 - 01 1C 718.8kHz O good value auto step delta
    7 16 - 01 2E 859.4kHz O good value auto step delta
    8 16 + 00 02 1.031MHz O good value auto step delta
    9 16 + 00 0F 1.234MHz O good value auto step delta
    10 16 + 00 1F 1.484MHz O good value auto step delta
    11 16 + 00 32 1.781MHz O good value auto step delta
    12 16 + 01 04 2.125MHz O good value auto step delta
    13 16 + 01 11 2.531MHz O good value auto step delta
    14 16 + 01 21 3.031MHz O good value auto step delta
    15 16 + 01 34 3.625MHz O good value auto step delta
    16 16 + 02 05 4.313MHz O good value auto step delta
    17 16 + 02 13 5.188MHz O good value auto step delta
    18 16 + 02 1B 5.688MHz {O} good value auto step delta
    19 64 + 01 3B 3.844MHz O good value auto power initial
    20 64 + 02 0B 4.688MHz O good value auto power delta
    21 64 + 02 13 5.188MHz O good value auto power delta
    22 64 + 02 17 5.438MHz O good value auto power delta
    23 64 + 02 19 5.563MHz O good value auto power delta
    24 64 + 02 1A 5.625MHz O good value auto power delta
    25 64 + 02 1A 5.625MHz O good value auto power delta
    26 64 + 02 10 5.000MHz {O} good value auto margin initial

    The first internal/external clock test resuts are:
    The expect frequency was 500000Hz.
    The actual frequency was 499872Hz.
    The delta frequency was 128Hz.

    The second internal/external clock test resuts are:
    The expect frequency was 570312Hz.
    The actual frequency was 569214Hz.
    The delta frequency was 1098Hz.

    In the scan-path tests:
    The test length was 2048 bits.
    The JTAG IR length was 12 bits.
    The JTAG DR length was 2 bits.

    The IR/DR scan-path tests used 26 frequencies.
    The IR/DR scan-path tests used 500.0kHz as the initial frequency.
    The IR/DR scan-path tests used 5.688MHz as the highest frequency.
    The IR/DR scan-path tests used 5.000MHz as the final frequency.

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

    The frequency of the JTAG TCLKR input is measured as 4.994MHz.

    The frequency of the JTAG TCLKR input and TCLKO output signals are similar.
    The target system likely uses the TCLKO output from the emulator PLL.

    -----[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 12 bits.

    The test for the JTAG DR bypass path-length succeeded.
    The JTAG DR bypass path-length is 2 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: Blackhawk XDS560v2-USB System Trace Emulator_0]

    Does this test tell us that we have the correct HW design or could it still be a HW error? 

    Kind regards,
    Lars

  • In reply to Lars von Wachenfeldt:

    Hi Rafael,
    the HW designers had missed that the nRST was low due to a missing pull-up.
    Problem solved! Thanks!
  • Guru 124030 points

    In reply to Lars von Wachenfeldt:

    Lars,

    Sorry for the delay; I was out of the office earlier this week.

    At any rate, thank you for reporting back your findings! Much appreciated for similar inquiries in the future.

    Regards,
    Rafael

    P.S. I am quite surprised you managed to get 5MHz TCLK through isolated connection - the delay tends to be a lot higher through the optocouplers.

    When posting, click on the link Insert Code, Attach Files and more... to attach images, files or use nice formatting.

    If my reply answers your question please click on the green button "This resolved my issue".

    Search the wiki or go to useful pages for SDOWP, Compilers, CCSv3, CCSv4, CCSv5, CCSv6, CCSv7
  • In reply to desouza:

    No problems regarding the delay, Rafael. 

    The TCLK actually went up to ~6.8MHz when the "...legacy 10.368MHz limit" setting was selected. 
    I did not tell you what kind of isolation we use but it's your ISO7440.
    Maybe that can explain the high speed?

    The HW flaw was this:

    Both MCUs have the capability to reset each other from a GPIO.
    The GPIO (e.g. MCU1) pin is connected to a buffer which in turn is connected to the nRST (MCU2). 
    A pull-up is used on the outside of the buffer (used when the buffer is in tri-state) but not on the GPIO side! 
    Since the default setting for the GPIO is input with weak pull-down at power-up, then nRST is pulled low. 
    The SW controls the GPIO but that is not much of a help when we can't load the SW. Catch 22. ;) 
    That was the thing they missed when designing. An alternative solution would be to set the buffer in high-z at power-up. 

    Best regards,
    Lars

  • Guru 124030 points

    In reply to Lars von Wachenfeldt:

    Lars,

    Thank you for the opto recommendation and the additional details. One detail: I think you meant ISO7740.

    Cheers,
    Rafael

    When posting, click on the link Insert Code, Attach Files and more... to attach images, files or use nice formatting.

    If my reply answers your question please click on the green button "This resolved my issue".

    Search the wiki or go to useful pages for SDOWP, Compilers, CCSv3, CCSv4, CCSv5, CCSv6, CCSv7
  • In reply to desouza:

    Rafael,

    yes, you are absolutely correct, ISO7740 it is.

    Cheers to you as well!

    Lars