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.

TMX320C6474 JTAG Problem

Other Parts Discussed in Thread: TMS320C6474, CCSTUDIO, DM3730

When I use TMX320C6474 REV.1.2 on my design board, I found that :

Jtag emulator can't find the DSP core when there is no clk on ddrrefclkp and ddrrefclkn pin.

Once I sold on the oscillator, emulator could find the dsp core.

I do this again on TMDXEVM6474, I got the same result.

But I didn't find anything about this in datasheets, why is  DDRREFCLKP and DDRREFCLKN required for JTAG to work properly?

  • I see no mention of these pins needing to be connected for the device to function properly, so from my perspective they should not be needed for JTAG either. I will check around to see if I can find any reason this might fail, but in the meantime please double check that soldering on an oscillator and connecting it to those pins is not impacting the connection of any other pins.

    Also, please let me know what specific error message you see as this might be useful in determining the issue.

  • Which boot mode are you using?

    There is no direct reason for this requirement, but the DSP cores must be able to successfully come out of reset before JTAG can communicate with them correctly.

    It may help when you show Tim the exact error message you get.

    But in the end, you need to have the oscillator for the DDR anyway, right? Is this needed for your application, or not? If not, there may be power-down considerations that you need to take care of to make sure the DDR is not affecting the DSP cores.

  • This is a suggestion from one of the folks in the factory:

    In the TMS320C6474 Hardware Design Guide (SPRAAW7) we state:"If the DDR2 peripheral is disabled, all interface signals (including reference clocks) can be left floating and the input buffers are powered down." I'd assume that you shouldn't connect PLL2 power in addtion (even if that's not explicetly mentioned in the HW Design Guide). PLL2 power pins are AVDD218 / AVDD118.
    You can find this note in section 7.9.1 on page 32.

    Another thought: do you have any code that's attempting to access the DDR2 module when the clocks are disconnected or anything like that (e.g., GEL file, configuration code, etc.)?

  • Thans for your advice.

    Soldering EMI filter(NFM18CC223) is too hard for me, so I didn't do the test.  Anyway DDR2 is used in my design, so I just solder the oscillator on.

    I just use the gel file from EVM6474 board , because  I can't find  c6474.gel in D:\CCStudio_v3.3\cc\gel\ . Will this be the problem?

    And I've got another question:

     2 of 5 boards still can't find the JTAG chain,  I didn't got clk on the SYSCLKOUT(AD6 pin) . The power for the DSP is OK, and clk for PLL1 and PLL2 is applied properly, what should I  check next? (The other 3 boards works properly in same design) The error message returns from CCS:

    Error connecting to the target:
    Error 0x80000240/-1146
    Fatal Error during: Initialization, OCS,
    Invalid data was scanned by the emulation controller.
    Verify the board setup to make sure the scan chain is properly
    defined.
    If the setup is correct, then RESET EMULATOR.  This will disconnect each
    target from the emulator.  The targets should then be power cycled
    or hard reset followed by an emureset and reconnect to each target.

    another error message:

    Error connecting to the target:
    Error 0x80002240/-230
    Fatal Error during: Initialization, OCS, Control,
    This error was generated by TI's USCIF driver.

    SC_ERR_PATH_MEASURE <-230>
    The measured lengths of the JTAG IR and DR scan-paths are invalid.
    This indicates that an error exists in the link-delay or scan-path.

    Thanks!

     

     

  • chenhao1st said:

    I just use the gel file from EVM6474 board , because  I can't find  c6474.gel in D:\CCStudio_v3.3\cc\gel\ . Will this be the problem?

    The GEL file that comes with the EVM6474 will be the right one to use, although you may need to modify it slightly to match your own board design. Primarily, the GEL file will configure hardware features of the C6474, such as PLL ratios, sub-module power/config, DDR2 EMIF, and the CCS memory map. For your own board, some of these settings will be different. For example, you may be using a different size of DDR memory or may have a different input clock frequency. Also, the EVM GEL will probably turn on everything inside the chip, and you may want to have some sub-modules turned off. Read through the GEL file, look up the different commands in the CCS Help menu so you understand what it is doing, then you will be able to customize it to your hardware design.

    chenhao1st said:

    2 of 5 boards still can't find the JTAG chain,  I didn't got clk on the SYSCLKOUT(AD6 pin) . The power for the DSP is OK, and clk for PLL1 and PLL2 is applied properly, what should I  check next? (The other 3 boards works properly in same design) The error message returns from CCS:

    This is very exciting that you have 3 of the 5 boards working now. This validates 99% of the C6474 portion of your design. The remaining 2 boards can be debugged by comparing signals on a working board with those on a failing board. As an example, the fact that you do not get a clock signal on SYSCLKOUT means that you do not have basic functionality on your board for the operation of the C6474. Even though it is common to conclude that there is something wrong with your C6474, this is not usually the best path to go through first. The most likely problem is board manufacturing and the only way to figure it out is to look at every one of the vital signals

    This is a short list of steps you could take. There are more ideas in the C6474 Hardware Design Guide spraaw7.

    • Where possible, visually inspect the solder connections for breaks, bad solder joints, and shorts. Excess solder flux can cause coupling of high-frequency signals.
    • Verify the right amount of power supply current is being drawn (inverse smoke test). See spraaw7 for some power supply estimation assistance.
    • Check the power supplies to everything you are testing, and the clocks, and the resets.
    • Use an oscilloscope to look at
      • clock inputs,
      • clock outputs,
      • reset signals,
      • configuration line states at the time the reset signal(s) goes high,
      • power supply noise levels, and
      • JTAG signal integrity.
    • Verify that all signals look the way the datasheet says they should.

     

  • Dear,

    I am trying to connect the XDS560v2 STM debugger with my customized DM3730 board and got the same problem as mention above.

    My error message is: 

    -----[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 ONE on its EMU[0] input pin.
    The controller has a logic ONE 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.

    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 or utilities.

    The value is '-230' (0xffffff1a).
    The title is 'SC_ERR_PATH_MEASURE'.

    The explanation is:
    The measured lengths of the JTAG IR and DR scan-paths are invalid.
    This indicates that an error exists in the link-delay or scan-path.

    [End]

    I have check the JTAG's signal integrity and things are normal.

    Could you suggest me some work around, pliz?!

    Thank you!

  • David,

    You have attached to a 3 year-old thread that has been answered. If that answer is not what you were looking for, please post a new thread instead of attaching to this old thread.

    Post the new thread to the Code Composer Forum under the Development Tools support group. That is the correct place to get emulation questions addressed. When you post there, please include all the relevant information that is missing here, such as CCS version and a description of your target configuration file.

    Regards,
    RandyP

  • Finally I chaged my cpu from c6474 to c6487(same pin as c6474) and the problem solved. So I just doubt that's the bug of the cpu or CCS. Suggest you ask this question in CCS board.