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.

CC2652P7: Enabling DC/DC causes board to become unresponsive.

Part Number: CC2652P7
Other Parts Discussed in Thread: CC1352P7, SYSCONFIG, CC2652PSIP



We are working on a custom board utilizing the CC2652P7. Our intention is to use the chip to transmit and receive IEEE 802.15.4 signals at high power.

We have used the Reference design for the CC1352P7 and SWRC350a as a starting point for our board design.

We have adjusted the internal Load Capacitors for the external HF Oscillator so the board is running and can successfully run any non-RF project.

When we enable the DC/DC option in the firmware, the board seems to no longer complete the boot process.

We have as of yet been unable to determine if the issue is with our layout of the our DC/DC passive components or a software setting we have missed.
I have attempted to Operate the Board Via the Smart RF Studio, and the board fails to communicate once the firmware is flashed, likely due to Smart RF Studio enabling the DC/DC.

What would you recommend we look at next for troubleshooting?

Because we cannot get the RF to work, we are also unable to tune the HF Oscillator or even verify that it is running. I was not able to identify any option to output the HF Clock Signal on a GPIO. Is that something that is possible?

  • Hi Andrew,

    Can you confirm the voltages at the VDDR and DCOUPL pins? What is the system voltage VDDS?

    In SmartRF studio, to confirm, when DCDC is checked SmartRF communication fails but with DCDC unchecked SmartRF works correctly:


  • Hello Jake,

    When DC/DC is unchecked in Code Composer, and the Empty Example Project is running on the board

    VDDS is a stable 3.2V
    The DCOUPL Pin is sitting at 1.273V
    VDDR is sitting at 1.682V

    When DC/DC is checked, and the empty project is flashed to the board (it does not seem to run)

    VDDS is still 3.2V
    the DCOUPL Pin is still sitting at 1.273V
    VDDR is at 1.679V

    I am unable to get Smart RF to open the board regardless of what settings I change. I opened the board in offline mode, unchecked DC/DC and made sure to adjust the Cap Array as required since we have external load capacitors on the board. Going back to the Smart RF panel without closing the device control panel, I then double click on the device and attempt to open in in IEE 802.15.4 mode. The SmartRF application appears to begin flashing it's default bin, and then I am faced with this error:

    I do not know whether Smart RF applies the RF options prior to flashing the board, or if it instead flashes the board, then would apply the RF options. If it is the latter, then I suspect the default firmware has DC/DC enabled by default and the software does not get the chance to set the DC/DC to disabled prior to losing connection with the board.

    Thank you for taking the time to help us figure this out!

  • All the voltages look good so I don't suspect that the issue is directly related to the DCDC but maybe a symptom of something else going on. Have you had your schematics and layout reviewed? You can submit through and I can take a look and see if there's anything that might be suspicious. 

    When the board fails to start are you still able to connect the debugger in CCS? Can you see where the device is stopped or read back register values? Or does setting the DCDC option effectively brick the board?


  • Enabling DC/DC effectively bricks the board as far as the user program goes. The debugger is no longer able to reach any line that is referenced by the debug symbols.

    I can connect via a debugger session if I disable program loading first, but this results in me dropping into the disassembly, which I am not as comfortable navigating or even determining where I am in reference to the User Program VS Bootloader.

    I was able to determine the last line I can reach prior to the board disconnecting.
    F7FFF8D5 bl #0x1000058c

    It is a Branch Link instruction directed at a location that the memory map is prevented from reading.

    After continuing past that line, I receive (Error -2134 @ 0x0) and (Error -1170 @ 0x0) in the code composer console. Full Error Messages Below:

    Cortex_M4_0: Can't Run Target CPU: (Error -2134 @ 0x0) Unable to control device execution state. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package

    Cortex_M4_0: Error: (Error -1170 @ 0x0) Unable to access the DAP. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package

    I can begin the process of submitting our schematics and layout.

  • Andrew,

    Thanks for the additional information.

    Is this happening on just one of your boards / devices or every board you're trying to bring up?

    Is it possible to load and test a couple of the example projects, namely the empty project and the basic_ble project from the SDK?

    I'll keep an eye out for the review request.



  • This is happening on each of our boards.

    I can get the "Empty" example project running on our custom board by starting with the CC1352P-7-4 example project, and then using sysconfig to move to a "custom" board, and then switch to the CC2652P-7. After adjusting our Cap-array to account for our external load capacitors, the project runs without issue.

    One complication is that we acquired the CC2652PSIP launchpad before discovering the migration difficulty. We followed the advice given on some other threads to migrate projects over from the CC1352P7-4; however, most of the RF projects won't migrate between those targets via sysconfig. The TI15.4 stack, nor the BLE stack examples can be switched from the CC1352P-7 to the CC2652P-7. Are there examples for specifically the CC2652-P7 somewhere?

    I see that according to the Answer given in this thread, that sysconfig is not suitable for making such migrations, is that still the case?

    At this moment, we are simply after the ability to output a consistent frequency so that we can tune the HF oscillator properly and then tune the antennae we plan to use.

    Our engineer is making sure our schematic accurately documents our board, and then we'll submit for review.

  • Hi Andrew,

    I'd have to bring in someone from our software team to discuss the best way to port the example. given it fails with SmartRF which only loads test firmware to SRAM and otherwise completely isolates any software issue (as well as the fact that the empty project example works) I think we can focus on the hardware design. We can work on follow-up steps after a review.



  • Hello Jake,

    You should see that submission now. Please let me know if there is anything else I can get you to aid in this process. Thank you!

  • Hi Andrew,

    I see the request. I'll close the topic from here and follow-up through the schematic review request process.