This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

DA16200 DCDC Regulation Suspect Not Working

Hello, I'm bringing up a custom board with a DA16200 using the BGA package. Upon initial hardware bring-up, all voltages look good with the exception of the DCDC converter output which is measuring 1.25V instead of the expected 1.37 - 1.40V.  I'm using the DA16200 in low-power, 1.8V flash mode and have gone through the hardware guideline doc finding few clues as to what might be the culprit.  I've posted the schematic sheet with the DA16200.  Couple notes around this:

  • VCC is a regulated output capable of 3.3V/300mA.
  • VBAT going into the GPIO is driven by an op amp buffer to scale the battery input for measurement.
  • I've tried to communicate over UART1 but cannot get the AT interface to respond (115200,8,N,1) so I'm suspecting the MCU is not coming up due to this DCDC regulator issue.  When I pull off the UART pull-ups, I'm finding the IOs are being driven out to 1.8V (noticed that the TX andRX lines measured 2.5V).
  • I've also removed R29 to disconnect the antenna in case there was an issue loading the internal DCDC; no change.
  • Both XO's are now running and I changed out their load caps to 8.2pF.
  • Measured impedances look good; DCDC output to GND measures 3.2k ohm - does this sound right?
  • Is there a GPIO that isnt biased properly maybe?

  • Just an update on another thing tried:

    • Attempted to remove the inductor and externally supply 1.37V to the VDCO rail which would power the VDD_ANA, VDD_PA, and VDD_DA power pins on the MCU.  Power draw to VCC is  +3.3V/6.3mA and VDCO is +1.37V/3.4mA.
    • No change to behavior over the UART1 interface (no AT command response).
  • Forgot to include voltage measurements for RTC block using VBAT = 3.3V:

    • RTC_WAKE_UP = 0.44V for VIL(max) = 0.6V
    • RTC_WAKE_UP2 = 0.45V for VIL(max) = 0.6V
    • RTC_PWR_KEY = 3.11V for VIH(min) = 2.3V
  • More things tried:

    • Changed pull-up on the RTC_PWR_KEY from 470K to 100K to ensure stronger/faster slew rate but no change.
    • Verified 4.7uH inductor was indeed placed on the board using one from a kit but no change.
  • BTW, VDD_DIG pin does show +1.11V coming out pin L3 so the internal LDO for the digital domain looks to be there but I'm sure the internal power supervisors are still not happy with seeing +1.25V on VDD_ANA or the other AFE rails and thus may be keeping it in reset, I suspect.

  • Hi Alan, 

    Thanks for your question online. Let me check this with are Team internally and will get back to you. 



  • Hi Alan, 

    I've read the whole thread, and the actual issue is the UART1 : the device is not responding on the AT CMD.

    Before checking the schematic, can you please indicate which SDK you are using? Are the AT CMDs enabled in the software?

    In file apps/da16200/get_started/include/user_main/config_generic_sdk.h : 

    #define __SUPPORT_ATCMD__                               // Support AT-CMD

    Please keep in mind that the highest COM port number is used for AT CMD.



  • Thanks for getting back to me.  The custom board literally came right off the mfg line and they're first being powered up. I simply used TeraTerm with 115200, 8, N, 1 settings over UART1 and was expecting to see "OK" after typing "AT<enter>".  So no code at this time has been pushed down yet.

    Note that I'm using an FTDI cable that bridges UART-to-USB and its plugged into my PC.

  • Hi Alan, 

    Can you please program the device with the FreeRTOS SDK v3.2.2.0 image ? Here is a download link :



  • These are img files with TTL scripts that likely depend on TeraTerm and the UART assumed to be working, correct?  I've tried to execute these macros under TeraTerm and they simply hang.  I'm going through the process to see if I can get Eclipse setup or IAR to try the Segger J-Link method of pushing an image down.  If you have a .elf image and J-link Flash project I can use, please lemme know.  Thanks.

  • Another thing I've tried is to pulse the RTC_WAKE_UP pin to see if its sitting in a sleep state.  But that did not make any difference either.

    [update]. wanted to be clear on this test that I pulled the WAKE pin up and pulsed it low like the devkit does using a push-button.