DA14683 Pre-emptive Links to documents:
Datasheet = https://www.renesas.com/tw/en/document/dst/da14683-datasheet?r=1600766
Hardware design guide = https://www.renesas.com/tw/en/document/apn/b-061-application-note-da1468x-application-hardware-design-guidelines?r=1600766
Platform Reference = https://www.renesas.com/tw/en/document/mas/um-b-044-da1468x-software-platform-reference?r=1600766
Software Dev Guide = www.renesas.com/.../um-b-056-da1468x-software-developers-guide
Hardware:
Custom DA14683 Board
Latest SDK = 1.0.14.1081 (last updated in 2018)
Situation:
Relevant Threads:
1) "DA14683: Implementing a "soft power button". Push to sleep. Push again to wake."
https://community.renesas.com/wireles-connectivity/f/bluetooth-low-energy/29023/da14683-implementing-a-soft-power-button-push-to-sleep-push-again-to-wake
2) "DA14683: How to troubleshoot what is blocking extended sleep modes?"
https://community.renesas.com/wireles-connectivity/f/bluetooth-low-energy/28510/da14683-how-to-troubleshoot-what-is-blocking-extended-sleep-modes/100138#100138
3) DA14683: Can't sleep with debugger attached, where in the SDK does it abort?
https://community.renesas.com/wireles-connectivity/f/bluetooth-low-energy/28953/da14683-can-t-sleep-with-debugger-attached-where-in-the-sdk-does-it-abort
NOTE: Before anyone starts asking if these issues are custom hardware related, I can run both the pxp_reporter and BMS demos on my custom hardware, and both sleep with currents in the 300uA range. Given this information, if you still think this is still a hardware issue it would be helpful to maybe suggest some actual troubleshooting ideas instead of just saying "hardware issue".
To repeat my goal here, I'm trying to implement what is essentially a soft power button. Push to sleep. Push again to wake and reset the system. Because of this, I need to retain essentially nothing during sleep. I should be able to shut down everything. The only thing I really care about is being able to wake the system back up with the same button. The system will fully reboot on wake up.
I think I have finally got the DA14683 into a condition where there are no more parts of the system blocking sleep. I shut down everything I could find to shut down, and when I issue the "pm_set_sleep_mode(pm_mode_extended_sleep);" command it looks like it's actually doing it. Nothing is blocking anymore.
That's great, but the sleep current is still in the 3-6mA range. This is too high. Occasionally, after about 45 seconds or so it will drop down to about 600uA. This is still high, but barely acceptable. Sometimes it never drops down and stays in the 3-6mA range.
Questions:
1) How can I troubleshoot what is pulling current while in sleep mode?
Jan 11th Ping.
Hi Nathan, Happy new year. I will check this and will get back to you today.
Regards,
PM_Renesas
Nathan.L.Cook said:The UART is an important part of the firmware functionality at this point. "Commenting out" all instances of the UART usage will be non-trivial and not something I want to do as a casual test. I need you to confirm that you have some suspicion that having the UART RETARGETED would be causing the system to fail sleep before I go about that effort. Do you have a reason to think that having the UART RETARGETED would cause the system to fail to sleep?
Hi Nathan,
Sorry, but it's a little bit difficult to understand the issue, and I have re-read all your comments. If you get the steps I mentioned, you should be able to put the system into extended sleep.
Since it's a custom code & HW, could you please raise a ticket on our private ticketed system and share your whole project?
We can spend some time to take a look into your project and try to understand what is waking up the device.
Ticket created. Thank you.
Just a quick update to close this issue.
Turns out the issue was caused by the touch screen controller chip on the display I'm using. The (rather poor) data sheet for the controller chip (it came attached to the displays) was missing the information about how to put the chip into hibernate mode, and I was only putting it in "monitor" mode. The 3.6mA was caused because the chip was still responding to touch input and would wake up at full power.
I appreciate the help both here and on the private ticket. Thank you very much.
Thanks for sharing the resolution on the forum!