• State Resolved
  • Locked Locked
  • Replies 12 replies
  • Subscribers 31 subscribers
  • Views 2305 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

UniFlash Error 1170 on Custom Board with TM4C123GH6ZRB

snellr
Intellectual 715 points
Other Parts Discussed in Thread: UNIFLASH, TM4C123GH6PM, TM4C123GH6ZRB, LMFLASHPROGRAMMER

Hello,

I'm using UniFlash v3.1.0.00026 in Win8.1 and the XDS100v2 (ARM).

I can use the XDS100v2 to program ("Debug-In") the target mcu on a TM4C123GH6PM Launchpad, but when I apply it to my custom board which has a TM4C123GH6ZRB I am getting a variety of errors.  

Here is my ccxml: 

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<configurations XML_version="1.2" id="configurations_0">
<configuration XML_version="1.2" id="Texas Instruments XDS100v2 USB Emulator_0">
<instance XML_version="1.2" desc="Texas Instruments XDS100v2 USB Emulator_0" href="connections/TIXDS100v2_Connection.xml" id="Texas Instruments XDS100v2 USB Emulator_0" xml="TIXDS100v2_Connection.xml" xmlpath="connections"/>
<connection XML_version="1.2" id="Texas Instruments XDS100v2 USB Emulator_0">
<instance XML_version="1.2" href="drivers/tixds100v2cs_dap.xml" id="drivers" xml="tixds100v2cs_dap.xml" xmlpath="drivers"/>
<instance XML_version="1.2" href="drivers/tixds100v2cortexM.xml" id="drivers" xml="tixds100v2cortexM.xml" xmlpath="drivers"/>
<property Type="choicelist" Value="2" id="The JTAG TCLK Frequency (MHz)"/>
<platform XML_version="1.2" id="platform_0">
<instance XML_version="1.2" desc="Tiva TM4C123GH6ZRB_0" href="devices/tm4c123gh6zrb.xml" id="Tiva TM4C123GH6ZRB_0" xml="tm4c123gh6zrb.xml" xmlpath="devices"/>
</platform>
</connection>
</configuration>
</configurations>

I keep getting errors -121, -1170, and -1063 in any order when I try to access the mcu to program it:

CORTEX_M4_0: Error connecting to the target: (Error -121 @ 0x0) A bad controller handle has been given to a function, either before attempting to open the controller, or after having opened the controller and ignored its error status. Valid controller handles are generated when attempts to open the controller return a clean error status. (Emulation package 5.1.507.0)

CS_DAP_0: Error connecting to the target: (Error -1170 @ 0x0) Unable to access the DAP. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 0.0.0.0) 

CORTEX_M4_0: Error connecting to the target: (Error -1063 @ 0x0) Device ID is not recognized or is not supported by driver. Confirm device and emulator configuration is correct, or update device driver. (Emulation package 5.1.507.0)

I have used a serial sniffer to confirm that RESET is staying high, and that TDI, TDO, TMS and TCK are all toggling, though I don't have the expertise to analyze the protocol.  (I could send complete serial snapshots f needed.) Supply voltage is a well-regulated 3.3V for the mcu.  

Here is a 300 kB UniFlash Log which reflects error -1170: 5241.5466.UniFlashLog.log

Here is a UniFlash Log which reflects error -121: 7317.1440.UniFlashLog_121.log

Here is a UniFlash Log which reflects error -1063: 4645.8540.UniFlashLog_1063.log

Any tips?  Thanks.

  • 0
    Guru 86755 points

    snellr said:
    I can use the XDS100v2 to program ("Debug-In") the target mcu on a TM4C123GH6PM Launchpad, but when I apply it to my custom board which has a TM4C123GH6ZRB I am getting a variety of errors.  

       As loading program works for Tiva Launchpad, you need to check what is particularly different in circuitry at your custom board that might be causing these problems.

    - kel

  • 0 in reply to Markel Robregado
    Intellectual 715 points

    Maybe someone can help me debug.  I am trying to take steps toward the solution.  I removed the TM4C123GH6PM (U1) from the Launchpad and placed it onto a breadboard.  After making connections from the breadboard to the Launchpad for all the Vdd, Vbat, Vddc, Gnd,  Rst, and 4 jtag connections, I am unable to run CCS in the debugger as if the chip were still on the Launchpad.  The console message "CORTEX_M4_0: Error connecting to the target" comes up.  Is this a length of wire thing, or are there other critical connections that I have overlooked?

    (I have even connected the UART0, wake, hibernate, and 16MHz crystal connections to my breadboarded Tiva, but still no luck.)

  • 0 in reply to snellr
    Intellectual 715 points

    Taking it back another step...

    If the 16 MHz crystal Y1 is removed from a Launchpad, the same on-board ICDI can no longer connect to the on-board U1 mcu.

    Is this spelled out in the datasheet for the TM4C1236GHPM somewhere?  All I see is that the mcu has an internal PIOSC at 16MHz which should be sufficient for basic operation (not USB) .  Why doesn't the JTAG work without the external crystal?

    (I"m going to copy this post over into the Tiva forum, since the present question belongs there.)

  • 0 in reply to snellr
    Intellectual 715 points

    The crystal-less problem is solved in this post: http://e2e.ti.com/support/microcontrollers/tiva_arm/f/908/p/376258/1323907.aspx#1323907.

  • 0 in reply to snellr
    Intellectual 715 points

    I'm reopening this thread because I have a bit of additional information.

    I have been able to successfully connect to my custom board (which has TM4C123GH6PM) twice now.

    I disconnected and then successfully connected a second time.  With this second connection, I loaded some firmware (which does not use PC0-3).  After loading, the JTAG lost connection (which might be normal/ok--might have been due to a clock configuration problem in the firmware).

    Every attempt since then, however, I have been unable to even connect to the device.  I have performed the UNLOCK procedure in UNIFLASH multiple times.  OSC0 is grounded, VDDC has proper cap values, and nRST is pulled high. I am getting errors -121, -1170, and -1063.  The "Test Connection" utility in CCS still says everything checks out fine, just as it did before I was actually able to connect.

    Does anyone have ideas about why I seem to be locked out?

  • 0 in reply to snellr
    Intellectual 715 points

    More info:

    On the first connection attempt after powerup (whether or not I assert nRST on powerup), I get Error -1063 on the first connection attempt every time.  If I hit the Retry button in the popup window of UNIFLASH with power maintained on the device, then I get Error -121.  Every time I hit the Retry button, I get Error -121 again.  If I hit Cancel (in the error popup) and initiate a new attempt to connect to the device, then I get Error -1170.  Hitting the 'Retry' button in the error popup results in Error -1170 consistently ever after.

  • 0 in reply to snellr
    TI__Guru**** 244400 points

    Hello Snellr

    It could be a clocking issue which may have got the device locked out. However the UNIFLASH should have recovered the device. The UNIFLASH or LMFlashProgrammer cannot check if the device is unlocked till the next power cycle. So it would always "Pass".

    Can you reconfirm the steps for unlocking the part?

    Regards

    Amit

  • 0 in reply to Amit Ashara
    Intellectual 715 points

    Sure.  

    With XDS100v2 plugged in ...

    1. Assert nRST and keep asserted.
    2. Power up device.
    3. Press 'Unlock' in Uniflash.
    4. Wait for script in Uniflash.
    5. Release Reset on device.
    6. Press 'Finish Unlock' in Uniflash.
    7. Wait for script in Uniflash.
    8. Remove power from device.
    9. Reapply power to device.
  • 0 in reply to snellr
    Intellectual 715 points

    XDS100v2 connections include:

    mcu > > >XDS100v2

    nRESET > 3" wire > 6" ribbon cable > XDS100v2 nRESET (with 10k pullup inserted between the 3" wire and the 6" cable)
    VDD > 100 ohm res > XDS100v2 VTRef
    GND > GND
    TDI > 4" wire > 6" ribbon cable > XDS100v2 TDI
    TDO > 4" wire > 25 ohm res > 6" ribbon cable > XDS100v2 TDOTMS > 4" wire > 6" ribbon cable > XDS100v2 TMS (with 10k pullup inserted between the 4" wire and 6" cable)
    TCK > 4" wire > 22 ohm res > 6" ribbon cable > XDS100v2 TCK (with 10k pullup inserted between the 22 ohm res and 6" cable)

    Like I said, it programmed once with these configurations.  Is it possible that the Unlock feature is more picky about some connection that is edgy above?

  • 0 in reply to snellr
    Intellectual 715 points

    I believe I can confirm that it is not a lock-out issue.  I was able to put the same firmware on a Launchpad which didn't have a crystal (like the custom board I have).  The firmware didn't run properly of course, but subsequently, I was able to use LM Flash Programmer to simply load different firmware without needing to unlock the device.

  • 0 in reply to snellr
    Intellectual 715 points

    I hooked up my custom board OSC0 and OSC1 to the 16 MHz crystal on a Tiva 123 Launchpad, and my code (which I mentioned that I had succeeded in downloading to my device) started running as designed.  (Fine, whatever.) Then I plugged in the XDS100v2 and it connects and debugs just fine, too.  

    This leads me to believe that perhaps the no crystal configuration of the mcu is not supported fully in Uniflash and/or CCS and/or Tiva jtag connectivity.   Btw, I had tried a much lower connection speed (100 kHz) without the crystal before and it had failed, too.

    For the purposes of my dev, I'm going to call this forum answered and simply pursue integrating a crystal into my design.  However, I would think that this might want to be investigated on the TI/UniFlash/Tiva side.

  • 0 in reply to snellr
    TI__Guru**** 244400 points

    Hello snellr,

    The unlock sequence starts with power supply being ramped while the reset is pressed. At this point the crystal cannot start, hence not having a crystal is not the issue for UNIFLASH not to work.

    The JTAG frequency of 100K not working either would mean that somehow the configured device system frequency was way below 1MHz (at least) that could be causing a general debug issue. Why? because you were able to load and debug code with OSC0 GND, which would also imply that "may be" system clock configuration was incorrectly applied.

    Regards

    Amit