Hello,
I have posted around "Wed, 2018-01-17 09:58" where I was able to resolve my Hybernate state with success.
I now have an updated board and facing this new issue. With the same procedure to POWERDOWN(Hybernate), I ends up having a BPERI at 3V3 cycling with a 108ms period. VDDCORE is also cycling. It look like it POWERDOWN(Hybernate) / WAKE UP in cycle. I went back to my older hardware revision and made some investigation. It look like in POWERDOWN(Hybernate) Step, my VDDCORE was at a low power and BPERI Off.
My question: What should I look for that would explain the BPERI Cycling state ? How can I prevent It ? I am attach to an xMX6 SOM processor with iMX6.PMIC_ON_REQ loop to nSHUTDOWN.
Also, all my event are set to zero and I can't determine any wake-up source when I power up.
u16Addr = DA9063_CONTROL_A;
u8Data_Ctrl = 0;
u8Data_Mask = M_POWER1_EN | M_POWER_EN | M_SYSTEM_EN | STANDBY | SYSTEM_EN | POWER_EN;
fResult = OALDA9063PmicSetRegister(PMIC_I2C_PORT, u16Addr, u8Data_Ctrl, u8Data_Mask);
Note: The board goes in POWERDOWN and the Wakeup works 95% time but a LED is blinking on BPERI.
谢谢,克uy.
Hello Guy,
I will need to investigate this. I have a few questions:
You have my email address from when we last spoke.
Kind regards,
Elliott Dexter
Hello,
Not sure about the INI file as I have a SOM. I am trying to get support from both "side" therefor, I dont have the schematic of the DA9063. I am just accessing the I2C register to POWERDOWN the unit. Previously, the system was stable with some values (PMIC_ON=1V8, STBY 3V...). Now thing is pulsing like if it was in conflict POWERDOWN or WAKE? Since an "event" is waking up the system, the conflict must reside in the electrical signal, where no change was done (on our side). We have PMIC_ON loop to nSHUTDOWN with a 100k pull up VDDCORE (removed - no effect - pulsing VDDCORE). Not using the STBY, ONKEY. VBBAT is pulsing also. nOFF/CHG_WAKE is unknown (yet - working on it). I am not sure what VDDCORE means in my schematic (VLNREF).
The trace shows various signals pulsing, same period all of them. GPIO wakes up and stabilize the system. It loops in POWERDOWN.
谢谢,克uy
I have removed the CONTROL_E Access because it was "after" the CONTROL_A access but without this, it power cycle. We also have lower the MAIN VDC from 5 to 3V6 for heat condition in the LDO.
#if 1 // AN-PN-027 Soft power off
u16Addr = DA9063_CONTROL_E;
u8Data_Ctrl = RTC_MODE_PD;
u8Data_Mask = RTC_MODE_PD;
u8Data = 0;
I2CRegReadEx(1,PMIC_I2C_ADDRESS, (BYTE)u16Addr, (LPBYTE) &u8Data, 1);
u8Data = (u8Data &(~u8Data_Mask)) | u8Data_Ctrl;
fResult = I2CRegWriteEx(1,PMIC_I2C_ADDRESS, (BYTE)u16Addr, &u8Data, 1);
#endif
Hi Guy, can you confirm you have everything you need ? BR JE_Dialog
Hello,
The cycling was caused by SYS_EN hardware signal once the wakeup event had triggered. The iMX6 pulse that signal. The normal power sequence "ignore" the SYS_EN pulse. It could be a configuration around the GPIO8/SYS_EN. The solution was simply to setup "GPIO8-9(0x19) GPI Only with Wake-up suppressed" before the STANDBY in CONTROL A. The RTC_MODE in CONTROL E is not used/changed. My next step will be to reach the STANDBY using the SYS_EN signal from the iMX6 in conjunction with a WAIT/STOP suspend core request (PMIC_STBY_REQ line). The nShutdown tied to the iMX6 is straightforward to test (Dummy PMIC with assert low PMIC_ON_REQ). The cycling was not observed in our preliminary test and was a source of confusion. The PMIC suspend/standby (re)power the iMX6 on wakeup is a simple approuch. The suspend to RAM requires more debugging.
Guy.