The deep sleep functionality in the power management API (fsl_power.c) of the QN9090 is unfinished, but I require this part of the API to work for a project. I have been in contact with NXP about this issue previously on this same board (https://community.nxp.com/t5/MCUXpresso-IDE/QN9090-deep-sleep-support-in-API-commented-out/m-p/17705...). I've asked if this API can be finished to which I have gotten no clear answer, so I presume the answer is no. I have decided to implement this myself, but I'm running into a couple of issues because I am lacking experience and/or documentation.
It's important to mention that I'm an intern, so it's quite possible I'm not understanding something vital or making a mistake.
To measure the energy consumption of the system I am using the QN9090-DK006. I'm measuring the voltage drop over a resistor on the board as advised by the datasheet.
Issue 1, deep sleep: When I compare the measured voltage before the system is put into deep sleep and after the system has been put into into deep sleep and woken up, the voltage measured is 15%~ lower (8.4mV -> 6.5mV), meaning that putting the system into deep sleep causes a significant change of state which is not being entirely reverted by waking up. I presume the cause of this is that when the system gets placed into deep sleep through a ROM-function, a single or multiple power domain(s) and/or peripheral(s) get shut down and remain that way when the system wakes up. I have no insight into what the exact cause for this change is because the ROM-function is hidden: One sets the desired sleep mode and configurations by passing a struct containing register values pertaining to the desired sleep mode and configurations to a function at address 0x0300404d (this happens in fsl_power.c and rom_lowpower.h in the QN9090 library). The function to which this address links is hidden and I'm not able to find anything about it. It's unclear what changed within the QN9090 but it's important to know. I could try running tests involving different functionalities and see which ones fail to get an idea of what changed, but even then there might be changes that aren't immediately apparent so it's necessary that I know what goes on behind the scenes.
Issue 2, power down: Power down mode normally resets the system upon wakeup. I have to write an implementation wherein the system regains it's context and memory after the system wakes up from power down. Now knowing that sleep modes alter the state of the system after waking up, I assume that for this mode the state of the system also changes, and code has to be written to revert the state back to what it was before the system entered power down mode. This assumption might be faulty because power down involves additional code for resetting the system, which might also involve changing the state of the system into something desired, so I'd greatly appreciate if someone told me if this assumption is faulty or not.