Pulling XRES low to ground will cause the chip to reset, as the XRES pin is the reset pin.
If you look at the cyPm.c file at around line 113, you will see the documentation for the CySysPmHibernate function describing it.
It says "Wakeup is possible from a pin or a hibernate comparator only". "The interrupt cause of the hibernate peripheral is retained, such that it can be either read by the firmware or cause an interrupt after the firmware has booted and enabled the corresponding interrupt".
Based on those lines, I would think that on your software bootup you need to read the reset reason with CySysPmGetResetReason() if you want to treat the hibernate resume differently than a normal bootup, and you will want to clear the hibernate interrupt pin flag, otherwise it will be going into hibernate? (That's what the documentation looks like it is saying)
Thanks for help, e.pratt.
This is my operational senarios.
User turns on power by slide switch and paring with BLE and use the device that is running with a coin cell battery CR2032 with pressure sensor.
The device is programmed to send the pressure input data thru BLE only when the pressure sensor is over the set threshold.
The device does transition between ACTIVE and DEEPSLEEP for low power and iwhenever the pressure sensor is under threshold, WDT timer start but the timer disable as soon as the pressure is over the threshold.
If 10 minutes passed after WDT running and pressure sensor still under threshold, the device goes to hibernate and loses BLE connection.
User noticing that the the device in Hibernate by lost BLE connection and turn off the power and turn back on then the device should do normal bootup but it is still in hibernate unlike my expectation.... It seems my code isn't executed in normal bootup. So I don't want to treat hibernate resume differently but I need only normal bootup. I don't know what is required to boot up normally. Yes I know XRES will wake up the device, but it is not the way that I expect user to do.
If the user is going to power cycle the board when it notices the device is in hibernation mode, why not just use the STOP mode instead? That will be cleared by a power reset by the user, will consume less power, and will probably bypass the reset issue you are seeing.
It could be that the device is resuming from power-cycle at the instruction after CySysPmHibernate() command; Try putting CySysReset() after the hibernate command and see if that fixes the issue.
e.pratt. Thanks for your advice. I just use CySysPmStop() instead of Hibernate. Now everything works as I intended and I understood the difference of wake up in two modes.