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

Problems with debugger Stellaris EK-LM4F120H

Hans de Jong1
Prodigy 40 points
Other Parts Discussed in Thread: CODECOMPOSER

After receiving 2 Stellaris Launchpad boards a little while ago I finally got the time to try them. I installed the drivers, that all went fine. I tried the LM flash programmer , and it connects fine, I can blank check, read images, erase, upload images, etc.

However, when I try to debug my boards with any tool it all has been pretty much horror. I tried both the 30-day evaluation of IAR Embedded Workbench and CodeComposer Studio v5 but they both crash on debug sessions.

IAR 6.5 crashes when I try to perform any action when the debugging starts. It sometimes programs the chip, but it fails to start anything or the debug session. No assembly read-out, and no actions can be performed. Clicking on 'run' results in an error "Unable to start execution" error 0x00000004. After which IAR locks up one full CPU core and is unresponsive. The selected target chip is the LM4F120H5QR; the debugger is TI Stellaris, JTAG, 500kHz.

I tried the uart console demo of CCS v5 but this will hang when trying to start the debug session. The CPU is stopped (blinky stops) and then it hangs forever. When I unplug the board and get an error saying there is a time out while waiting for target powerup/polling the hardware resource. Sub sequentially a fatal program crash is a result.

I've tried to use CooCox IDE , but unfortunately they lack (official) support for the LM4 series proccesors.I am pretty sure the software versions are all up to date, because I downloaded them today of the website. The ICDI firmware revision is up to date as well, it's version 9454. I get the same behavior on both boards and on my personal PC and my work laptop (which runs IAR 6.40). It doesn't matter what program is in the chip; the demo blinky, erased, or manually programmed the bin file from IAR studio (a very simple blinky test).

I am running Windows 7 x64 in test mode on both machines.

Is this a known issue , did I forget to configure/install anything, or any thing else that may help out?

  • 0
    TI__Intellectual 2615 points

    Which version of CCS are you running?

    I just loaded up Blinky via CCS5.3 on Win7x64 (not in test mode) and it worked fine.  Is there anything more that you can tell me about your machine's configuration?  Does your IT department install anything that would interfere with Win7's USB stack? 

    --Miles

  • 0 in reply to Stellaris Miles
    Prodigy 40 points

    I'm running Code Composer Studio version 5.2.1.00018. I downloaded it this weekend from the TI website via the LaunchPad pages.

    I've been trying some things out and I notice that the debugger is very picky on USB ports. I might be running an unusual setup: but I got a Dell U2312HM monitor on my desk (which has a 4-port USB2.0 hub I use for mice, etc.). In addition I use a Sweex USB hub on my desk for easy access and electronics testing (because it has it's own power adapter). The Sweex USB hub is connected via the Dell's USB hub. The dell monitor goes back to the PC. 

    After some trial and error:

    When I run the Launchpad from my PC directly it works fine.
    When I run the Launchpad from my PC -> Dell U2312HM it works fine.
    When I run the Launchpad from my PC -> Dell U2312Hm -> Sweex US009 USB hub  it malfunctions.
    When I run the Launchpad from my PC -> Sweex US009 USB hub  it malfunctions.
    These results apply for both CCS and IAR EW 6.50. LM Flash Programmer works in all situations.

    I also use the sweex hub in combination with my laptop machine, due to a shortage of USB ports. Therefor I use the hub for many many other debuggers and tools, including J-LINK, PICKIT2 and a ST-Link debugger and work without a hitch on both my PC and laptop, in the same setup. There are no drivers or firmware for this hub available as it works out of the box (which you expect from a simple USB 2.0 hub).

    If useful, the specifications of my machines are:

    Asus P8Z77-V PRO with 1805 BIOS (latest)
    Intel i5 3570K (stock speed)
    16GB (2 dimms) DDR3 1333MHz memory (Corsair CMX16GX3M2A1333C9)
    Sapphire HD7850 2GB graphics card 
    3 harddrives including 1 SSD 
    All related motherboard  drivers are updated to latest versions.

    Laptop is a Samsung R510 AS02 with latest drivers and is completely stock. Both machines run Windows 7 x64 in Test Mode.

    As far as I am aware of there I haven't got software running that would influence the USB functionality. I installed and manage these machines myself. I run test mode because I use some unsigned drivers that I use frequently (like MotionInJoy drivers as a controller for various projects), and don't want to reboot for them all the time.

    However, because I see a correlation between the Sweex hub in series or left out, I suspect the hub is most likely the problem in this setup. I will be (carefully) continue using the other USB ports, but I prefer using a powered hub for these things so I there is less chance damaging the monitor/PC ports (or worse).

    Hopefully this helps in narrowing down the issue for anyone else, or hopefully this issue can be resolved in a future update of the ICDI toolchain.