To minimize power consumption while in S3/S4/S5, the PCH supports a lower power, it is a lower featured version of these power states know as Deep Sx.
In this state, the suspend wells are powered off, while the Deep Sx Well (DSW) remains powered.
The Deep Sx capability and the SUSPWRDNACK pin functionality are mutually exclusive.
Please check the section 188.8.131.52.1 Entry Into Deep Sx - to see the set of conditions required to enter to this state.
The SUSWARN, performed by the PCH, is a handshake to ensure the platform is ready to enter Deep Sx. The PCH asserts SUSWARN# as notification that it is about to enter Deep Sx. Before the PCH proceeds and asserts SLP_SUS#, the PCH waits for SUSACK# to assert.
Table 184.108.40.206 SUSPWRDNACK/SUSWARN#/ GPIO30 Steady State Pin Behavior, summarize the SUSWARM# pin behavior.
I hope this information helps,
Thank you for your reply. The problem I am having is with coming out of reset.
I am starting with just the battery installed and applying Deep Sleep Well power
then Suspend Well power and then de-asserting pch_rsm_reset. With no battery
installed, SUSWARN# signal goes high and we proceed with boot up. With the
battery installed, SUSWARN# stays low. Even if we ignore this and continue with
the power-up sequence, the system doesn't boot.
Sadly, the pin description doesn't describe what is supposed to happen when powering up the devices.
Thank you for your reply. In which document is the section 220.127.116.11.1?
I have been looking at 486711 and 486708, but I can't find this
section. Which Intel document should I be looking at?
The case I am interested is applying power after the
battery is installed. We start off with no power at all. We install
the battery. Then we apply power to the deep Sx well and on
through the other supplies as shown in one the power sequencing
diagrams. Thanks, Paul.
Sorry about the delay in replying. I have been sick for a few days.
Thank you for the reference. This part of the manual implies that the
Power Button signal is required to bring the processor out of reset.
The timing diagrams on page 328 and 329 which supposedly show
the processor coming out of reset don't show the Power Button signal
at all, but, at least I can experiment with this. If there are any other
timing diagrams in the manual showing the relationship between the
Power Button signal and all the other power control signals, that
would be very useful.
I have been looking at some more of the PCH signals after applying power. The chief
difference I have noticed is that in the failing case SLP_S5# never goes high. The timing
diagrams imply that it should go high, although whether this is supposed to always
happen or happen in response to the PWRBTN signal is not at all clear. If I
remove the battery and apply power, SLP_S5# goes high a few mS after SLP_SUS#
goes high. The only way I can get the board to boot with the battery installed,
is to ground RTC_RST#. As this clears the RTC, this isn't a practical solution.
We currently take the PWRBTN signal low for 500mS sometime after SLP_SUS#
goes high in an attempt to boot up the board. I have also tried grounding the WAKE#
signal, but nothing except grounding RTC_RST# will make the board boot with the battery
installed We have had problems with getting the board to boot ever since starting this
project, but we are really stuck now. There seems to be no practical way to get this
processor to boot with the battery installed.
There is some mention in the literature about areas of NVRAM that can have bits set
that will stop normal booting. Is it possible that these are part of the problem? If
so how do we workaround this?
I have downloaded a couple of 'scope traces, which I hope you can find.
There doesn't seem to be any way to associate images with this conversation.
The images are PR2i_SlpS5Good.tif and PR2i_SlpS5Fail.tif
On both traces the following signals can be identified by colour
The PR2i_SlpS5Fail.tif image is the case with the battery installed. SLP_S5# never goes high,as it
is supposed to. CL_RST DOES behave as shown in the power sequence diagrams. However,
the system doesn't boot.
The PR2i_SlpS5Good.tif image shows the case without the battery, where the processor boots
correctly. SLP_S5# can be seen going high. However, in this case, CL_RST never gets driven
low as described in the timing diagrams or as occurs with the battery installed.
We believe we have the correct timing for the PWR_BTN, does the timing look correct to
you? We are now doing the No Deep Sx power application method, using the timing
shown in doc 486708 page 238. Are there any other pre-cursor signals not shown that we
need to drive differently?
It's really odd that neither case shows the part operating as completely as described in the documentation.
Any assistance gratefully accepted!
I have noticed one other difference between the working
case with no battery installed and the non-booting case
with the battery installed.
In the working case, I get SPI Flash clock transitions about
140mS after SLP_S5 goes high. I presume this is the "soft-strap"
data being read. In the non-working case, SLP_S5 never goes
high and the SPI clock just gets driven high once and stays high.
Are there some GPIO pins that need to be strapped in a particular
way to make this board boot with the battery installed? We have attempted
to copy the reference designs as closely as possible as regards the GPIO
straps. We have been trying to get this problem solved for several weeks now.
I can download 'scope images of these cases if that would be useful.