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.

CCS/EK-TM4C129EXL: Windows 10: Cannot upload compiled firmware...

Part Number: EK-TM4C129EXL

Tool/software: Code Composer Studio

Am trying to get a Windows 10 CCS v7 environment fully up and running. For the moment, trying to build some examples for the EK-TM4C129EXL...

Having tested with a few sample apps - which all build successfully - I consistently get a 'total freezeup' of CCS at the point it should be uploading the firmware. CCS becomes unresponsive.

Do not see the debugger break at main loop, as would be standard ( right? )

CORTEX_M4_0: GEL Output: 
Memory Map Initialization Complete
CORTEX_M4_0: Error connecting to the target: Unable to communicate with the device. Please check your connection.

Unplugging the EK-TM4C board then releases CCS, but reports error in communication with board.

I do have drivers installed; Device Manager reports:

Stellaris Virtual Serial Port (COM6)  -- and

Stellaris ICDI DFU Device
Stellaris ICDI JTAG/SWD Interface

Please note that the same board is programmable - and debug-able - from OSX.

Hmmm.... What am I missing?

  • Is the Windows environment that has the connection issues running native Windows or a virtual machine? We usually don't validate CCS running under virtual machines, therefore this configuration is untested. However, It should definitely work on native Windows 10 environments.

    If using native Windows, are you connecting the Launchpad to the PC directly or through a USB port?
    Have you tried connecting to different USB ports and/or using different USB cables?

    Also try rebooting the computer (if it hasn't been done already) to see if that resolves any device driver instability issues. 

  • Since we haven’t heard back from you, we are assuming you were able to resolve this issue and will be closing this thread. If the issue is not resolved or you need further support, just post a reply below or create a new thread. Thanks!
  • Do you have a target.cfg  configuration file added to your project? If not, add one, and take care to configure correct frequency for your Xtal.

  • Your caring & timely response must be memorialized - and thanked.
    Poster's failure to respond proves a breach!       (typing those needless/endless "handle" E's may have exhausted...)

  • ArtiG,

    AartiG said:

    Is the Windows environment that has the connection issues running native Windows or a virtual machine? We usually don't validate CCS running under virtual machines, therefore this configuration is untested...


    Have you tried connecting to different USB ports and/or using different USB cables?

    Many thanks for your attempts to help with this.

    I’m not exactly asking that TI ‘validate’ VMs*… I am asking that there be one, complete, error-free environment we can rely on… Yes, this question is based on Windows10/VMWare Fusion on macOS. Yes, have tried different USB ports and cables, with innumerable reboots along the way.

    I’m now back to Windows 10, after several weeks of foray into Win7 - having been told that certain things we were testing ‘wouldn’t run’ on Win 10. Now that a critical app has been fixed for Win10, I’m back; only to run into new driver issues with Win10. I’d run through all the testing again; the quick recap:

    As of several days ago, the problem we’d been seeing has been reproducible - per my original post. Please note that CCS connects to, and flashes, Launchpads on all other drivers; MSP-EXP430G2, MSP430 (ez-FET), MSP432 (XDS100-ET)…

    Then; update: in the last few days, Windows Update has installed: 2017-12 Cumulative Update for Windows 10 Version 1709 for x64-based Systems (KB4054517) …and suddenly the driver issues are gone.

    Have no idea what magic MS has installed with this update, but the TM4C is now programmable. I can point to no other change in our environment which has changed things. Again, am/had been fully willing to accept ‘pilot error’ as causative here, but had no idea how to remediate, or even properly diagnose.

    Unfortunately, within the time windows we budget for this new project - which may, hopefully?, we’d like to? include some TI components - we are spending really excessive amounts of time on what I think should be pedestrian concerns of ‘building/configuring a reliable, stable development (and examples) environment’.

    Ultimately, I really don’t think this can be laid at the feet of VMWare. Perhaps helpful to some other VMWare sufferer in future: That any USB device connection (ie, any LaunchPad) be connected to the VM with the ‘remember this connection’ option selected. Seems clear that the timing of the disconnect/reconnect cycles had generated some problems in various operations.

    *( We are somewhat dependent on VMs for the moment, for needs of portability. I’ll lobby again: That, ultimately, macOS is at the core of all we do here, including all other software development. It would be really, really great if TI were able to give us one-stop shopping - or at least one-stop Development/Examples Environment - on macOS. )

  • Petrei: Thanks for your suggestion - but this project is a direct lift of a TI Design; I hadn’t changed anything re configuration other than library paths. Crystal frequency was 8 MHz.
  • LouEEEE,

    Thank you for the feedback, we do understand and appreciate your concerns!

    So your initial reported issue seems to be resolved with the latest Microsoft Windows update, correct? Although I wasn't aware of a specific driver issue, I am glad to hear that this is resolved with Windows update and thank you for letting us know as this information could be helpful to others.

    I do understand your dependency on VMs but at the same time, we at TI are constrained in the number of environments/operating systems we can test and validate.

    Thank you also for your feedback on MacOS support, we will certainly take this under consideration for future software releases.

  • Hi,

    I would like to warn you: according to this document: , the board should be configured for crystal frequency 25MHz (§2.2.3).  Unfortunately, the above document has no more the schematic diagrams, at least I cannot see them on my mobile device. (TI, why?).

    If you changed the crystal, the target also needs to change....

  • Petrei, Again; thanks for taking a swing.

    But this is a direct copy of a TI Reference Design; I've not dared to change any source code; eg, to multiply PLL, and have certainly not modified the board in any way physically.

    The 8 MHz I refer to is the Debug / Flash Settings in the Project Preferences. This is set at 8 MHz (again, as copied from reference Design source code), and seems consistent with other EK-TM4C129EXL examples we've fiddled with.

    Please correct me if I'm barking up the wrong proverbial tree here.

  • AartiG,

    AartiG said:
    So your initial reported issue seems to be resolved with the latest Microsoft Windows update, correct? Although I wasn't aware of a specific driver issue, I am glad to hear that this is resolved with Windows update and thank you for letting us know as this information could be helpful to others.

    I am certainly not smart enough to know this! And I would be loathe to assert it; that the update resolved the issue... I can only say that 'stuff started working' roughly contemporaneously, perhaps even accidentally and/or independently, or even serendipitously, with the install of the above-referenced Windows patch. It's impossible to know what Black Magic Microsoft installs/modifies, etc.

    If I were to base any diagnosis on such flimsy - even ethereal - evidence, I'd be roundly excommunicated from (insert domain expertise of choice here).
    AartiG said:
    ... we at TI are constrained in the number of environments/operating systems we can test and validate.

    Could we agree on one? IE, if we are forced to suffer under Windows, could it be a given that Everything will run on (eg) Windows 10?

    Better?: After a lot of experimentation on macOS, through moving relevant libraries and software packages -and various manipulations of the CCS environment, we've been able to build for virtually all of the TI Parts/LaunchPads which apply to our interests*. In fact, what has driven us to Windows is often just the GUI front end(s) to various design examples. If those front ends could be built on macOS (with source code provided), we'd be most of the way toward a macOS-only environment for TI.

    We have wasted a lot of time in essentially non-productive installations/updates/remediations/guessing related to 'Windows'.

    *The MSP-EXP430G2, for example, while interesting - is not a target device for us.