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/CC2640R2F: Blackhawk USB100v2 debugger not connecting.

Part Number: CC2640R2F


Tool/software: Code Composer Studio

I am getting the error:

The controller has detected a target power loss.
The user must turn-on or connect the power supply for the target.

I have ensured that my VTREF pin (pin 1) is at 3.3 V. I am using CCS 8.

  • Hi,

    What is the exact connector in your board? The reason of my question is that this debug probe has a cTI 20-pin connector, which requires an adapter to connect to the 10-pin Cortex M connector commonly present on CC2640R2F Launchpads. Depending on this adapter, it is quite easy to reverse its placement - I get the exact same error if I use my Blackhawk USB100v2 on my CC2640R2F board in reverse.

    For help with the different pinout standards, check:
    software-dl.ti.com/.../emu_jtag_connectors.html

    Hope this helps,
    Rafael
  • Hi Rafael,

    I am working with a custom board and ensured that my pinout corresponded to the ARM 20-pin connections. Are you saying the Blackhawk probe has the cTI 20 pin configuration?

    Thanks,
    Abi
  • Abi,

    Sorry for the delay and for the confusion; in my reply I was thinking about the "Blackhawk USB100v2 Model D" but they also sell the "Blackhawk USB100v2-ARM". Per your description you have the latter.

    If you haven't yet solved this issue, the only additional thing I can tell is that the error message is straight from the VTRef pin readout and is performed before any attempts to communicate between the Debug Probe and the target board happen. I am very suspicious that something may be loading your target board in a way the VTRef pin ends up falling below the noise margin to be properly detected by the probe.

    Inserting an oscilloscope or a fast meter may help catch any brownouts on this line while trying to connect to the target. Another idea is to always double-check for either noise or ground loop issues between the target board and the host PC, which can also trigger a false alarm.

    Apart from these suggestions, I am really out of ideas on how to further debug this.

    Hope this helps,
    Rafael