• State
  • Locked Locked
  • Replies 25 replies
  • Subscribers 30 subscribers
  • Views 5135 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.

TM4C1294NCPDT JTAG Error- Unable to access DAP

Akin
Prodigy 240 points
Other Parts Discussed in Thread: TM4C1294NCPDT, UNIFLASH, LMFLASHPROGRAMMER, EK-TM4C1294XL

I'm unable to program TM4C1294NCPDT on a custom board using XDS200 USB emulator. I continue to get error- 1170 @ 0x0 whenever I try to program the microcontroller. I have verified that the JTAG connection is correct - scroll down to see snapshot.

The JTAG scan test that I did came back without any error - see attached txt file. I don't really know to what extent to interpret the result. Not sure if it also indicates that the microcontroller is still functioning.

I thought I may have inadvertently locked up the JTAG port. So I decided to use Uniflash to unlock the port. This does not resolve the issue even though it showed a message that the process was successful.

I'm open to any suggestion or ideas at this point.

Thanks,

Akin

6567.Test Connection.txt 
[Start: Texas Instruments XDS2xx USB Emulator]

Execute the command:

%ccs_base%/common/uscif/dbgjtag -f %boarddatafile% -rv -o -S integrity

[Result]


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

C:\Users\akinboni\AppData\Local\TEXASI~1\
    CCS\ti\0\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 'xds2xxu.out'.
The library build date was 'May 21 2014'.
The library build time was '18:02:25'.
The library package version is '5.1.507.0'.
The library component version is '35.34.40.0'.
The controller does not use a programmable FPGA.
The controller has a version number of '13' (0x0000000d).
The controller has an insertion length of '0' (0x00000000).
This utility will attempt to reset the controller.
This utility has successfully reset the controller.

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

This emulator does not create a reset log-file.

-----[Perform the Integrity scan-test on the JTAG IR]------------------------

This test will use blocks of 512 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 512 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: Texas Instruments XDS2xx USB Emulator]

0447.Tiva TM4C1294NCPDT.txt 
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<configurations XML_version="1.2" id="configurations_0">
    <configuration XML_version="1.2" id="configuration_0">
        <instance XML_version="1.2" desc="Texas Instruments XDS2xx USB Emulator" href="connections/TIXDS2XXUSB_Connection.xml" id="Texas Instruments XDS2xx USB Emulator" xml="TIXDS2XXUSB_Connection.xml" xmlpath="connections"/>
        <connection XML_version="1.2" id="Texas Instruments XDS2xx USB Emulator">
            <instance XML_version="1.2" href="drivers/tixds560cs_dap.xml" id="drivers" xml="tixds560cs_dap.xml" xmlpath="drivers"/>
            <instance XML_version="1.2" href="drivers/tixds560cortexM.xml" id="drivers" xml="tixds560cortexM.xml" xmlpath="drivers"/>
            <property Type="choicelist" Value="0" id="The JTAG TCLK Frequency (MHz)">
                <choice Name="Fixed with user specified faster value" value="SPECIFIC">
                    <property Type="stringfield" Value="2.0MHz" id="-- Enter a value from 0.5MHz to 20.0MHz"/>
                </choice>
            </property>
            <platform XML_version="1.2" id="platform_0">
                <instance XML_version="1.2" desc="Tiva TM4C1294NCPDT" href="devices/tm4c1294ncpdt.xml" id="Tiva TM4C1294NCPDT" xml="tm4c1294ncpdt.xml" xmlpath="devices"/>
            </platform>
        </connection>
    </configuration>
</configurations>

  • 0
    TI__Guru**** 244380 points

    Hello Akin,

    The Test Connection Success indicates that the device is alive and resets have been released. It is a simple JTAG Bypass IR-DR test. However it does not mean that if the device is locked up, then device can be functionally accessed.

    UNIFLASH does not support XDS to Unlock (feature is pending implementation). The only method to unlock the device is using the Stellaris ICDI (either in UNIFLASH or LMFlashProgrammer)

    Regards

    Amit

  • 0 in reply to Amit Ashara
    Prodigy 240 points

    Amit,

    I had no luck unlocking the first board using LMFlashProgrammer with Stellaris ICDI. Tried multiple times but still got the same error.

    I was able to get my hands on a new board to program using Code Composer Studio 6 (CCS6).CCS6 appeared to have partially of fully programmed the board before giving an error shown in the screen shot below (It only shows this error on a new board).

    This appears to be a bug because my software is fully licensed. The same thing happened in the case of the first board. The second board started behaving the same way as the first board.

    It appears as if Code Composer Studio 6 is putting the microcontroller in a state that makes it unresponsive.

    First Error Screen Shot:

    Subsequent Error Screen Shot:

  • 0 in reply to Akin
    TI__Guru**** 244380 points

    Hello Akin

    Licensing issues can be resolved by Code Composer Studio Forum.

    Regarding the LMFlashProgrammer and Stellaris ICDI unlock of the device make sure that the following steps are done in the correct order

    1. Power Up the Board with Reset Pressed

    2. Run the Unlock Sequence for TM4C129 using LMFlashProgrammer while the Reset is pressed

    3. When the LMFlashProgrammer says to release the reset, only then release the reset

    4. Power Cycle the board and then try doing a Flash Blank Check

    Regards

    Amit

  • 0 in reply to Amit Ashara
    Prodigy 240 points

    Amit,

    Is it possible to send you a schematic to review in private?. I just want to have a second set of eyes take a look at the JTAG connection to see if there are any connection issues that I may have overlooked. It is a straight forward design hence not too complicated to get a quick feedback.

    Thanks,

    Akin

  • 0 in reply to Akin
    TI__Guru**** 244380 points

    Hello Akin,

    I use the EK-TM4C129 and DK-TM4C129 boards. The schematics are available on the TI website under the respective user guides.

    Regards

    Amit

  • 0 in reply to Amit Ashara
    Prodigy 240 points

    Amit,

    My assumption right now is that the problem is related to JTAG port locking up but that may not be the case.

    Here are sections of the design that I need second set of eyes on. I'd appreciate it if you can take a look at it and let me know if there are any concerns. J1 is the 10 pin ARM debug interface.

  • 0 in reply to Akin
    Prodigy 160 points

    Hello Akın,

    Your clock (TCK) seems to be connected to a pull-up resistor. That may be the problem.

    Have you ever had a chance to program the device, at least once?

    Best,

    Caner

  • 0 in reply to Caner Cuhac
    Prodigy 160 points

    Lowering the JTAG clock may help, as proposed in the error screen. Give TCK some time to recover from High state to Low. 10k pull up would strongly keep this signal up. You can try to desolder it.

  • 0 in reply to Caner Cuhac
    Guru 47900 points

    We note that PC2/TDI "floats" your most recent schematic.  Is that deliberate or wise?  Relying upon the JTAG probe to provide proper level signals - especially when you note potential issue - may not be best practice...

    Scope cap. of each/every JTAG signal - @ the MCU (not JTAG source) would prove useful.

    FWIW we've designed/built > 10K ARM boards - each/every bearing 10K pull-ups all 4 JTAG pins.  Note further that we've long moved to SWD (not possible under CCS) which saves 2 gpio.

    For completeness - ARMs spring from 4 vendors (mix of M0, M3, M4) - IDE is paid (multi-seat) IAR via J-Link JTAG probe.  Thus far (knock-on wood) JTAG/SWD issue free...

  • 0 in reply to cb1
    Prodigy 240 points

    CB1,

    The previous design that I did with Stellaris LM3S9D90 had 10K pull-ups on all 4 JTAG pins and it worked fine without issues. The current design is based on the EK-TM4C1294XL board:

    http://www.ti.com/ww/en/launchpad/launchpads-connected-ek-tm4c1294xl.html

    If ou take a look at the schematics for EK-TM4C1294XL, you'd see that only two JTAG pins are connected to 10K pull-up resistor (i.e. TCK and TMS).

    At this point I may try your suggestion to add pull-ups on all pins. The only concern is that Caner (in the post above) suggested that having a pull-up on TCK may be the cause of the problem. Do you have any comments on this?

    Thanks,

    Akin

  • 0 in reply to Caner Cuhac
    Prodigy 240 points

    Caner,

    I have not been able to program a board. The first attempt to program a new board appears to be going smoothly until CCS6 throws an error due to licensing issues - see screen shot in posts above. Subsequent attempts gives the "Unable to access DAP" error.

    What do you think about the suggestion from CB1? It seems to contradict your suggestion that the 10k pull-up on the Clock (TCK) may be the source of the problem.


    Thanks,

    Akin

  • 0 in reply to Akin
    TI__Guru**** 244380 points

    Hello Akin

    The schematics look fine. The fact that the JTAG Test connection is working means that the device is alive. The fact that you have never been able to get the program loaded (even once) would suggest that the External Crystal may be the cause (besides Pull Controls).

    Suggest removing the Crystal, it's cap and resistance and connect OSC0 pin to GND through a 1K pull down resistor and then attempting CCS Connect.

    Regards

    Amit

  • 0 in reply to Amit Ashara
    Prodigy 240 points

    Amit,

    I'll try out your suggestion later on today.


    Thanks,

    Akin

  • 0 in reply to Akin
    Prodigy 160 points

    If the EK schematics are working with pull-ups, and the EKs can be programmed properly via JTAG, it should be okay to do so. I think it is a good practice to stick with EK as reference design.

    I personally have designed a custom ARM board with JTAG pins directly connected to MCU (only #RESET pin is pulled up). It works perfectly. I have 20 pin JTAG and RTCK pin is floating.

  • 0 in reply to Caner Cuhac
    Prodigy 160 points

    Okay now I have found your problem.

    There is a 2k resistor between your 25MHz crystal and the OSC1 pin. That should not be there. Just remove it and directly connect to OSC1 pin. In here: http://www.ti.com/general/docs/lit/getliterature.tsp?baseLiteratureNumber=spmu360&fileType=pdf
     it is 0 ohm resistor.

  • 0 in reply to Caner Cuhac
    TI__Guru**** 244380 points

    Hello Caner

    I have been suspecting the same besides a dry solder on the PCB for the external crystal or a wrong Rs. That is why suggested removing the crystal altogether along with the Cap's and Resistors.

    Regards,

    Amit

  • 0 in reply to Caner Cuhac
    Guru 47900 points

    Caner Cuhac said:
    I personally have designed a custom ARM board with JTAG pins directly connected to MCU (only #RESET pin is pulled up). It works perfectly.

    I don't like - nor recommend this - at all - ever!  (strong message to follow)

    a) Minus normal/customary JTAG pull-up Rs - are you not fully/critically dependent upon the JTAG probe (each/every probe ever to be used - both now & future) to supply proper signal levels & edges?  In our 15+ years of JTAG/SWD usage - we've not found such "total" reliance - upon the JTAG probe - to be a good decision.

    b) Minus normal/customary JTAG pull-up Rs - do not those JTAG pins "float" when program/debug ends - and the board is placed into the field?  Is it normal/customary to enable MCU pins to float?  (especially those which potentially may "lock" your MCU - or otherwise cause the MCU to become vulnerable - then run amuck)

    Making any long-term decision based upon so limited a sample size ("designed a custom ARM board" does not sound especially comforting/convincing) thus may violate, "best practice."  (such small, unspecified "record of success" would cause serious investors to, "flee!")

    Note further that on > 50 occasions we've travelled to clients (3 continents) and "rescued" those who neglected JTAG Rs or employed "MCU's internal {most always high value} pull-ups - and suffered a multiplicity of issues - all cured via the installation of proper, external, pull-up Rs!  Those clear facts have convinced us - value and robustness of "real JTAG pull-up Rs - despite "individual/one/few-off protestations of, "it worked!"

  • 0 in reply to Caner Cuhac
    Prodigy 240 points

    Caner,

    I'd have to disagree with you on setting the 2K  resistor to 0. There are recommended values for this resistor and it varies based on the manufacturer of the crystal - see snapshot below. You can get more information on Page 1840 of the datasheet:

    http://www.ti.com/lit/ds/symlink/tm4c1294ncpdt.pdf

    The document you referenced belongs to a different chip. The correct document is:

    http://www.ti.com/lit/ug/spmu365a/spmu365a.pdf

    The good thing about your observation was that I discovered that the value of the resistor that I should have used is 2.5K. I must have misread that section when I was doing the design of the board.

    Here are three things that I've been able to gather from previous discussions:

    1) Missing pull-ups on JTAG pins.

    2) Bad crystal or bad solder joint.

    3) Wrong value selected for the resistor that is placed in series with the crystal

    I'll try to investigate further tonight to see if any of the above is the root cause of the problem.

    Thanks,

    Akin

  • 0 in reply to cb1
    Prodigy 160 points

    @cb1: The MCU that I used had its own internal pull-up resistors:

    If these guys would think that external resistors should always be used, or it would be too risky to rely on internal pull-ups; they would not build their JTAG interface this way. Otherwise the investors would "flee".Anyway, I do not claim that this or that is best practice. I just said that it worked for me.

  • 0 in reply to Akin
    Prodigy 160 points

    @Akın:

    Sorry that I was looking to wrong pdf. Your design seems exactly like the EK so I think it is okay.

  • 0 in reply to Caner Cuhac
    Guru 47900 points

    Caner Cuhac said:
    it would be too risky to rely on internal pull-ups; they would not build their JTAG interface this way.

    Really - if you have such faith in, "these guys" or many/most other ARM vendors - how do you account for the massive amount of errata?  (here & elsewhere!)

    Have you looked at the value of the MCU's pull-up Rs?  They're high - and may result in reduced signal levels and/or slowed signal rise times.  And - what happens if - inadvertenly - those pins are repurposed? 

    As everything critical is likely to revolve upon successful JTAG/SWD operation - use of such "weak pull-up Rs" is a concession to, "user convenience" - and we believe a poor one...  (this not a knock upon this vendor - we use multiple ARMs - multiple vendors - and always employ proper, external pull-ups.)

    The cost/size of 4, 06-03 smt resistors places the, "risk-reward" equation far to your advantage. Makes little sense to, "seek such savings!"

    Readers of your post should be warned - what (once) worked for you - opens them to much pain/suffering!  (note your original post made no mention of internal pull-ups - it suggested that NO pull-ups had worked!)

  • 0 in reply to cb1
    Prodigy 240 points

    Amit,

    I tried your idea and still got the same result. You said I should connect OSC0 pin to GND through a 1K pull down resistor. OSC1 was left floating. Let me know if you have any other ideas.

    I also tried adding 10K pull-up resistors on the 4 JTAG lines but still could not program the board.

    Thanks,

    Akin

  • 0 in reply to Akin
    Guru 117850 points

    That's not good - but do trust that those added, external pull-ups - heighten & speed your chances for eventual success.

    Loss of JTAG/SWD is always frustrating - beyond the, "Other Utilities/Debug Port Unlock" there exists a rather detailed "sticky" (atop this forum & wasteland (pardon, Stellaris forum) which provides a "laundry list" of JTAG gremlins.

  • 0 in reply to Akin
    TI__Guru**** 244380 points

    Hello Akin,

    The connections are right that you made to remove the Main Crystal. I am really out of ideas as the Oscillator would have been the suspect at this point. Also having put the Pull Up is not helping.

    And the issue happened the first time you tried to Flash the code via CCS. Just to confirm it never even once Flashed the code and these are still fresh parts from Factory?

    Regards

    Amit

  • 0 in reply to Amit Ashara
    Guru 117850 points

    As this is a low volume, custom board "everything" is suspect.  By chance - did you design/build several?  (that's always a good idea - enables "A-B-C" style testing)

    Amit's well guided - time now for "each/every MCU power pin, then Reset, then 3V3 regulator" in depth visual & metered inspection.  Not fun - not quick.  We find that unless you've over-voltaged/ESD'ed the MCU - they're hearty beasts - we had a client's board (on a vessel) catch fire - the MCU still worked!  (looked like hell, though...)