• State TI Thinks Resolved
  • Locked Locked
  • Replies 11 replies
  • Answers 5 answers
  • Subscribers 66 subscribers
  • Views 2724 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Creating UCD3138 project in CCS6.1 for XDS100V2 debugger

Torsten Dreisbach
Prodigy 50 points
Other Parts Discussed in Thread: UCD3138, UCD3138CC64EVM-030, UCD3138A64, UCD3138A, UCD3138064, UCD3138OL64EVM-031, UCD3138064EVM-166

Hello,


I am just starting with digital power and want to try the UCD3138. I have a UCD3138CC64EVM-030 and a XDS100V2 debugger. Now I installed the latest CCS and asked a software guy to help me setting up the connection. But there seems to be no way to select UCD3138 together with XDS100V2.

On the XDS100V2 product page, the UCD3138 is listed. So I would expect that I can at least program that device with the XDS100V2. Why am I not able to create a configuration for the two?

Any help would be appreciated.

Thank you

Torsten

  • 0
    Prodigy 60 points
    I am try to do the same thing, I have xDS100v2 and UCD3138A64, yesterday I find Linux CCS6.1 can select xds100 for ucd3138, but I am not able to download my program, may be configuration problems, I still working on it.
  • 0 in reply to Snaku Lee
    Prodigy 50 points

    After your post I looked into the installation of 6.1 on a different PC. I can also select the combination on that PC - do not know why this is different there.

    Creating a configuration file and trying to test the connection ends up in an error. I do not know why the demo should have a problem after the 12V externally is applied. So I would also think that there is an issue in the settings.

    The XDS100V2 makes a difference in the error on powered Controller or missing external 12V. So the JTAG does do something. Unfortunately not what I want...

  • 0
    Prodigy 90 points
    I'd love to hear an answer/update on this. Currently trying to get UCD3138A and an XDS2xx USB Debug Probe talking as well. Everything connected and passes through a core reset, but then fails out with a :
    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.

    Hoping Ian or someone can chime in. When selecting the 3138A I swear the datasheets or manuals had said that the XDS2xx should now have support w/n CCS 6.1
  • 0 in reply to Daniel Havener
    TI__Genius 17090 points

    I'm working on coming up to speed myself on the XDS100, so I hope I'll be helpful shortly on those. 

    I'm already up to speed on the XDS200, but it's not good news - we do not support the XDS200.

  • 0
    TI__Genius 17090 points
    I have a couple of suggestions:

    1. You need at least CCS 6.1. Click on Help->Installation Details. Digital Power device support should be at least Version 1.1.1.
    If it's not, Click on help->Check for Updates. Check at least the Digital Power device support, and upgrade
    2. With the UCD3138, starting in ROM mode, you need to clear the IOMUX register. The UCD3138 powers up with the JTAG disabled, even in ROM mode. Other family members power up in ROM mode with JTAG enabled. Note that all UCD devices keep the JTAG disabled if the flash checksum is valid and they go directly to the flash program from power up. This is done for customer code security. So if you want to power up with the checksum for debugging and go to JTAG, your program needs to clear the IOMUX, or at least the JTAG bit in the IOMUX.

    To clear the IOMUX in ROM mode, use the memory debugger in the UCD3138 device GUI.

    To learn about the memory debugger, see the videos in the UCD3138 video training area.

    training.ti.com/ucd3138-digital-power-training-series

    There are also some JTAG videos on there which are mostly oriented to the XDS510.

    I just installed the XDS100 for the UCD3138064, and it was very straightforward.
  • 0 in reply to Ian Bower
    Prodigy 90 points
    Thanks! I will just go this direction. (Hopefully) Last question: specifically for a UCD3138ARMHT, which (or all?) of the XDS100v2 will work with the above instructions?
    TMDSEMU100V2U-14T
    TMDSEMU100V2U-20T
    TMDSEMU100V2U-ARM
    I'm assuming (but already got me once!) that because the UCD3138A has a ARM7TDMI-S core, that I should go with the last one - TMDSEMU100V2U-ARM?
  • 0 in reply to Daniel Havener
    TI__Genius 17090 points

    It's good not to assume.  In this case, you want the 14T, since our EVMs and open loop boards use the TI 14 pin connector configuration. 

  • 0 in reply to Ian Bower
    Prodigy 90 points

    Ian,

    Finally got the XDS100V2 (14pin version).  I'm still stymied though. When trying to "test connection" within CCS6.1, I get the following:

    ....[previous setup and config of the Emulator]......

    -----[Perform the standard path-length test on the JTAG IR and DR]-----------

    This path-length test uses blocks of 64 32-bit words.

    The JTAG IR instruction path-length was not recorded.

    -----[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

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

    This error is generated by TI's USCIF driver or utilities.

    The value is '-183' (0xffffff49).
    The title is 'SC_ERR_CTL_CBL_BREAK_FAR'.

    The explanation is:
    The controller has detected a cable break far-from itself.
    The user must connect the cable/pod to the target.

    So, I've 2nd and 3rd checked my cabling, as we are force to get the 14 pin connection down to a 10 pin header (for legacy purposes). Mapping each of the following: TCK, TDI, TDO, TMS, VREF, GND, RESET.

    I've pulled the schematic from the EVM used in the tutorials (UCD3138OL64EVM-031). Schematic looks just about right, except for the fact that it looks like for that EVM they tie RESET to ground ; through a 10K resistor. I've actually got a different EVM from the family (UCD3138064EVM-166). And in that schematic, it looks like they just leave RESET unconnected.  

    I've tried all 3 methods. Each ended with the "Test Connection" routine bombing out at the same place (as shown above).  I'm at my wits end, and really afraid that the UCD3138ARMHT we are on is / or has gotten itself into the JTAG disabled mode??  Could this have happened out of the factory? I've seen/read many places about the IOMUX register/bit and having to clear it. But it seems like all references to doing that are talked about through the PMBUS protocol/connection.  Which (of course) we do NOT have available.

    Please help!  (and thanks!)

  • 0 in reply to Daniel Havener
    TI__Genius 17090 points

    Here's a file with a list of steps to try for installing the JTAG:

    css-one-click-download-debug.pdf

  • 0 in reply to Ian Bower
    Prodigy 90 points
    Wonderful guide!! This was a deep dive and description of lots of the JTAG / Debug setup options. It worked, but I'd add one additional detail.

    The Labs have this snip of code at the top of main{}
    //---------------------------------------------------------------------------
    // IMPORTANT: READ BELOW, OR CODE MAY NOT EXECUTE CORRECTLY
    //---------------------------------------------------------------------------
    // tie pin FAULT3 to ground for normal operation
    // tie pin FAULT3 to 3.3V to clear checksum
    if(GioRegs.FAULTIN.bit.FLT3_IN == 1)
    {
    //clear_integrity_word();
    }

    I had to (for now) disable the clear_integrity_word() function call. Stepping into, or over, this function call results in a jump into unknown memory locations and halt of the core (UCD3138064). So, digging into this I find (in software_interrupt_wrapper.c: 83):

    void clear_integrity_word()
    {
    swi_single_entry(0,0,0,12);
    }

    Digging into what this is doing now, and will update (unless someone beats me to it). What I don't like with just tieing the pin FAULT3 to ground is that the same call can be made by pmbus function(s), so I'm afraid I'm sitting on a crash-bug without understanding what it does (or is trying to do).
  • 0 in reply to Daniel Havener
    TI__Genius 17090 points
    You're right that we should add this. We've had another customer have the same issue, so 2 is probably a crowd.

    That code is designed to set the checksum in the program flash to a zero. This is useful because the ROM calculates a checksum for various areas in the program flash, which vary from part to part. If the checksum is valid, it jumps to the flash at location zero and starts executing. If you want to go back to ROM mode to download new code, you have to clear the checksum and reset the part.

    Normally we do this via the PMBus commands, but in the development cycle, it's easy to screw up the PMBus, say by putting in an infinite loop or getting stuck in an interrupt or something. So we put in what we call a hardware backdoor like what you have just commented out. It's at the beginning of the code, before interrupts are enabled, and it depends on just an I/O line, rather than PMBus hardware. Of course it's also possible in development to screw up the checksum clearing code as well, but it's less likely.

    So don't program the checksum until you've tested the clearing for that specific version of the code.

    The program flash returns FFs if you try to read it while it's being programmed, so the clear checksum software interrupt has to copy the relevant code into RAM and execute from RAM while the checksum is clearing. I'm not sure if that is what is crashing the JTAG, or if it's the assembly language code inserted into the start of the software interrupt to disable the interrupts - or something else, but the checksum clearing definitely crashes the JTAG.