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.

Unable to connect to EK-TM4C1294XL

Other Parts Discussed in Thread: EK-TM4C1294XL, UNIFLASH

I seem to have "bricked" my EK-TM4C1294XL Launchpad. I am using Code Composer Studio 6.1.0 and Uniflash under Debian Linux 7.

The board has been modified to use a 24 MHz crystal, but that is not the problem -- I've been loading and running test software on it for a while. Earlier today I added some new code to enable SSI3 on PF0-PF3. This *may* have triggered the problem. (There's a lot of other code, but I've been running it for weeks. I don't rule out the possibility of a software interaction between the old code and the new.)

The board is now unresponsive. The crystal is oscillating and there is 3.3v. Attempting to download new software with either CCS or Uniflash gives the notorious "CORTEX_M4_0: Error connecting to the target: Frequency is out of range" message. The board is doing *something*, because LED D2 (PN0) is pulsing dimly with about a 91 msec period.

I know that CCS, Uniflash, and my USB drivers are OK, because I can still download "blinky" to a second Launchpad.

I have tried doing a Debug Port Unlock with Uniflash, and it seems to operate -- at least, it gives no error messages. But it does not fix the problem. Doing a Blank Check immediately after an Unlock still gives the "Frequency is out of range" message.

Is there any other way to restore the board to a factory-new state?    Are there any other tests I can perform to identify the problem?

  • Hi,

    I have read before that the Uniflash Debug Port Unlock feature does not work. I am not sure that Debug Port Unlock already works for current Uniflash version.

    Try LM Flash Programmer Debug Port Unlock running under Windows. If successful, program a simple program like blinky. If the blinky works then you have recovered your Launchpad.

    - kel
  • Thanks for that suggestion.  I'll try to scare up a Windows PC tomorrow, and see if LMFlash works.

    However, I'm beginning to think it's the ICDI.  After my last post, I noticed that the virtual COM port (for UART0, that I use for debugging) had vanished.  And usbview, which shows all connected USB devices, is *not* showing the usual "In-Circuit Debug Interface."  I know the USB port is ok because it works with a USB memory stick and with my other Launchpad (and usbview shows that Launchpad).  So for some reason, the dead Launchpad is not enumerating on the USB.

    One more thing occurred to me: today was the first time I tried using the board with external 3v3 power.  I had removed JP3 to disconnect the on-board 3v3 regulator, but I wonder if the ICDI has a problem with 3v3 powered but the USB unplugged.  (I'm fairly certain I never plugged it into the USB port without first applying 3v3, but I'm not absolutely certain of that.)  I'm not sure how to test that the ICDI part is ok.  I'll look into that tomorrow.

  • Okay, it's a problem with our add-on hardware. I had a board plugged into X11 which seemed to be working ok, but when I removed that board the Launchpad began responding to the USB again. I've loaded "blinky" and it's working.

    And yes, I know I should have tried that earlier, but it practically needs a hydraulic jack to separate that 98-pin header.
  • Hello Brad,

    Now we do not want the Booster Pack to Launch when users want to use sensor hub and see the gyro movement response.

    Regards
    Amit
  • Amit, I'm sorry, but I don't understand your reply.  I'm not using any Boosterpacks.

  • Well, I've made some progress. I now know how to enter the locked-up state, and I can break out of it with a simple reset. And external power is working fine.

    Our add-on board plugs into the X11 header, and includes 3.3v and 5v regulators that power the Launchpad. It also includes software-controlled switches that enable 3.3v and 5v to much of the rest of the add-on board. When I turn on that peripheral power (controlled by PJ0), the Launchpad locks up. (That used to be a default action in my initialization code; I now have it under manual control.)

    The curious thing is that it looks like it is just the ICDI chip, and not the TM4C129 MCU, that is freezing. After I trigger a lockup, the timers on the '129 continue to run, an interrupt-driven blinker continues, and it continues to send UART data (visible with a 'scope on TXD). But the virtual COM port stops working and the ICDI no longer appears on the USB port. Pressing the Reset switch restores it.

    I've checked the 3.3v and 5v voltages, and they're fine -- the regulators are not overloaded. My best guess at the moment is that turning on the peripheral power causes a glitch on 3.3v, which for some reason locks up the TM4C123 but not the TM4C129. That's what I'm investigating next.
  • Hello Brad

    I am sorry for making the post a lighter (pardon my unprofessional behavior). The reason for having the header pins being tight is to make sure vibration or fall in conditions of use do not cause boards to get disjoint or lose connections causing an arc affect damaging components. There is a simpler way to unmount the header. Use a small tweezer at the end to lift up, gradually skiiping 5 set of pins and then lifting the header mating. This will loosen up the header and the process can be started gradually and with less effort lifting and eventually lifting the header out.

    Regards
    Amit
  • Ah! Sorry, I must be slow on the uptake today. Nothing unprofessional at all; no pardon required. Thanks for the suggestion, but I have managed to separate the boards with brute force. :-)