Da14683 Not coming out of sleep on internal RC timer

Hi JeffKAllen,

Thank you for posting your questions online.

1, Which SDK version you are using?

2, You can compare with the EVK schematic: https://www.renesas.com/us/en/document/sch/da14683-pro-development-kit-daughter-board-schematic-aqfn?r=1580551

3, Does the customer board powered the same as EVK?

4, You can share your schematic if it's possible.

BR,

JH_Renesas

Hi JH Thank you or quick response,

1. The SDK version is 1.0.14.1081

2. The schematic is at  https://www.dropbox.com/scl/fi/rwocxsxcz5hz7d5lmuu6v/Screenshot-2024-06-13-at-09.25.55.png?rlkey=jzv585dkm083ube290m8ogab2&dl=0 

As far as i can see this is near enough identical to the EVK schematic

3. The power is provided on VBAT and is from a 3.7V lithium battery

4. The timer being used is the free RTOS timer provided in the SDK that we believe uses timer 1

BR Jeff

Hi Jeff,

I got updates from HW team:

I have checked the schematic, and found nothing relevant for the issue.
One item not related to issue has been found, please see last line in this comment. 
  
Some questions to the customer: 

• so, also at VBAT = 3.8 V from external power supply, the chip is not waking up after some time? 
• what are the following rail voltages when the device is not waking up and the VBAT current is 200 µA? 

  VBAT	V33	V18	V18p	V14	V12
  ? V	? V	? V	? V	? V	? V

• is the XTAL32K (Low Power Clock) running?  Please measure at the Xtal32K pins using a low capacitance probe. 
     

• The one comment about the SCH: the LED D1 can not work as it's connected like in the schematic. 
    The LED1 pin of the DA14683 is an Open-Drain output. So the LED has to be connected to a supply, e.g. +3V3. 
    

BR,

JH_Renesas

JH_Renesas said:

The one comment about the SCH: the LED D1 can not work as it's connected like in the schematic. 
  The LED1 pin of the DA14683 is an Open-Drain output. So the LED has to be connected to a supply, e.g. +3V3. 

We don't use this so not an issue but will note for future Thank you

Hi JH

JH_Renesas said:

• what are the following rail voltages when the device is not waking up and the VBAT current is 200 µA? 

  VBAT	V33	V18	V18p	V14	V12
  ? V	? V	? V	? V	? V	? V

Vbat is stable at 3.653

V33 is stable at 3.25V

V18 is stable at 1.795V

V12 is stable at 1.15/1.17V, but drops when unit goes to sleep, when it comes back up after the time period it has a bit more ripple on it

V14 varies depending on state from 1.3V to 1.4V

V18P powers up to 1.8V on power up but then decays to about 0.45V and never comes back up.

Another thing noticed is the power consumption. On power up while running current is 1.9mA approx, when sleep starts current drops to approx 200uA, but then after the 5 seconds sleep time the current goes back up to 1.14mA but the unit does not start up properly, seems it is timing during sleep but not able to power up correctly on trying to leave sleep mode.

JH_Renesas said:

so, also at VBAT = 3.8 V from external power supply, the chip is not waking up after some time? 

Correct when powered up from an external supply at 3.7 or 3.8V it does not wake up

KR Jeff

JeffKAllen said:

Another thing noticed is the power consumption. On power up while running current is 1.9mA approx, when sleep starts current drops to approx 200uA, but then after the 5 seconds sleep time the current goes back up to 1.14mA but the unit does not start up properly, seems it is timing during sleep but not able to power up correctly on trying to leave sleep mode.

Hi JH

On the dev kit board the power consumption is is 1.2mA when running and 20uA when asleep with the same firmware, as with the above the power supplies measure similarly. However after going to sleep and wakinig up for the first time the power comes back to 900uA not 1.2mA

KR Jeff

Hi Jeff, Thanks for your info.

Hi Jeff,

1, Q: what is status of the low-power Xtal32K oscillator? 
 
The lower power consumption after waking up the first time can be explained I think: 
When booting, the chip is operating on the internal LDOs, until first time going into sleep-mode. 
After that, the more efficient DCDC is used, and VBAT current will be lower than when using the LDOs (0.9 mA vs. 1.2 mA). 

2, 

the issue appearing after waking up the first time and using the DCDC makes me think of following: 

• could the customer try to not use the DCDC at all, and let the chip operate from its internal LDOs all the time - for a test? 
  I thinks there's an API for disabling the DCDC.  Is all stable after disabling the DCDC?     

• Or, alternatively: for a test, disable the BOD for all rails (BOD_RESET_EN = 0x0) - see explanation for BOD below. 

• The issue could be related to non-ideal grounding of the bottom ground-pad of the AQFN60 package. 
  Q: Is the PCB design a 2-layer board?  
   

-  PCB design comments: 

• The Ground layer at the Top-side is not ideal, it's not solid.
     The grounding of the decoupling caps is on another ground-plane than the ground used for the DA14683. 
• Are (multiple) vias used to connect the DA14683 ground-pad (bottom layer) to the Top-side ground?
     These are not visible in the shared layout files. 
     If the ground connection of e.g. the V18 decoupling capacitor (C1) is long (that is: having impedance) to the DA14683 Ground,
     the BOD circuit could be triggered when waking up the first time and using the DCDC (big peak currents in the DCDC). 
   
     
  
   
  Only small/narrow connections from one side of the ground-plane to the other side: causing some impedance between both ground areas.  
• 

3, As a test, manually a copper-foil connection could be made (soldered) from one side of the ground to the other side of the ground. 
Use some wide copper foil to make a more solid ground area. 

Hi JH 

Yes the board is 2 layer, but we also have the same issue on a 4 layer version.

The 32kHz crystal is running

We have tried disabling the DCDC and now all seems to work, i am becoming convinced this is grounding issue, so looks like we will have to go to 4 layers to solve the issues.

Would you be able to review gerbers before we commit?

Thoughts?

BR Jeff

Hi JH, have redone the artwork

This is the ground plane inner layer for the new artwork

This is the new bottom layer artwork, yo will see the vias for the ground connections 

I am hoping this will sort the issues, any comments gratefully received.

Thanks

BR Jeff

Hi Jeff,

Is this 4 layers board? but same top/bottom You can share the file or screenshot to my email.

I will share with our HW team for review.

BR,

Jason

Have sent you the files

Have sent you the files

Hi Jason

We have built first boards modified as specified, except for these first ones do not have the ground planes open beneath the crystal oscillator active pads as you suggested. The next ones do have this change. In meantime we tested the boards, all is working as expected, except for the current consumption in extended sleep mode this is still at 170 to 200uA, any ideas on what this could be caused by, could it be the ground planes not being open under the crystal pads?

Thanks Jeff

Hi Jeff,

This may because the Flash doesn't sleep.

You can try to disconnect the power for Flash then test the consumption.

qspi_automode_flash_power_down this function is putting the flash to low power mode.

Which flash you are using, default CMD is 0xb9

BR,

Jason

Hi Jason

The flash is Winbond W25Q80EWUXIE. Have checked the data sheet power down is B9h

KR

Jeff

Have you tried to cut the flash power supply when in sleep mode? is there any peripheral consumptions?

what is the power on the EVB