• Locked Locked
  • Replies 6 replies
  • Subscribers 54 subscribers
  • Views 3376 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.

evm6472 "Power Failure on Target CPU"

James Markle
Prodigy 160 points

I've been debugging my application on the evm6472 (eInfochips board) using a spectrum digital XDS510 usb plus. Generally this works fine but I'm having a regular problem when starting a new debug session in code composer. After loading the code, I see the following error in the project debug session console:

C64XP_A: GEL Output: PLL1 has been configured.
C64XP_A: GEL Output: PLL2 has been configured.
C64XP_A: GEL Output: PLL3 has been configured.
C64XP_A: 2: GEL StartUp Complete (Primary Core).
C64XP_A: GEL Output: Turn off cache segment
C64XP_A: GEL Output: Disable EDMA events
C64XP_A: Power Failure on Target CPU
C64XP_A: Failed to remove the debug state from the target before disconnecting.  There may still be breakpoint op-codes embedded in program memory.  It is recommended that you reset the emulator before you connect and reload your program before you continue debugging

Re-launching the debug session seems to always trigger the same error until after some time things start working again. Usually this involves cycling power to the board, replugging-in the USB cable and restarting CCS. Unfortunately no combination of these steps seems to reliabily get me back to a working state.

It may be worth noting that I am running CCS version 4 within a WinXP virtual machine. The VMware host is Linux.

Is there anyone else running a similar set-up or anyone else that has run into this "Power Failure on Target CPU" error?

The board does get rather hot but I don't really think it's a power issue. I have tried two boards and still get the error eventually on both.

Thanks,
Jamie

  • Prodigy 160 points

    Once I booted WinXP natively I stopped seeing this problem so I assume the issue is related to running CCS and/or the XDS510 inside a virtual machine.

  • in reply to James Markle
    TI__Guru**** 464301 points

    Hi James,

    VMware should work with CCS depending on the emulator used and VMware version being used.

    See this wiki article for more information:

    http://processors.wiki.ti.com/index.php/VMware_with_CCS

    Thanks

    ki

  • in reply to Ki
    Intellectual 650 points

    I am having the same problem. Runs fine natively. In a Virtual Machine, if pause operation, and wait about 30 seconds i get the error:

    C28xx: Power Failure on Target CPU
    C28xx: Failed to remove the debug state from the target before disconnecting.  There may still be breakpoint op-codes embedded in program memory.  It is recommended that you reset the emulator before you connect and reload your program before you continue debugging


  • in reply to Grant E Pitel
    Prodigy 160 points

    For what it's worth we have had good results moving to CCS v5 and running natively in both Linux and Windows.

  • Expert 1310 points

    Just to up the ante, I have been having this problem (low frequency) on:

    - WinXP (native), CCSv4,

    - Win7 (native), CCSv4.

    We have no virtual machines in this shop.

    It began happening more frequently since I moved to the power lab and have my emulator plugged into a live power conversion device (running at 1/5 voltage). This afternoon my emulator kicked the bucket.  I just noticed it is disconnecting almost every time I apply power to the power conversion device and we have had problems in the past with noise levels on the neutral in the lab.

    I will continue to investigate and report in if I find anything.

  • in reply to Gary Lynch
    Expert 1310 points

    We found a potential of about 0.6 Vdc between the embedded device neutral and the PC's neutral. We installed an isolation transformer in front of the PC and connected the transformer secondary neutral to the device's neutral. 

    It hasn't auto-disconnected nor complained about power failure since (over 24 hours). There are probably many explanations for your particular symptom, but this one worked for us.