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.

Updating from CCS 5.4 to 5.5 and updating XDS 560STM driver leads "Device ID is not recognized"

Other Parts Discussed in Thread: UNIFLASH, TM4C1231D5PM, TM4C123BE6PZ

Updating from 5.4 to 5.5 seemed to work, with no errors.  I updated the compiler to 5.1 also.

Now when I try to emulate I get the message;

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.73.0)

Any ideas on what I need to change to get back to where I was before the update?

Further background:

Using CCS UniFlash on the same target setup works.

When I open the .ccxml file  and use "Test Connection" button,  there are no errors:

[Start]

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\osenjw\AppData\Local\.TI\693494126\
    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 'sd560v2u.out'.
Loaded FPGA Image: C:\ti\ccsv5\ccs_base\common\uscif\dtc_top.jbc
The library build date was 'Aug 19 2013'.
The library build time was '22:41:20'.
The library package version is '5.1.229.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 '5' (0x00000005).
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 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.
Loaded FPGA Image: C:\ti\ccsv5\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    512  - 01 00  500.0kHz   O    good value   measure path length
    4    128  - 01 00  500.0kHz   O    good value   auto step initial
    5    128  - 01 0D  601.6kHz   O    good value   auto step delta
    6    128  - 01 1C  718.8kHz   O    good value   auto step delta
    7    128  - 01 2E  859.4kHz   O    good value   auto step delta
    8    128  + 00 02  1.031MHz   O    good value   auto step delta
    9    128  + 00 0F  1.234MHz   O    good value   auto step delta
   10    128  + 00 1F  1.484MHz   O    good value   auto step delta
   11    128  + 00 32  1.781MHz   O    good value   auto step delta
   12    128  + 01 04  2.125MHz   O    good value   auto step delta
   13    128  + 01 11  2.531MHz   O    good value   auto step delta
   14    128  + 01 21  3.031MHz   O    good value   auto step delta
   15    128  + 01 34  3.625MHz   O    good value   auto step delta
   16    128  + 02 05  4.313MHz   O    good value   auto step delta
   17    128  + 02 13  5.188MHz   O    good value   auto step delta
   18    128  + 02 23  6.188MHz   O    good value   auto step delta
   19    128  + 02 2D  6.813MHz  {O}   good value   auto step delta
   20    512  + 02 0D  4.813MHz   O    good value   auto power initial
   21    512  + 02 1D  5.813MHz   O    good value   auto power delta
   22    512  + 02 25  6.313MHz   O    good value   auto power delta
   23    512  + 02 29  6.563MHz   O    good value   auto power delta
   24    512  + 02 2B  6.688MHz   O    good value   auto power delta
   25    512  + 02 2C  6.750MHz   O    good value   auto power delta
   26    512  + 02 2C  6.750MHz   O    good value   auto power delta
   27    512  + 02 20  6.000MHz  {O}   good value   auto margin initial

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

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

In the scan-path tests:
The test length was 16384 bits.
The JTAG IR length was 4 bits.
The JTAG DR length was 1 bits.

The IR/DR scan-path tests used 27 frequencies.
The IR/DR scan-path tests used 500.0kHz as the initial frequency.
The IR/DR scan-path tests used 6.813MHz as the highest frequency.
The IR/DR scan-path tests used 6.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 5.993MHz.

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 512 32-bit words.

The test for the JTAG IR instruction path-length succeeded.
The JTAG IR instruction path-length is 4 bits.

The test for the JTAG DR bypass path-length succeeded.
The JTAG DR bypass path-length is 1 bits.

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

  • This is a device driver issue. Try uninstalling the drivers and load them again. 

    Regards,

    Gautam

  • This issue is now cancerous in our development.

    Of four target types, three remain unscathed, the fourth, well nothing seems to get us back to square one...

    1. Roll back our code to last working version
    2. Uninstall the XDS560v2 drivers
    3. Uninstall CCS 5.4
    4. Reinstall CCS 5.4
    5. Create a new CCS workspace
    6. In new workspace create the default empty main program
    7. Try to emulate and get the same result.  This is on HW that was working splendedly for months.
    8. Swap in different physical units of target HW
    9. Delete all cached data
    10. Start CCS with -clean argument
    11. Try on second work station (but after updating CCS UniFlash) with second XDS560, different cables
    12. Reboot computer
    13. Cycle power to emulator, target and computer
    14. We have tried emulating/UniFlashing on 24x different target controllers.  Six work.  Of the other 18, about 8 were actually programmed by UniFlash, then went into the state where the device ID was not recognized.

    It seems like at some point the target hardware looses it device information.

    How do you see what device ID the emulator is getting?

     And how do I know what device ID the emulator should be getting?

  • Hi,

    I don't think you'll be able to check the device ID using any tool. But atleast Uniflash is able to interact with your device, right?

    Regards,

    Gautam

  • Thanks for answering.

    I updated the SD drivers from the Help -> Install New Software menu, no change

    In UniFlash I get the same issue, but...

    There were about eight controllers where UniFlash connected and downloaded an image once.  On a couple of those units I was looking at the device's LCD screen and saw the expected 2 sec splash screen stating program status.  On all devices that did program via UniFlash then went dead, power cycling does not help.

    Unfortunately the devices with problems are all wireless devices.  The only indications of normal operation are the splash screen, an LED that should blink, and a wireless address claim.  None of these occur once the device can no longer be connected to.

    If you power off the device, then either CCS or UniFlash complains about no power.

    The processor is a TM4C1231D5PM.  On a different implementation, we use that same chip.  I tried once to connect to that other implementation and was able to connect.  I did not dare try a second time, as that board is the only one I have.  I tried connecting with CCS on two other implementations using a TM4C123BE6PZ with no problem.

  • Did you try to check on any other PC?

  • Failing on two.  However, both had recently updated software for the emulators.  Will check with third engineer's setup without updates this morning.

  • Tried on a third engineer's desk with his cables, his emulator and his CCS 5.4 without updates and found the same issue.

    It seems that touching a controller with UniFlash has messed up the controller.

    Is there another utility that can erase erase flash?

    In the test connection output screen, output indicates sd560v2u.out is loaded.  No error is reported, and success in not reported either.  What is the command that loads this file?  I would like to try loading, via the' test connection',  a simple file with a forever loop.

  • We did resolve the problem.  We used an TI TiVa launch pad as an emulator to interface the target board to LM_Flash.  Using this we erased the FLASH.  This left the boards in a state were we could connect with them through CCS.  I downloaded the debug version of the SW and we were ready to roll.

    I request that an erase flash function be added to either the .ccxml editing page or to CCS itself.  Or LM_FLash be modified to support additional emulators.

    I know that using UniFLASH, I was downloading the release version of the code, which has only the debug flag cleared.  This is what we did on a sister product a few months back with no issue.  Ironnically, I recently posted a question on the difference between generated code with debug flag on and off.  I will try to recreate the failure tomorrow.

  • Well Done, John.

    Congrats and Cheers,

    Gautam

  • Hi John,

    Im currently experiencing a very similar problem with a custom board. CCS cannot connect to the device (Error -1063 - Device ID not recognised) & LM Flash doesn't 'see' the MPU either.

    Could you please run me through how you used the launch pad to interface to the processor? Please excuse my ineptitude with this, I'm totally new to the TM4C & CCS.

    Thanks in advance,

    Alex

  • I am not the engineer that actually modified the HW.  But our boards still had the JTAG connector populated.  We took the 2x5 (or whatever) connector and soldered flying leads to the appropriate pins on the launch pad.  We then brought up LM Flash, connected to the device and cleared FLASH.  It was a pretty ugly looking little setup, but it worked.