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.

TMDX5505EZDSP: Error connecting to the target: (Error -1143 @ 0x5F) Device core was hung...

Part Number: TMDX5505EZDSP

Problem connecting to the board (C5505 eZdsp).

Full error reads:

Error connecting to the target:
(Error -1143 @ 0x5F)
Device core was hung. The debugger has forced the device to a ready state and recovered debug control, but your application's state is now corrupt. You should have limited access to memory and registers, but you may need to reset the device to debug further.
(Emulation package

  • Dear Yordan:

    Thank you for trying to resolve this issue. Unfortunately, the link you provided does not outline the steps needed to be taken to recover from this error and only talks about a remote possibility of dumping the memory ("it may be possible to dump memory ") . Additionally, it is still unclear how to "dump" the memory if I am unable to connect to the chip to begin with.
  • Have you double checked your target configuration file to match your EVM?

    Best Regards,
  • Target configuration is not an issue as I am able to connect to other C5505 boards.
  • Hi Sergei,

    What revision of the C5505 eZdsp do you have? Is the PCB a red color (rev D)?

    What version of CCS?

    Are you using a GEL file when connecting? Check the target configuration, advanced tab. Does this target configuration connect to other C5505 eZdsp/ USBSTK boards? See

    Are you able to connect with this error - ie the debugger is able to “force the device to the ready state”?
    The GEL console should read.
    C55xx: GEL Output: Reset Peripherals is complete.
    C55xx: GEL Output: Configuring PLL (100.00 MHz).
    C55xx: GEL Output: PLL Init Done.C55xx: GEL Output: Target Connection Complete.

    Can you tell me the program counter (PC) value? Its in the register view under Core Registers.

    Was anything programmed into SPI EEPROM (or attempted)?
    If you can connect, load a programmer and clean the EEPROM - just need to write 0x00 to the firs two bytes. An EEPROM test probably clears these bytes.
    If you cannot connect, try connecting after shorting SPI0_CS0 high so CS cannot go low, and the bootloader skips the SPI boot step.

    If that all fails, then we can look into the FTDI firmware on the embedded USB emulator.


  • Mark:

    Thank you for your response. Unfortunately, for me to be able to try what you have suggested, I have to be able to connect to the target first. However (please, read this carefully before suggesting anything else):


    Here is the error dialog box that I am getting:


    Thusly, my only option is a hardware reset. The board is red, Assy 512320, Rev Unknown (probably D), S/N C5U_1306034.

  • Hi Sergei,

    I've seen some customers were still able to connect after encountering this "Device core was hung" error. The debugger is supposed to have forced the device to "a ready state".

    Do you get any GEL log output when you attempt to connect to this board? Can you confirm a GEL file is being loaded by the CCS Target Configuration?

    Do you have access to an oscilloscope? I'm curious to know if the bootloader is trying to boot from the SPI EEPROM (U9). Did you program anything into it? This board comes with a demo program that bootloads from the SPI EEPROM. The demo program plays two tones out of the headphone jack and blinks the LED labeled XF. Can you confirm if that program is still running when you power the board?

    If a "bad" program was programmed into the SPI EEPROM, it might be the reason for this connection issue. I recommend forcing the bootloader to bypass the SPI EEPROM by shorting the CS signal to VDD_3V3. To do this, you can short TP11 (3V3) to U9 pin 1 (closest to C16). See this photo. Plug the USB cable in with these two shorted together.

    The result should be the XF LED remains solidly lit. You may then remove the short, connect to CCS, and erase the EEPROM by either running an EEPROM example that writes to byte 0 and 1. Or you can run the programmer.out file with an image that is zero for bytes 0 and 1 (a clean option might be available in the programmer.out file).

    Let me know what you find out.

    Do you have a second C5505 eZdsp/ USBSTK that you can use to check your settings/ compare against this one?


  • Mark:

    Thank you very much for your help: this was the ticket (shorting the U9 pin to VDD_3V3)!

    And yes, you are quite right: this error was the result of a bad EEPROM flashing: the board had worked just fine (I had been able to program it multiple times up until the point when CCS froze during flashing and I had to abort and restart it. After that I started getting this error.

    Everything works fine now. Again, thank your for your help!